Bug 1347 - Mapped GLProfile's (e.g. GL2ES2, GL2ES1) select software renderer GL2 instead of hardware renderer GLES1 & GLES2
Summary: Mapped GLProfile's (e.g. GL2ES2, GL2ES1) select software renderer GL2 instead...
Status: RESOLVED FIXED
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 2.4.0
Hardware: All all
: P4 normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2016-11-14 10:51 CET by Xerxes Rånby
Modified: 2019-12-28 04:21 CET (History)
3 users (show)

See Also:
Type: DEFECT
SCM Refs:
jogl e2223107cc54e08031bd9505ce8a9ccc72673be0
Workaround: ---


Attachments
ARM Mali EGL and Mesa GL at the same time on C.H.I.P. GLWindow log (24.58 KB, text/plain)
2016-11-14 10:51 CET, Xerxes Rånby
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xerxes Rånby 2016-11-14 10:51:55 CET
Created attachment 793 [details]
ARM Mali EGL and Mesa GL at the same time on C.H.I.P. GLWindow log

This bug is related to Bug1084

GLProfile's mapping code does not consider the following combination:
  - GL2 software
  - GLES1 hardware
  - GLES2 hardware

and hence maps GL2-software -> [GL2ES2, GL2ES1], 
where GLES2-hardware -> [GL2ES2]
      GLES1-hardware -> [GL2ES1] is desired.

This combination has recently been observed two embedded systems

C.H.I.P. using OS image 4.4
http://blog.nextthing.co/accelerate-your-3d-gaming-with-quake-iii-on-pocketc-h-i-p/ 

and 

ODROID-C rev 0.3 20141107 using its default system image

both systems includes Mesa3d software GL2 implementation and ARM Mali EGL GLES1 & GLES2 implementation.

However, other systems could be affected as well.
Comment 1 Julien Gouesse 2016-11-23 17:18:39 CET
Do you obtain GLES1 when calling GLProfile.getMaxFixedFunc(true)?
Comment 2 Gottfried Haider 2017-04-20 11:50:55 CEST
GLProfile.getMaxFixedFunc(true) returns GLES2 hardware
Comment 3 Gottfried Haider 2017-04-20 11:51:29 CEST
(just getGL2ES2() returns GL2 software)
Comment 4 Sven Gothel 2019-12-28 04:10:00 CET
GLProfile.computeProfileImpl(..) as of Bug 1084 is not the culprit here and its hardware criteria filter works.

The issue is commit 99a064327bf991318841c858d21d13e55d6b39db of Bug 1203,
in particular the change in GLProfile re:
"Merge computed EGL-Profile-Map (1) and Desktop-Profile-Map (2)
 per device, instead of just using the last computation,
 preserving and favoratizing the Desktop-Profile-Map."

Here the Desktop-Profile-Map overwrites the EGL-Profile-Map and hence 
the software mapping gets used.

Indeed, this is a regression cause by the work of Bug 1203.

+++

Resolution is to revert the explicit 'union mapping'
and rely on an enhanced 'GLContextImpl.remapAvailableGLVersions(fromDevice, toDevice)' function.
Here the EGLDrawableFactory _already_ maps the EGL device's GL Versions to the 'host' device (e.g. X11).
This has to be refined so that the remap will not overwrite the 'host' device's already detected GL Versions.

That alone is enough, so that GLProfile can simply use the 'mappedEGLProfiles' of the 'host' device if detected, which already is a merged mapping of X11 host- and EGL sub-device. 

In case no 'mappedEGLProfiles' are available, we simply use the 'mappedDesktopProfiles'.
Comment 5 Sven Gothel 2019-12-28 04:18:11 CET
jogl e2223107cc54e08031bd9505ce8a9ccc72673be0

fixed as described in comment 4