KHR_no_error Patches Posted For Mesa In Quest To Finding More Performance

[phoronix]

Phoronix: KHR_no_error Patches Posted For Mesa In Quest To Finding More Performance

Timothy Arceri, working for Valve on the open-source Mesa graphics stack primarily around Radeon hardware support, has posted early patches on his latest OpenGL extension upbringing...

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-RFC-KHR-No-Error

[microcode]

For what it's worth, it's pretty hard to separate out the validation code in these GL calls, that's most of the work involved. It will take a lot of work to get a meaningful performance gain from this.

Could be good though, especially for things like compositors which have relatively little interaction with GL.

[VikingGe]

For what it's worth, it's pretty hard to separate out the validation code in these GL calls

Do you happen to know how much time Mesa spends validating GL calls in proportion to doing the actual work?

Good stuff though, might eventually help my ancient CPU a bit.

[iame6162013]

help my ancient CPU a bit.

Indeed, it will free one bit no longer needing to be in cache.

[L_A_G]

For what it's worth, it's pretty hard to separate out the validation code in these GL calls, that's most of the work involved. It will take a lot of work to get a meaningful performance gain from this.

From the application or driver developers? Because if I remember correctly one of the big performance boosting features of Vulkan was that to reduce CPU overhead they made most of the driver side validation optional functionality that would only really be used by developers during development. If they can achieve the same thing on OpenGL then it would definitely be nice.

This is obviously meant for VR, which Valve is heavily invested in, as it requires consistently low frame times and this should help achieve that. Avoidable overheads and specially unpredictable ones are the absolute last thing you want when you're doing VR.

[VikingGe]

Because if I remember correctly one of the big performance boosting features of Vulkan was that to reduce CPU overhead they made most of the driver side validation optional functionality that would only really be used by developers during development.

if your application is triggering OpenGL errors, you're usually doing something horribly wrong. Even if you haven't ever developed anything using OGL, just read the docs, it's full of "this will trigger GL_INVALID_OPERATION if you're doing texture operations on an object that isn't a texture". Vulkan just assumes you're not an idiot and provides validation layers. If you're still doing things wrong... well, people will complain about GPU hangs.

[L_A_G]

if your application is triggering OpenGL errors, you're usually doing something horribly wrong. Even if you haven't ever developed anything using OGL, just read the docs, it's full of "this will trigger GL_INVALID_OPERATION if you're doing texture operations on an object that isn't a texture". Vulkan just assumes you're not an idiot and provides validation layers. If you're still doing things wrong... well, people will complain about GPU hangs.

The thing about the validation layers is that they're mostly useful for the developers of the application. The end users won't have the skills necessary to debug and fix the application and with proprietary software like games the developers obviously don't even want for them to have access to the source code.

Theoretically at least the debugging should be done and the application should work completely without issues before the end user gets their hands on them.

[microcode]

The thing about the validation layers is that they're mostly useful for the developers of the application. The end users won't have the skills necessary to debug and fix the application and with proprietary software like games the developers obviously don't even want for them to have access to the source code.

Theoretically at least the debugging should be done and the application should work completely without issues before the end user gets their hands on them.

The end user has the full ability to use layers. They can use the validation layers (useful for developers mainly, as you said), but they can also use custom layers. This means that if you have an out-of-support binary program which has a bug which is triggered when it is used with a newer Vulkan driver, you could technically shim the bug-inducing calls in some way to work around them. Really there are many excellent use cases for layers.

[microcode]

From the application or driver developers?

I meant work for the driver developers. Application developers are already mostly "done" in OpenGL. Their code shouldn't have been triggering OpenGL errors to begin with, so enabling this should have no impact on stability (fingers crossed).

[L_A_G]

Really there are many excellent use cases for layers.

Maybe, but for 99.9% of users those validation layers are just useless cruft causing unnecessary CPU overhead.