Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clip control on the Apple GPU

rosenzweig.io

Post reply on HN
Print view View original

31–40 of 127 posts

Re: Clip control on the Apple GPU

#31

Post by phire »

viktorcode wrote: post #15

Can someone explain to me why support OpenGL at all? Vulkan is easier to implement. Is there a need for OpenGL on Linux?

Keep in mind that Mesa actually implements most of OpenGL for you. Its not like you are implementing a whole OpenGL driver from scratch, you are mostly implementing a hardware abstraction layer.

My understanding is that this hardware abstraction layer for mesa is way easier to implement than a full vulkan driver, especially since the earlier versions of OpenGL only require a small subset of the features that a vulkan driver requires.

Re: Clip control on the Apple GPU

#32

Post by bob1029 »

Jasper_ wrote: post #30
bob1029 wrote: post #25

Clip space is the bane of my existence. I've been building a software rasterizer from scratch and implementing vertex/triangle clipping has turned into one of the hardest aspects. It took me about 50 hours of reading various references before I learned you cannot get away with doing this in screen space or any time after perspective divide. It still staggers me that there is not 1 coherent reference for how to do all…

Vertex/triangle clipping is quite rare, and mostly used for clipping against the near plane (hopefully rare in practice). Most other implementations use a guard band as a fast path (aka doing it in screen space) -- real clipping is only used where your guard band doesn't cover you, precision issues mostly. I'm not sure what issues you're hitting, but I've never found clipping to be that challenging or difficult. Also…

> clipping against the near plane (hopefully rare in practice)

I am not sure I understand why this would be rare. If I am intending to construct a rasterizer for a first-person shooter, clipping is essentially mandatory for all but the most trivial of camera arrangements.

Re: Clip control on the Apple GPU

#33

Post by Jasper_ »

viktorcode wrote: post #15

Can someone explain to me why support OpenGL at all? Vulkan is easier to implement. Is there a need for OpenGL on Linux?

Because of how mesa is structured. OpenGL is notoriously terrible to implement, so there's a whole framework called Gallium that does the hard work for you, and you slot yourself into that. Meanwhile, Vulkan is easier to implement from scratch, so there's a lot less infrastructure for it in mesa, and you have to implement more of the boring paperwork correctly.

It's an accident of history more than anything else. Once the reverse engineering is further along, I expect a Vulkan driver to be written for it, and the Gallium one to be phased out in favor of Zink.

Re: Clip control on the Apple GPU

#34

Post by bpye »

Jasper_ wrote: post #30
bob1029 wrote: post #25

Clip space is the bane of my existence. I've been building a software rasterizer from scratch and implementing vertex/triangle clipping has turned into one of the hardest aspects. It took me about 50 hours of reading various references before I learned you cannot get away with doing this in screen space or any time after perspective divide. It still staggers me that there is not 1 coherent reference for how to do all…

Vertex/triangle clipping is quite rare, and mostly used for clipping against the near plane (hopefully rare in practice). Most other implementations use a guard band as a fast path (aka doing it in screen space) -- real clipping is only used where your guard band doesn't cover you, precision issues mostly. I'm not sure what issues you're hitting, but I've never found clipping to be that challenging or difficult. Also…

Even with a guard band don’t you need to at least test the polygons for Z clipping prior to the perspective divide?

Clipping in X and Y is simpler at least, and again the guard band hopefully mostly covers you.

Re: Clip control on the Apple GPU

#36

Post by bpye »

bob1029 wrote: post #32
Jasper_ wrote: post #30

Earlier quoted context omitted.

Vertex/triangle clipping is quite rare, and mostly used for clipping against the near plane (hopefully rare in practice). Most other implementations use a guard band as a fast path (aka doing it in screen space) -- real clipping is only used where your guard band doesn't cover you, precision issues mostly. I'm not sure what issues you're hitting, but I've never found clipping to be that challenging or difficult. Also…

> clipping against the near plane (hopefully rare in practice) I am not sure I understand why this would be rare. If I am intending to construct a rasterizer for a first-person shooter, clipping is essentially mandatory for all but the most trivial of camera arrangements.

Clipping or culling? I expect it’s mostly the latter unless your camera ends up intersecting the geometry.

Re: Clip control on the Apple GPU

#37

Post by hashishen »

samstave wrote: post #27
bob1029 wrote: post #25

Clip space is the bane of my existence. I've been building a software rasterizer from scratch and implementing vertex/triangle clipping has turned into one of the hardest aspects. It took me about 50 hours of reading various references before I learned you cannot get away with doing this in screen space or any time after perspective divide. It still staggers me that there is not 1 coherent reference for how to do all…

Be the documentation you want to see in the world.

"RTFM" - The manual

Re: Clip control on the Apple GPU

#38

Post by bpye »

Jasper_ wrote: post #29
bla3 wrote: post #3

> Here’s a little secret: there are two graphics APIs called “Metal”. There’s the Metal you know, a limited API that Apple documents for App Store developers, an API that lacks useful features supported by OpenGL and Vulkan. > And there’s the Metal that Apple uses themselves, an internal API adding back features that Apple doesn’t want you using. Apple does stuff like this so much and gets so little flak for it. I us…

As a graphics engineer, good riddens to the old clip space, 0...1 really is the correct option. We also don't know what else "OpenGL mode" enables, and the details of what it does probably changes between GPU revisions -- the emulation stack probably has the details, and changes its own behavior of what's in hardware and what's emulated in the OpenGL stack depending on the GPU revision. Also, to Alyssa, if she's read…

> you're just going to have to implement support shader variants

I admittedly have zero experience with Mesa, but it seems like shader variants is something that should be common infrastructure? Though of course the reason that a variant is needed would be architecture specific.

Re: Clip control on the Apple GPU

#39

Post by bob1029 »

bpye wrote: post #36
bob1029 wrote: post #32

Earlier quoted context omitted.

> clipping against the near plane (hopefully rare in practice) I am not sure I understand why this would be rare. If I am intending to construct a rasterizer for a first-person shooter, clipping is essentially mandatory for all but the most trivial of camera arrangements.

Clipping or culling? I expect it’s mostly the latter unless your camera ends up intersecting the geometry.

Both. You almost always need both.

Clipping deals with geometry that is partially inside the camera. Culling (either for backfaces or entire instances) is a preliminary performance optimization that can be performed in a variety of ways.

Post reply on HN