OpenGL workaround rules

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4445
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 909
Contact:

OpenGL workaround rules

Post by 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?

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: OpenGL workaround rules

Post by 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).

User avatar
c6burns
Beholder
Posts: 1511
Joined: Fri Feb 22, 2013 4:44 am
Location: Deep behind enemy lines
x 134

Re: OpenGL workaround rules

Post by c6burns »

Wolfmanfx wrote: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 :/

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: OpenGL workaround rules

Post by holocronweaver »

dark_sylinc wrote: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.

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4445
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 909
Contact:

Re: OpenGL workaround rules

Post by dark_sylinc »

holocronweaver wrote: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.
holocronweaver wrote: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).
Wolfmanfx wrote: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?
Wolfmanfx wrote: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.

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: OpenGL workaround rules

Post by 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 :)

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: OpenGL workaround rules

Post by holocronweaver »

dark_sylinc wrote: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?

User avatar
AlexeyKnyshev
Goblin
Posts: 213
Joined: Sat May 26, 2012 10:37 am
Location: Russia
x 13

Re: OpenGL workaround rules

Post by 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?
Last edited by AlexeyKnyshev on Sat May 24, 2014 8:25 pm, edited 1 time in total.
Voltage Engine - boost your ogre project with realtime physics and interactive scripting!
OgreBullet & CMake - easy to use bullet physics integration.

drwbns
Orc Shaman
Posts: 777
Joined: Mon Jan 18, 2010 6:06 pm
Location: Costa Mesa, California
x 23

Re: OpenGL workaround rules

Post by 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

User avatar
c6burns
Beholder
Posts: 1511
Joined: Fri Feb 22, 2013 4:44 am
Location: Deep behind enemy lines
x 134

Re: OpenGL workaround rules

Post by c6burns »

drwbns wrote: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.

User avatar
AlexeyKnyshev
Goblin
Posts: 213
Joined: Sat May 26, 2012 10:37 am
Location: Russia
x 13

Re: OpenGL workaround rules

Post by AlexeyKnyshev »

c6burns wrote: 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.
Voltage Engine - boost your ogre project with realtime physics and interactive scripting!
OgreBullet & CMake - easy to use bullet physics integration.

scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 214

Re: OpenGL workaround rules

Post by scrawl »


Post Reply