OpenGL Connundrum

Graphics and GPU Programming Programming OpenGL

Started by neeker July 11, 2013 06:36 PM

13 comments, last by MarkS_ 10 years, 9 months ago

neeker

228

Author

July 11, 2013 06:36 PM

Hello,

I'm looking for some opinions on a cunnundrum I came across today. This applies to a project that I'm in no position to change the parameters, so please don't offer suggestions along those lines.

The project, which has been in development for about a year, uses OpenGL 2.1 with GLSL 1.20. Today, it was discovered that it will not run on Win 8 machines which do not have an OpenGL driver (this can happen for numerous reason, e.g. a user installs Win 8 over Win 7 without checking for newer drivers). In this case, Win 8 will attempt to emulate OpenGL version 1.1 through GDI. The project specification states that it must work under this scenario.

So, it seems that I'm left with two options: either create a branch that uses GL 1.1 (currently, my rendering is done in shaders, so this seems substantial) or create a DirectX branch. Neither seems appealing, but which would be better (least evil)? Going GL 1.1 seams faster to develop, but the results will look pretty ugly. Is there another route that I'm missing?

Regards!

MarkS_

3,509

July 11, 2013 07:01 PM

If the user's machine doesn't meet the requirements, why not tell them so? It is entirely expected to be asked to download current drivers if the drivers are out of date.

21st Century Moose

13,459

July 11, 2013 07:08 PM

This can also happen on Windows XP, Vista or 7 machines that have certain OEM-provided drivers (Intel in particular), so it's a bigger problem than you think.

One viable solution may be to just tell your users to upgrade their drivers. Depending on their environment this may not always be possible, of course. Those OEM drivers may also cause you trouble as sometimes the machine may be "locked" to the driver, and users may have to do some jiggery-pokery to get them updated.

You may also encounter problems with "switchable graphics" laptops, particularly those with AMD GPUs, where driver support is quite poor.

That leaves you with your original two options.

We can immediately discount the first - using software-emulated GL1.1 via the default Microsoft implementation. It's just too slow, and by "too slow" I don't mean running at 50% or some reasonable fraction of full speed; I mean framerates that are typically in the order of 1fps.

So creating a D3D branch seems to be the best way forward from here; or at least the lesser of the two evils.

One interesting twist on that option is to write a GL to D3D emulation layer which would enable you to keep your main GL2.1 code but have it translated by that layer to D3D calls. Several public examples exist that may help you here; I'd recommend looking at ANGLE, for example; even though it's for ES2.0 you should find that there are similarities to the GL2.1 code you're using, and it is widely used in the field ("ANGLE is used as the default WebGL backend for both Google Chrome and Mozilla Firefox on Windows platforms. Chrome uses ANGLE for all graphics rendering on Windows, including the accelerated Canvas2D implementation and the Native Client sandbox environment") so you have a good degree of confidence in it.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

Vilem Otte

3,376

July 11, 2013 07:23 PM

You may also encounter problems with "switchable graphics" laptops, particularly those with AMD GPUs, where driver support is quite poor.

I have to oppose to this, I've got a laptop with Mobility Radeon HD 5470 and driver fully supports OpenGL 4.2 and some further extensions. Of course the performance of F.e. tessellation is imcomparable to F.e. Radeon 6870 that I've got in desktop, but...

Even further, the Linux drivers (as I'm mainly Linux user, but run both major OS on my computers) supports same version of OpenGL and same extensions.

EDIT: Although I can't state about older AMD gpus...

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com

neeker

228

Author

July 11, 2013 07:30 PM

Thank you for the info mhagain.

The spec states specifically that we cannot require changes to the user machine to use the software, so requiring a driver update is out of the question (FWIW, we can't even recommend this).

Unfortunately, this project must also be portable (including GL ES), which is why I didn't want to go the D3D route. Maintaining two code paths sounds horrible, but I think I can do the D3D "emulation" layer with a lot less effort. Cheers!

21st Century Moose

13,459

July 11, 2013 07:55 PM

Unfortunately, this project must also be portable (including GL ES), which is why I didn't want to go the D3D route. Maintaining two code paths sounds horrible, but I think I can do the D3D "emulation" layer with a lot less effort. Cheers!

Looks like ANGLE is the solution you want then; just use your ES2.0 path on Windows and send it through ANGLE to handle the emulation.

I have to oppose to this, I've got a laptop with Mobility Radeon HD 5470 and driver fully supports OpenGL 4.2 and some further extensions. Of course the performance of F.e. tessellation is imcomparable to F.e. Radeon 6870 that I've got in desktop, but...

Even further, the Linux drivers (as I'm mainly Linux user, but run both major OS on my computers) supports same version of OpenGL and same extensions.

I wouldn't dispute that it works fine for you, but it is a fact that AMD switchable graphics drivers on Windows have historically been a massive PITA for many users, with AMD themselves not even supporting updates using their regular driver packages.(see e.g. http://support.amd.com/us/kbarticles/Pages/AMDCatalystSoftwareSuiteVersion126ReleaseNotes.aspx and note the section headed "The following notebooks are not compatible with this release"). See here for more discussion.

It's all irrelevant anyway as the OP has made it clear that no changes to the user PC is part of the requirements.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

neeker

228

Author

July 11, 2013 09:06 PM

I'm unable to use ANGLE, although it looks really interesting. If I do go the D3D emulation route, I'd have to incorporate it into our libraries. So, I'll wait a bit longer to see if another suggestion comes up.

uglybdavis

1,066

July 11, 2013 09:31 PM

Sounds like your core issue is not having your render code abstracted enough.

Off the top of my head something like:


class IVertexBuffer { // Abstract Base Class 
     void Bind() = 0;
     void Unbind() = 0;
}

class GL2xVertexBuffer {
    // Contains a VAO
}

class GL1xVertexBuffer {
    // Contains a list of vertices
}

class IIndexBuffer { // Again abstract
   void DrawCall() = 0;
}

// Subclass that draws gl2x path, subclass that draws gl1x path

class IMaterial { // Still Abstract
    bool m_bIsLit;
    Color m_colorAmbient;
    Color m_colorDiffuse;
    Color m_colorSpecular;

    void SetState() = 0;
    void ClearState();
}

class GL2xMaterial {
    void SetState(); // Bind shader, bind shader properties
}

class GL1xMaterial {
    void SetState(); // Configure fixed function states
}

void Render(IVertexBuffer& vertexBuffer, IIndexBuffer& indexBuffer, IMaterial& material) {
    material.SetState();
    renderBuffer.Bind();
    indexBuffer.DrawCall();
    renderBuffer.Unbind();
    material.ClearState();
}

Sounds like what your assignment really wants. Then you just need some utility code:


IVertexBuffer* CreateVertexBuffer() {
    if (g_bSystemSupportsGl2X)
         return new GL2xVertexBuffer();
    return new GL1xVertexBuffer();
}

21st Century Moose

13,459

July 11, 2013 09:55 PM

Sounds like your core issue is not having your render code abstracted enough.

That's not going to solve the problem of a Windows PC without a proper OpenGL driver going through software emulation and getting 1fps though.

Yes, one could use such an abstraction to include a D3D layer relatively easily, but there are complexities that - if you come at it primarily with a GL hat on - are going to cause you trouble:

No requirement for "bind to modify" in D3D.
Shader uniforms are per-program object in GL, global-and-shared in D3D.
Differences between D3D "streams" and GL "attribs".
Hardware capabilities that D3D enforces but GL emulates in software if absent.
Etc etc etc.

@OP - is the reason for not being able to use ANGLE the BSD license? TitaniumGL is another option that's freeware but only supports GL1.4; no shaders but better at least than software-emulated 1.1 (I've little experience of it so can't vouch for it's quality).

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

uglybdavis

1,066

July 12, 2013 12:15 AM

Nothing is going to solve the problem of not having proper drivers. Nothing.

From the original post i gather that the game must work under OpenGL 1.1 emulated environment (Hence no ANGLE). There was no mention of it needing to be performant.

It honestly sounds to me like the idea of the assignment is to implement multiple render paths, which is what the poster seems to want to avoid.

Could be wrong tough....

OpenGL Connundrum

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

OpenGL Connundrum

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines