[Mesa-dev] [PATCH 05/11] [RFC] mesa: allow binding framebuffer without depth&stencil

Marek Olšák maraeo at gmail.com
Fri Dec 18 15:24:00 PST 2015


On Fri, Dec 18, 2015 at 11:45 PM, Miklós Máté <mtmkls at gmail.com> wrote:
> On 12/17/2015 01:06 PM, Marek Olšák wrote:
>>
>> On Wed, Dec 16, 2015 at 11:30 PM, Miklós Máté <mtmkls at 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?

Yes. If reordering the FBConfigs fixes the issue, it would be an
acceptable workaround I think.

Marek


More information about the mesa-dev mailing list