On 12/17/2015 01:06 PM, Marek Olšák wrote:
On Wed, Dec 16, 2015 at 11:30 PM, Miklós Máté <mtm...@gmail.com> wrote:
On 12/16/2015 05:27 PM, Marek Olšák wrote:
What is this good for?
Marek
KotOR uses a series of scratch framebuffers for drawing the framebuffer
effects. These have no depth and no stencil, so check_compatible() rejects
them, subsequent GL calls are no-op, and the screen becomes garbage. I also
experimented successfully with disabling the visuals that have no depth or
no stencil in gallium/state_trackers/dri/dri_screen.c, but I concluded that
this one was a smaller hack.
What kind of scratch buffer are we talking about? How is it created?
Marek
They are pbuffers, created like this:
glXChooseFBConfig(dpy = 0x7cbe2280, screen = 0, attribList =
[GLX_RED_SIZE, 8, GLX_GREEN_SIZE, 8, GLX_BLUE_SIZE, 8, GLX_ALPHA_SIZE,
8, GLX_DOUBLEBUFFER, False, GLX_DRAWABLE_TYPE, GLX_PBUFFER_BIT,
GLX_RENDER_TYPE, GLX_RGBA_BIT | GLX_COLOR_INDEX_BIT |
0xfffffffffffffffc, 0], nitems = [80])
glXGetFBConfigAttrib(dpy = 0x7cbe2280, config = 0x7ccf08a0, attribute =
GLX_FBCONFIG_ID, value = [104])
glXCreatePbuffer(dpy = 0x7cbe2280, config = 0x7ccf08a0, attribList =
[GLX_PBUFFER_WIDTH, 64, GLX_PBUFFER_HEIGHT, 64, 0])
Since depth is unspecified in the attrib list (I checked that if the
game had supplied WGL_DEPTH_BITS_ARB to wglChoosePixelFormatARB, Wine
would have added GLX_DEPTH_SIZE to the attrib list), the first fbconfig
is chosen that has 8 bits of r,g,b, which happens to be the very first
config in the list, and it has no depth or stencil.
I noticed that the list of visuals that glxinfo prints has two elements
prepended that look like a bugfix for a similar problem. Maybe that
would be the optimal solution in this case as well?
MM
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
