glmark2

glmark2 sorts EGL_BUFFER_SIZE backwards when matching EGL configs

Bug #1264257 reported by Daniel Kurtz
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
glmark2
New
Undecided
Unassigned

Bug Description

By default, glmark2 initializes its target visual_config_ to 'r=1:g=1:b=1:a=1:buf=1:d=1:s=0' - that is, all components == 1, except the stencil size, which is 0. It then uses this target visual_config_ to (a) set the attributes for calling eglChooseConfig() and (b) score the resulting list of EGLConfigs. Note, however, that it doesn't actually send EGL BUFFER SIZE=buf to eglChooseConfig() in (a), but only uses it in (b), when scoring the configs.

I have an OpenGL ES 2.0 system with 7 EGL Configs for EGL_SURFACE_TYPE = WINDOW:
glmark2 will list the configs it finds for an all-zero --visual-config:

$ DISPLAY=:0 glmark2-es2 --validate --debug --visual-config 'r=0:g=0:b=0:a=0:buf=0:d=0:s=0' -b build:use-vbo=true

Debug: cfg buf rgb colorbuffer dp st config native support surface sample
Debug: id sz lum r g b a th cl caveat render visid type buf ns
Debug: ------------------------------------------------------------------------
Debug: 0x9 24 rgb 8 8 8 0 0 0 None false 0x21 0x407 0 0
Debug: 0xa 24 rgb 8 8 8 0 24 8 None false 0x21 0x407 0 0
Debug: 0xb 24 rgb 8 8 8 0 24 8 None false 0x21 0x407 1 4
Debug: 0x1 32 rgb 8 8 8 8 0 0 None false 0x47 0x407 0 0
Debug: 0x2 32 rgb 8 8 8 8 24 0 None false 0x47 0x407 0 0
Debug: 0x3 32 rgb 8 8 8 8 24 8 None false 0x47 0x407 0 0
Debug: 0x4 32 rgb 8 8 8 8 24 8 None false 0x47 0x407 1 4

If I request --visual-config 'alpha=0', the EGL will return all Window EGL Configs with depth buffers:
Debug: cfg buf rgb colorbuffer dp st config native support surface sample
Debug: id sz lum r g b a th cl caveat render visid type buf ns
Debug: ------------------------------------------------------------------------
Debug: 0xa 24 rgb 8 8 8 0 24 8 None false 0x21 0x407 0 0
Debug: 0xb 24 rgb 8 8 8 0 24 8 None false 0x21 0x407 1 4
Debug: 0x2 32 rgb 8 8 8 8 24 0 None false 0x47 0x407 0 0
Debug: 0x3 32 rgb 8 8 8 8 24 8 None false 0x47 0x407 0 0
Debug: 0x4 32 rgb 8 8 8 8 24 8 None false 0x47 0x407 1 4
Debug:
Debug: Best EGLConfig ID: 0x2

Note that the EGL implementation on this machine (ARM Mali) appears to sort the EGL configurations in the proper sort order (per OpenGL ES 2.0 spec 1.4 [0]). In particular, they are sorted:
 (1) in decreasing order of the sum of EGL_RED_SIZE+ EGL_BLUE_SIZE + EGL_GREEN_SIZE (since the requested a=0, the config's EGL_ALPHA_SIZE is not summed). For these configs, this value is alway 24.
 (2) in increasing order of EGL_BUFFER_SIZE = EGL_RED_SIZE+ EGL_BLUE_SIZE + EGL_GREEN_SIZE + EGL_ALPHA_SIZE. For these configs, there are 2 24-bit configs, and 3 32-configs.
 (3) in increasing order of EGL_CONFIG_ID

[0] http://www.khronos.org/registry/egl/specs/eglspec.1.4.withchanges.pdf

So, by EGL sort rules, EGLConfig ID: 0xa is first, however, glmark2 is choosing "Best EGLConfig ID: 0x2". Why?

Well, glmark2 scores all components in [r,g,b,a,d,s,buf] by the with the function GLVisualConfig::score_component(int component, int target, int scale). For the case where both the component and target are non zero there is the following comment:
        /*
         * Reward deeper than requested component values, penalize shallower
         * than requested component values. Because the ranges of component
         * values vary we use a scaling factor to even them out, so that the
         * score for all components ranges from [0,MAXIMUM_COMPONENT_SCORE).
         */
        score = scale * (component - target);

Thus, a greater EGL_BUFFER_SIZE is scored higher than a lower one, which is backwards from EGL sort order. The same is true for the depth and stencil components. According to EGL, all three of these attributes are: "Selection Criteria: AtLeast; SortOrder: Smaller".

Revision history for this message
Jesse Barker (jesse-barker) wrote :

I think the key here is that glmark2 eschews any configs with a stencil component (because there are no scenes currently that make use of stencil buffers). So, the key line (just a few lines below the excerpt from GLVIsualConfig::match_score() you included) is the following:

    score += score_component(stencil, target.stencil, 0);

This will add '-1000' to the score for any config that has a stencil component, and thus bump it well down the list of "preferred" configs. If this is causing you problems for other reasons (e.g., the implementation in question exposes other features only in configs with a stencil component), let us know, and we can look into changing it. For your immediate purposes, if you change the '0' to a '1' in that line, you should see the behavior you are asking for.

cheers,
Jesse

Revision history for this message
Daniel Kurtz (djkurtz) wrote :

Hi Jesse,
Thanks for responding, and sorry for the late reply. I've been trying to find a time to test out what you said.

What you said is true. Configs with stencil != 0 have a -1000 (UNACCEPTABLE_COMPONENT_PENALTY), and configs with stencil == 0 receive 32 (MAXIMUM_COMPONENT_SCORE). Unfortunately, just changing the stencil scale from 0 to 1 as you suggested doesn't affect these two score values.

localhost ~ # glmark2-es2 --validate --debug -b build:use-vbo=false --visual-config 'a=0'
Info: target rgba: {1 1 1 0} depth: 1 stencil: 0 buffer: 1
Info: config rgba: {8 8 8 0} depth: 24 stencil: 8 buffer: 24 => score: = {28 28 28 32} 23 -1000 23 == -838
Info: config rgba: {8 8 8 0} depth: 24 stencil: 8 buffer: 24 => score: = {28 28 28 32} 23 -1000 23 == -838
Info: config rgba: {8 8 8 0} depth: 24 stencil: 8 buffer: 24 => score: = {28 28 28 32} 23 -1000 23 == -838
Info: config rgba: {8 8 8 8} depth: 24 stencil: 0 buffer: 32 => score: = {28 28 28 -1000} 23 32 31 == -830
Info: config rgba: {8 8 8 8} depth: 24 stencil: 8 buffer: 32 => score: = {28 28 28 -1000} 23 -1000 31 == -1862
Info: config rgba: {8 8 8 8} depth: 24 stencil: 8 buffer: 32 => score: = {28 28 28 -1000} 23 -1000 31 == -1862
Info: config rgba: {8 8 8 8} depth: 24 stencil: 8 buffer: 32 => score: = {28 28 28 -1000} 23 -1000 31 == -1862

For my depth != 0 configs, all of the RGB ones have stencil=8. Only the first RGBA config has a 0 stencil size.
So, all the RGB configs have a -1000 penalty. However, the RGBA configs also have a -1000 penalty, since I am requesting a=0.
So, the tie-breaker is the "buffer size" field.
  For the RGB, buffer size is 24, which gives a score of (24-1) = 23.
  For the RGBA, buffer size is 32, which gives a score of (32-1) = 31.
This is where I think the bug is. The EGL spec says that the configs should be sorted in *increasing* order of buffer size, so 24 bit RGB buffers should be preferred over the larger 32-bit buffers. But, the scoring for buffer size is producing the opposite sort order.

By the way, why is glmark2 asking for an RGBA X visual by default, anyway?
Does it actually use the alpha channel for any of the tests?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.