OpenGL workaround rules

[dark_sylinc]

Writting on the HLMS forced me to take a look at the GL rendersystems (both GL3+ & GLES 2; GL & GLES are removed from Ogre 2.0), and I'm fixing the performance horrors as I encounter.

Something I'm stumbling quite often is with workaround code that today is probably useless.

For example:

Code: Select all

mStateCacheManager->setDisabled(GL_SCISSOR_TEST);
// GL requires you to reset the scissor when disabling
w = mActiveViewport->getActualWidth();
h = mActiveViewport->getActualHeight();
x = mActiveViewport->getActualLeft();
if (flipping)
    y = mActiveViewport->getActualTop();
else
    y = targetHeight - mActiveViewport->getActualTop() - h;
OGRE_CHECK_GL_ERROR(glScissor(static_cast<GLsizei>(x),
                              static_cast<GLsizei>(y),
                              static_cast<GLsizei>(w),
                              static_cast<GLsizei>(h)));

"GL requires you to reset the scissor when disabling", um... no and no. From both specs:

When the scissor test is disabled, it is as though the scissor box includes the entire window.

So, clearly, calling glScissor after glDisable(GL_SCISSOR_TEST) is unnecessary.
Either the guy who wrote this didn't knew the spec well, or he was workarounding a non-compliant buggy driver.

Who knows how long this bug was there? If by 2014 this bug has been erradicated from all OpenGL drivers, we're just left with an inefficient code adding API overhead.

So... I SAY NO TO WORKAROUNDS! We can't let drivers dictate the terms and then make us look bad when they're done fixing it.

From now on, we should follow a couple rules:
1. (Dekstop) Avoid workarounds. If the driver is buggy, it's their job to correct it. Bug the vendor's driver team to fix it. They usually do it. Let's keep a list of hall of shame until they fix it; blaming them instead of us. Desktop users are used to installing latest drivers, so this is not a long term problem, rather very short term.
If the bug is critical (i.e. affects many systems or many vendors, breaks too much compatibility, it is very noticeable, could put a lot of blame on us), go to rule 2.

1. (Mobile) Prefer avoiding workarounds if possible. But Android ES drivers are a minefield, and they can take ages to be updated with the proper fix (if the bug is ever fixed). So this rule is much more lax. Go to rule 2.

2. Enclose the workaround in a macro and define the macro in OgreGL3PlusPrerequisites.h/OgreGLES2Prerequisites.h
Then document the workaround:

Code: Select all

//glScissor rectangle needs to be reset even after glDisable(GL_SCISSOR_TEST); otherwise it still gets scissored
//First seen: YYYY/MM/DD
//Last seen: YYYY/MM/DD
//Driver: nv_gl.dll 1.2.3456
//GPU: GeForce NNN
#define OGRE_GL3_WORKAROUND_1

Then on the code itself:

Code: Select all

#ifdef OGRE_GL3_WORKAROUND_1
/* .. workaround code here .. */
#endif

This way, we know what is what, why it exists, when was this bug first observed; and we may even see if someone still observes this behavior after many years.
And more importantly, we can track each bit of workaround code and enable/disable on demand (and if too old, get removed)

Any feedback?

[Wolfmanfx]

Hi,

I have spotted this one 2 years ago + some other things which are useless but did not remove it (you know winXP is still a topic in china).
But for 2.0 we can remove that (same with disable glDither every frame for example).
Using macors for driver bugs are not so useful because the should be enabled / disabled on runtime based on hardware / driver. On android there many devices which will never see a update (but this changing slowly).

[c6burns]

Using macors for driver bugs are not so useful because the should be enabled / disabled on runtime based on hardware / driver. On android there many devices which will never see a update (but this changing slowly).

I agree it would be more useful to set these up as config options in the rendersystem, but if that's a pain then I don't think it's totally necessary. Also yes android is a really painful environment right now :/

[holocronweaver]

So... I SAY NO TO WORKAROUNDS!

Are there any GL3+ specific workarounds you found?

My general philosophy is if something is implemented correctly according to the API, then it should work. If it doesn't, then let the user decide not to use that feature on that particular system config. No macros needed within OGRE. If (for example) transform feedback doesn't work on Intel, the user needs to test this and create a workaround in their code if they plan to support Intel devices. If a very basic feature doesn't work, like a render command, yet the driver claims support, then that driver isn't ready for consumers yet and OGRE should ignore it.

[dark_sylinc]

Are there any GL3+ specific workarounds you found?

Not yet. The RS is very new, so I doubt it. All the workarounds seem to be the ones carried out from the old GL.

If a very basic feature doesn't work, like a render command, yet the driver claims support, then that driver isn't ready for consumers yet and OGRE should ignore it.

You're so young and naive!
GL has been plagued with basic render commands not working in its past. Literally, AMD's first official OpenGL 3.0 driver for Linux didn't work (Seriously, it failed to do anything). Nvidia would flicker when using 2D texture with autogen mipmaps (this is GL 2.0 era!).
There are "critical" bugs out there every once in a while that do need patching (the driver IS out there for consumers). Usually workarounds are "if you do Z before X, then X works as expected; but this isn't needed or should be like this. And since other AAA games happened to be doing Z before X, then Ogre is the buggy one [we aren't]".
Just saying, the "that driver isn't ready for consumers yet and OGRE should ignore it" doesn't apply to critical bugs. But I know what's in your mind. You're thinking "ok GL 4.4 drivers aren't mature yet; it's not ready yet for consumers." I'm thinking "GL 3.1 driver broke in the last update". I'm not talking about Intel. I'm talking about NVIDIA and AMD.

Fortunately, in 2014 most GL driver vendors work at the basic level (texture generation, render state calls buffer generation) by now, so that leaves rare critical bugs. Those are the ones that need a macro.
But the rest, we don't even bother. For example Catalyst 13.11 broke 3D textures with mipmaps (crash). Workaround? Don't use mipmaps. We just don't bother, it's gonna be fixed in the next one. The driver crashes w/ almost all 3D texture mipmaps so it's hard not to blame the driver.
Use rule 1 (in fact I reported the bug and they answered it was already fixed and going to in their next beta release, and they delivered).

I have spotted this one 2 years ago + some other things which are useless but did not remove it (you know winXP is still a topic in china).

I'm not sure if I get what does WinXP have to do with it?

Using macors for driver bugs are not so useful because the should be enabled / disabled on runtime based on hardware / driver. On android there many devices which will never see a update (but this changing slowly).

Still add the documentation to the header and enclose between macros. We can later keep track of the workaround code (even if it can be turned on/off at runtime); and when it gets too old (erradicated), we can remove it entirely quickly.

[Wolfmanfx]

Yes maybe creating workaorund caps (like we do it with features). I meant WinXP has usual old hardware / sw combo with old drivers which never got updated

[holocronweaver]

I'm thinking "GL 3.1 driver broke in the last update". I'm not talking about Intel. I'm talking about NVIDIA and AMD.

We should have a bi-annual cleansing of workarounds to avoid them building up and being forgotten. Is there an OGRE team calendar?

[AlexeyKnyshev]

I think it is quite something like offtop but I have this problem with OGL, and nobody cares. http://www.ogre3d.org/forums/viewtopic.php?f=2&t=80979
Long story short, I can't get texture shadows working (stencil shadows work well).
In my app I have keyboard toggle, and when they should be enabled I see FPS drop but nothing else?

[drwbns]

I agree with matias. if its not an ogre bug then dont cater to buggy drivers. maybe a wiki for current workarounds would be the best for those in need of them

[c6burns]

I agree with matias. if its not an ogre bug then dont cater to buggy drivers. maybe a wiki for current workarounds would be the best for those in need of them

I feel that catering to buggy implementations of a particular standard is just part of the game. It's not specific to graphics programming ... whether the spec is from khronos or ietf or whoever, vendors break it and you can either play ball or be broken. I think the point is more how to document the workarounds in order to ensure they don't become unnecessarily permanent fixtures.

My background is VoIP, and we ended up with dozens of these workarounds in both SIP and RTP implementations. We organized them into configuration switches so that end users could easily turn them on and off where needed. I feel this is a useful idea for Ogre, because end users are probably indie devs who end up shipping products without a giant test lab and QA process. Having developers able to instruct end users to make a config change for a workaround saves the dev from having to make custom workaround builds using macros. That's just my 2 cents Maybe the video hardware climate is very different from VoIP hardware though, but we had major vendors with implementation quirks that would last anywhere from months to years.

[AlexeyKnyshev]

My background is VoIP, and we ended up with dozens of these workarounds in both SIP and RTP implementations. We organized them into configuration switches so that end users could easily turn them on and off where needed. I feel this is a useful idea for Ogre, because end users are probably indie devs who end up shipping products without a giant test lab and QA process. Having developers able to instruct end users to make a config change for a workaround saves the dev from having to make custom workaround builds using macros. That's just my 2 cents Maybe the video hardware climate is very different from VoIP hardware though, but we had major vendors with implementation quirks that would last anywhere from months to years.

Very similar to plug n play support for dosen hardware in Linux. Things, such udev and so on. There is HUGE proc inside xbox, playstaition - it's fixed hardware and quite stable SDK that gets rid such problems.

[scrawl]

Related: https://www.youtube.com/watch?v=Ev7lM7SWVHE