FirePro "Not a GL2 implementation"

I just received a new FirePro W8100 GPU and updated to Ubuntu GNOME 15.04 at work and it looks like the new FirePro cards don't work the same as previous versions and jogl can't seem to create a backwards compatible GL2 implementation.

Code works on other systems but with my new card (and another co-worker's new FirePro Mobile card on a laptop running Win7) it cannot create a GL2 context.

So, we updated to the newest version of jogl and still the same issue. Any thoughts? If nothing comes to mind I can throw together a sample app that fails.


Thanks!
Stephen Ranger

Hi

Does this program fail too?
https://gist.github.com/gouessej/3420e2b6f632efdddf98

Yes, it does. Apparently, if I request a specific GLProfile (GLProfile.getGL2GL3() for example) it fails but if I leave the GLCanvas constructor empty it runs fine.

If I print out JoglVersion.getGLInfo(gl, null) with no capabilities, it shows

  "GL Profile   GLProfile[GL2/GL2.hw]"

but if I request GL2GL3, I get

  "GL Profile   GLProfile[GL3/GL3.hw]"

and it throws the "Not a GL2 implementation" exception.

I meant by "Yes, it does" as it does run. Sorry, I looked at your email before lunch and mis-remembered what your question was. You asked if it fails, too. I apologize if I was confusing in my response.

Your example works; it doesn't request a specific profile so it gets the default for the device (GL2) but if I request a GL2GL3 profile it throws an exception as if the profile requested shouldn't be backwards compatible.

Why not simply use GLProfile.getMaxFixedFunc() or getMaximum() then?

GLProfile.getMaxFixedFunc(true) doesn't seem to support everything that the old GL2GL3 profile did; shader point size, modifying the vertex location via a uniform, and point color via attribute all don't work in the current shader I'm using.

GLProfile.getMaximum(true) has the same "Not a GL2 implementation" exception.


I was looking at how the default GLCapabilities constructor works and it seems to pull the default device's default capabilities from a pre-defined mapping; could the mapping not be set up correctly or could this new line of cards not support a GL2/GL3 profile?


Thanks for the help,
Stephen Ranger

How does jogl initialize the device-to-profile mapping? Is there anything I could add that would determine what the issue might be (or where I could add some println's to figure out what it's setting up and where the issue might be; if any). Also, is there a way to force a profile that it might not believe is valid for testing?

Thanks for all your help.

GL2GL3 is a common subset for GL2 and GL3, maybe your graphics card's driver supports GL3 but not GL2.

Requesting a GL2 context directly works fine; it just doesn't do anything that isn't GL2 specific (as stated in my previous email) and JoglVersion.getGLInfo() says it supports GL2, GL3, and GL2GL3.

Please create a runtime version check test.log and runtime debug.log
according to instructions at
http://jogamp.org/wiki/index.php/Jogamp_Versioning_and_Releases#Runtime_Version_Check

This will give a full list of the capabilities that your driver support.

many drivers do not have backwards compatible GL3, especially using the latest versions.

2015-05-06 11:57 GMT+02:00 sranger [via jogamp] <
ml-node+s762907n4034438h41@n3.nabble.com>:

> Requesting a GL2 context directly works fine; it just doesn't do anything
> that isn't GL2 specific (as stated in my previous email) and
> JoglVersion.getGLInfo() says it supports GL2, GL3, and GL2GL3.
>
>
>  - Stephen
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://forum.jogamp.org/FirePro-Not-a-GL2-implementation-tp4034418p4034438.html
>  To start a new topic under jogl, email
> ml-node+s762907n782158h61@n3.nabble.com
> To unsubscribe from jogamp, click here
> <http://forum.jogamp.org/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=762907&code=eGVyeGVzQGd1ZGlubmEuY29tfDc2MjkwN3wtNTE5NjUwMzEw>
> .
> NAML
> <http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

How do I verify that it does or does not support a backwards-compatible context? (I've also attached the logs)

EDIT: the test.log says "GL3bc false" so I'm assuming jogl doesn't believe it's supported. Is there a way I can verify that outside of jogl? Though, it also says "GL4 false" which I know is untrue unless the open source radeon drivers don't support it. Also, it says "GL2GL3 GLProfile[GL2GL3/GL3.hw]" but if I request a GL2GL3 profile, I'm given "GLProfile[GL3/GL3.hw]"

test.log
test_dbg.log

sranger wrote

Requesting a GL2 context directly works fine; it just doesn't do anything that isn't GL2 specific

Does it mean that that it uses only GL2 specific features and not in GL3?

That's what it looks like its doing. If I request a GL2 context, our applications start without the "Not a GL2 implementation" exception but anything we do that isn't GL2 specific (shader-based point size, for example) doesn't seem to work.

sranger wrote

How do I verify that it does or does not support a backwards-compatible context? (I've also attached the logs)

EDIT: the test.log says "GL3bc false" so I'm assuming jogl doesn't believe it's supported. Is there a way I can verify that outside of jogl?

Jogl has thorough probed your driver and it is not supported.
you can look inside the test_dbg.log where Jogl probes if the various opengl function calls actually exist and the list of extensions exposed for each context.
If it was supported then your driver should have GL_ARB_compatibility in its list of supported extensions.

EDIT: Mesa 3D has decided not to implement GL_ARB_compatibility, thus it is unlikely to ever see backward compatible supported by the opensource radeon driver.
http://www.phoronix.com/scan.php?page=news_item&px=MTE3MzA
http://lists.freedesktop.org/archives/mesa-dev/2012-August/026624.html

sranger wrote

Though, it also says "GL4 false" which I know is untrue unless the open source radeon drivers don't support it.

This is correct.
Mesa3D do not yet have full OpenGL 4 support for their radeon driver.
Mesa3D radeon driver currently only have full support up to OpenGL 3.3
Thus the only way to use "4" features is to probe if the functionality is available using using the 3.3 context.
http://mesamatrix.net/
http://www.phoronix.com/scan.php?page=news_item&px=mesa-10.5-branched-opengl

sranger wrote

Also, it says "GL2GL3 GLProfile[GL2GL3/GL3.hw]" but if I request a GL2GL3 profile, I'm given "GLProfile[GL3/GL3.hw]"

test.log
test_dbg.log

GL2GL3 Interface containing the common subset of core GL3 (OpenGL 3.1+) and GL2, also known as the OpenGL 3.0 forward compatible, non deprecated subset.
This interface reflects only the programmable shader functionality of desktop OpenGL

in your case this interface is handled by your GL3 hardware driver that uses the core profile.
http://jogamp.org/deployment/jogamp-current/javadoc/jogl/javadoc_jogl_spec/com/jogamp/opengl/GL2GL3.html
http://jogamp.org/jogl/doc/Overview-OpenGL-Evolution-And-JOGL.html

Thank you for providing the logs.

Thanks for all the info. It then looks like, without the AMD driver (which is in Ubuntu but segfaults on my machine), the backwards compatible FFP context isn't going to be happening anytime soon, if ever.

Well, it's an answer, though not the one I was hoping for. Thanks again for all your patience.

sranger wrote

Thanks for all the info. It then looks like, without the AMD driver (which is in Ubuntu but segfaults on my machine), the backwards compatible FFP context isn't going to be happening anytime soon, if ever.

Well, it's an answer, though not the one I was hoping for. Thanks again for all your patience.

Backward compatible profile is dropped on proprietary Mac OS X drivers as well.

Both AMD and NVIDIA only support their latest GPU cards using the proprietary drivers.
NVIDIA has dropped support for all pre-Fermi (GTX 4XX) graphics cards in their latest driver
http://www.phoronix.com/scan.php?page=news_item&px=SteamOS-159-NVIDIA-Drop
AMD has dropped support for all pre-radeon HD 5000 Series GPU cards.
http://support.amd.com/en-us/kb-articles/Pages/AMDCatalystOmegaLINReleaseNotes.aspx

Thus if you have a GTX 300 NVIDIA , AMD HD 4000 or some other 5year old  GPU card then the only supported driver is the opensource Mesa3D driver.

This is the reason why the latest AMD drivers do not work on your GPU because AMD has removed support for all cards older than 5 years.
EDIT: in your case it looks like the proprietary catalyst linux driver never have added support for the high end FirePro W8100 GPU :/

Yes, the new AMD beta driver that was added to Ubuntu 15.04 to support Xorg 1.17 doesn't seem to work with my W8100. Hopefully it gets rectified soon.

sranger wrote

Yes, the new AMD beta driver that was added to Ubuntu 15.04 to support Xorg 1.17 doesn't seem to work with my W8100. Hopefully it gets rectified soon.

Please try generate a test_dbg.log using the latest AMD beta driver that was added to Ubuntu 15.04
in some situations we may workaround initialization and termination bugs if the crash happens deterministic for some usecases.

Xerxes Rånby wrote

GL2GL3 Interface containing the common subset of core GL3 (OpenGL 3.1+) and GL2, also known as the OpenGL 3.0 forward compatible, non deprecated subset.
This interface reflects only the programmable shader functionality of desktop OpenGL

in your case this interface is handled by your GL3 hardware driver that uses the core profile.

That's what I thought but your English is better than mine. Thanks.