diff options
Diffstat (limited to 'gfx/angle/src/libANGLE/renderer/gl/glx/FBConfigCompatibility.md')
| -rwxr-xr-x | gfx/angle/src/libANGLE/renderer/gl/glx/FBConfigCompatibility.md | 204 |
1 files changed, 204 insertions, 0 deletions
diff --git a/gfx/angle/src/libANGLE/renderer/gl/glx/FBConfigCompatibility.md b/gfx/angle/src/libANGLE/renderer/gl/glx/FBConfigCompatibility.md new file mode 100755 index 000000000..2343ad086 --- /dev/null +++ b/gfx/angle/src/libANGLE/renderer/gl/glx/FBConfigCompatibility.md @@ -0,0 +1,204 @@ +GLX Framebuffer Compatibility investigation +=========================================== + +In GLX and EGL, contexts are created with respect to a config that +describes the type of surfaces they will be used to render to. +Likewise surfaces are created with respect to a config and for +a context to be able to render to a surface, both their configs +must be compatible. Compatibility is losely described in both +the GLX and EGL specs but the following is clear: + * In GLX the config's color buffer must have the same type, including +RGBA vs. ColorIndex and the buffers must have the same depth, if they +exist. + * In EGL the config's color buffer must have the same type and the +buffers must have the same depth (not clear if it is only if they exist) + +Obviously the EGLconfig we will expose will have a one-to-one +correspondance with GLXFBConfigs. + +Our EGL implementation uses a single OpenGL context to back all +the EGLcontexts created by the application. Since our GL context +and GLXContext are the same object but in two APIs, we will make +the confusion and call the GLX context our backing context. + +The problem we have is that the the GLX context is created before +the application can choose what type of context it wants to use, +that means we have to expose EGLconfigs whose respective GLXFBConfigs +are compatible with the GLXFBConfig of our GLX context; we also need +to choose the GLXFBConfig of our GLX context so that it matches the +most common needs of application. + +Choice of the GLX context GLXFBConfig +------------------------------------- + +We decided that our GLX context's configuration must satisfy the following: + * Have a RGBA8 color buffer and D24S8 depth-stencil buffer which is what +the vast majority of applications use. + * It must render in direct colors, i.e. not in a color indexed format. + * It must be double-buffered (see later) + * It must support rendering to all the types of GLX surfaces so that we can +use it for all types of EGL surfaces + * It must have an associated visual ID so that we can use it with X, it seems +like this would be strongly tied to it having the ```WINDOW_BIT``` set. + * We would like a conformant context. + +Study of compatible GLXFBConfigs +-------------------------------- + +When using the condition of compatibility defined in the GLX spec and filtering +out the non-conformant GLXFBConfig we got the following list (see function +```print_visual_attribs_short``` in [glxinfo's source code](http://cgit.freedesktop.org/mesa/demos/tree/src/xdemos/glxinfo.c) +to understand how to read the table): + +``` + visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav + id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat Result +---------------------------------------------------------------------------- +0x02e 24 tc 0 32 0 r . . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None Fail +0x0e4 32 tc 0 32 0 r . . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None BadMatch +0x02c 24 tc 0 32 0 r y . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None Pass +0x0e2 32 tc 0 32 0 r y . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None BadMatch +0x089 24 dc 0 32 0 r . . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None Fail +0x087 24 dc 0 32 0 r y . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None Pass +0x026 24 tc 0 32 0 r . . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None Fail +0x0dc 32 tc 0 32 0 r . . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None BadMatch +0x024 24 tc 0 32 0 r y . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None Pass +0x0da 32 tc 0 32 0 r y . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None BadMatch +0x081 24 dc 0 32 0 r . . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None Fail +0x07f 24 dc 0 32 0 r y . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None Pass +``` + +The last column shows the result of trying to render on a window using the config, +with a GLX context using config 0x024. The first thing we see is that BadMatch is +thrown by the X server when creating the subwindow for rendering. This was because +we didn't set the border pixel of the subwindow *shake fist at X11* (see this [StackOverflow question](http://stackoverflow.com/questions/3645632/how-to-create-a-window-with-a-bit-depth-of-32)). +The result updated with this fix give: + +``` + visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav + id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat +---------------------------------------------------------------------------- +0x02e 24 tc 0 32 0 r . . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None Fail +0x0e4 32 tc 0 32 0 r . . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None Fail +0x02c 24 tc 0 32 0 r y . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None Pass +0x0e2 32 tc 0 32 0 r y . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None Pass +0x089 24 dc 0 32 0 r . . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None Fail +0x087 24 dc 0 32 0 r y . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None Pass +0x026 24 tc 0 32 0 r . . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None Fail +0x0dc 32 tc 0 32 0 r . . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None Fail +0x024 24 tc 0 32 0 r y . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None Pass +0x0da 32 tc 0 32 0 r y . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None Pass +0x081 24 dc 0 32 0 r . . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None Fail +0x07f 24 dc 0 32 0 r y . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None Pass +``` + +From this we see that our rendering test passed if and only if the config was double +buffered like 0x024 which is our GLX context config. The compatible configs are then: + +``` + visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav + id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat +---------------------------------------------------------------------------- +0x02c 24 tc 0 32 0 r y . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None +0x0e2 32 tc 0 32 0 r y . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None +0x087 24 dc 0 32 0 r y . 8 8 8 8 . s 4 0 0 16 16 16 16 0 0 None +0x024 24 tc 0 32 0 r y . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None +0x0da 32 tc 0 32 0 r y . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None +0x07f 24 dc 0 32 0 r y . 8 8 8 8 . s 4 24 8 16 16 16 16 0 0 None +``` + +We can see two dimensions, with our without a depth-stencil buffer and with TrueColor +or DirectColor. The depth-stencil will be useful to expose to application. + +More on double buffering +------------------------ +The tests above show that double-buffered contexts are not compatible with single- +buffered surfaces; however other tests show that single-buffered contexts are +compatible with both single and double-buffered surfaces. The problem is that in +that case, we can see some flickering even with double-buffered surfaces. If we +can find a trick to avoid that flicker, then we would be able to expose single +and double-buffered surfaces at the EGL level. Not exposing them isn't too much +of a problem though as the vast majority of application want double-buffering. + +AMD and extra buffers +--------------------- +As can be seen above, NVIDIA does not expose conformant context with multisampled +buffers or non RGBA16 accumulation buffers. The behavior is different on AMD that +exposes them as conformant, which gives the following list after filtering as +explained above: + +``` + visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav + id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat +---------------------------------------------------------------------------- +0x023 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 16 0 0 None +0x027 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +0x02b 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 2 1 None +0x02f 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 4 1 None +0x03b 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 16 0 0 None +0x03f 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +0x043 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 2 1 None +0x047 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 4 1 None +``` + +ANGLE's context is created using 0x027 and experimentation shows it is only compatible +with 0x03f which is the only other config lacking both an accumulation buffer and a +multisample buffer. The GLX spec seems to hint it should still work ("should have the +same size, if they exist") but it doesn't work in this case. Filtering the configs to +have the same multisample and accumulation buffers gives the following: + +``` + visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav + id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat +---------------------------------------------------------------------------- +0x027 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +0x03f 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +``` + +Mesa Intel driver +----------------- +In GLX, a criterium for context and surface compatibility is that buffers +should have the same depth, if they exist at all in the surface. This means +that it should be possible to make a context with a D24S8 depth-stencil +buffer to a surface without a depth-stencil buffer. This doesn't work on the +Mesa Intel driver. The list before the workaround was the following, with +0x020 being the fbconfig chosen for the context: + +``` + visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav + id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat +---------------------------------------------------------------------------- +0x020 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +0x021 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +0x08f 32 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +0x0d0 24 tc 0 32 0 r y . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None +0x0e2 24 dc 0 32 0 r y . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None +0x0e9 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +``` + +After the workaround that list becomes the following: + +``` + visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav + id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat +---------------------------------------------------------------------------- +0x020 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +0x021 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +0x08f 32 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +0x0e9 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None +``` + +Future investigation +-------------------- +All the non-conformant configs have a multisampled buffer, so it could be interesting +to see if we can use them to expose another EGL extension. + +Finally this document is written with respect to a small number of drivers, before +using the GLX EGL implementation in the wild it would be good to test it on other +drivers and hardware. + +The drivers tested were: + + - the proprietary NVIDIA driver + - the proprietary AMD driver + - the open source Intel (Broadwell) Mesa driver |