GL_KHR_robustness Lands For RadeonSI / NVC0, OpenGL 4.5 Changes Complete

[phoronix]

Phoronix: GL_KHR_robustness Lands For RadeonSI / NVC0, OpenGL 4.5 Changes Complete

Thanks to work done by AMD's Nicolai Hähnle, the Mesa Gallium3D state tracker exposes support for the GL_KHR_robustness extension...

http://www.phoronix.com/scan.php?page=news_item&px=KHR-Robustness-ST-Mesa

[Mystro256]

I don't see any patches for ARB_enhanced_layouts on the mailing list

Still, good to hear that gl4.5 is almost done.

[pal666]

I don't see any patches for ARB_enhanced_layouts on the mailing list

you mean, gallium-specific patches for "specified vec4-slot component numbers" part of ARB_enhanced_layouts? 9 days should be enough for that

[boxie]

you mean, gallium-specific patches for "specified vec4-slot component numbers" part of ARB_enhanced_layouts? 9 days should be enough for that

we can hope

[treba]

you mean, gallium-specific patches for "specified vec4-slot component numbers" part of ARB_enhanced_layouts? 9 days should be enough for that

see:

I had been waiting for some more feedback on my approach. At this stage it looks like I will need to make some changed and push the component packing down to the driver backend rather than trying to do it in the glsl compiler frontend. The advantages should be simpler mesa code and better output produced by the shader compiler, it should also put in place the steps for improving some of our other packing code too which currently produces sub-optimal output.

I'm about to take a couple of weeks leave so its very unlikely this will be done before the next Mesa release.

So probably no gl4.5 just yet

[treba]

Does anybody here know whether there is work going on to implement GL_ARB_bindless_texture? The author of FastUIDraw mentioned that it would make his work easier/faster during his talk at XDC and I guess that's true for other projects, too.

[mannerov]

Does anybody here know whether there is work going on to implement GL_ARB_bindless_texture? The author of FastUIDraw mentioned that it would make his work easier/faster during his talk at XDC and I guess that's true for other projects, too.

There was discussion long ago between mesa devs on the topic, and the concensus was that it is designed to reduce cpu overhead, but increases gpu work, which is thus a bad idea unless cpu limited.

[Ancurio]

There was discussion long ago between mesa devs on the topic, and the concensus was that it is designed to reduce cpu overhead, but increases gpu work, which is thus a bad idea unless cpu limited.

Is it really? From my limited understanding, modern architectures are actually completely bindless, ie. they don't have any physical binding points anymore but do everything via virtual addresses.

[mannerov]

Is it really? From my limited understanding, modern architectures are actually completely bindless, ie. they don't have any physical binding points anymore but do everything via virtual addresses.

Basically you have to maintain a table with the texture addresses, and convert the integer given by the app in the shader to the correct address looking at the table,
whereas without the extension you get the address directly.

[Ancurio]

Basically you have to maintain a table with the texture addresses, and convert the integer given by the app in the shader to the correct address looking at the table,
whereas without the extension you get the address directly.

I'm confused. By "integer given by the app", you do mean the binding point index, no? So that translating would happen in the (old) OpenGL usecase, whereas [bold]with[/bold] the extension, it lets you query the virtual address directly and put that in your uniform buffer.

I don't understand; why would skipping the lookup table result in more GPU work? What I was implying earlier was that modern HW no longer has dedicated texture units, I wasn't talking about the driver side.