I've been working on getting accelerated indirect rendering working, and in the process I've come across 3 problems in mesa: - The DRI drawable destructor need to remove the drawable from the hash table so it isn't freed again during the drawable garbage collection. Conversely, the garbage collection shoudn't do this. In the direct rendering case this never happens, since we don't call the DRI drawable destructor directly, it's only invoked during the garbage collection. - _gl_copy_visual_to_context_mode() should set the mode->rgbBits and mode->indexBits corresponding to the actual mode, instead of setting both to config->bufferSize. - I've removed the xf86drm.h include from dri_interface.h since it isn't used by anything in the file. dri/common/dri_util.h includes xf86drm.h indirectly this way, but the patch adds and explicit include there. See also: bug 4988.
Created attachment 3947 [details] [review] Patch for problems mentioned above
I've checked in your changes to Mesa CVS, both the trunk and 6.4 branch.
(In reply to comment #0) > - _gl_copy_visual_to_context_mode() should set the mode->rgbBits and > mode->indexBits corresponding to the actual mode, instead of setting both to > config->bufferSize. There was a reason for doing it like this, but I don't recall what it was. There was a certain amount for fragility in that code with respect to getting the set of visuals sent by the server to match the set of fbconfigs returned by the client-side driver. I don't know if this is still an issue.
(In reply to comment #3) > (In reply to comment #0) > > > - _gl_copy_visual_to_context_mode() should set the mode->rgbBits and > > mode->indexBits corresponding to the actual mode, instead of setting both to > > config->bufferSize. > > There was a reason for doing it like this, but I don't recall what it was. > There was a certain amount for fragility in that code with respect to getting > the set of visuals sent by the server to match the set of fbconfigs returned by > the client-side driver. I don't know if this is still an issue. That was exactly the problem I was seeing on the server side. The visuals didn't match up in the server, but the problem was hidden on the client side by the fact t__glXInitializeVisualConfigFromTags() always initializes indexBits to 0.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.