1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
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
|
