On 08/10/2017 05:20 AM, Michel Dänzer wrote:
On 09/08/17 06:53 PM, Thomas Hellstrom wrote:
We shouldn't be using GLX tokens in the dri subsystem, so define dri
SWAP_METHOD tokens and translate when necessary. Unfortunately the X server
uses the dri swap method value untranslated as the GLX fbconfig swapMethod,
so we can't enumerate these tokens arbitrarily, but rather need to make them
have the same values as the corresponding GLX tokens.

Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>

diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
index 406e97d..1d9f441 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -156,7 +156,8 @@ dri_fill_in_modes(struct dri_screen *screen)
     boolean mixed_color_depth;
static const GLenum back_buffer_modes[] = {
BTW, does this array need to include __DRI_ATTRIB_SWAP_EXCHANGE as well,
or is it possible to use GLX_SWAP_EXCHANGE_OML anyway?

No it's not. I have a patch that adds __DRI_ATTRIB_SWAP_EXCHANGE for dri3 only (that's when the DRI driver / state tracker is initialized with the image loader extension) but still it doesn't get advertised since the advertised direct rendering fbconfigs are a subset only of the AIGLX exported fbconfigs, and AIGLX doesn't use the image loader extension / dri3 path. See the following email thread for more insight on this:


As agreed in that thread, that should probably be remedied by rewriting the GLX fbconfig selection code so that the DRI startup decides what fbconfigs should be exported and the GLX code only makes sure there is a matching visual if needed. Since my primary motivation for doing these changes is to be able to run glretrace with GLX_SWAP_COPY_OML enabled, actually advertising GLX_SWAP_EXCHANGE_OML has lower priority ATM, but I'll try to do that at some point.

For the record, though, the code was tested with me unconditionally adding __DRI_ATTRIB_SWAP_EXCHANGE for both server and client and using a fixed version of piglit glx-swap-exchange (posted on the piglit list).



mesa-dev mailing list

Reply via email to