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

[Marek Olšák]

On Mon, Feb 1, 2016 at 3:51 PM, Miklós Máté <mtmkls at gmail.com> wrote:
> On 12/19/2015 12:24 AM, Marek Olšák wrote:
>>
>> 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
>
> I'm ready to post v2 of my patch series, except this one (well, I haven't
> been able to tackle any of the 3 problems mentioned in 00/11 either, but
> those are a different story).
>
> Quick recap: the problem is that KotOR uses a series of pbuffers to draw its
> post-process effects, but their visuals (depth=0, stencil=0 because they are
> not specified in the attrib list) are incompatible with the gl context, so
> the gl calls are no-op, and it blits back uninitialized data onto the final
> image.
>
> I found 3 ways to work around this issue (tested with radeonsi), but I can't
> decide which one is the smallest/acceptable hack:
>
> 1. remove the compatibility check in main/context.c (this is what patch
> 05/11 does) -- honestly I don't know why ctx needs a visual, it should be
> sufficient to use the visual of the currently bound buffer; moreover, I
> couldn't find these compatibility criteria in the glX specification
>
> 2. in src/glx/glxcmds.c fbconfig_compare(): use PREFER_LARGER() for depth
> and stencil -- this violates the glX specification, but it makes
> glXChooseFBConfig() return a list that starts with a config that is
> compatible with the ctx (KotOR uses the first config from the list)
>
> 3. in gallium/state_trackers/dri/dri_screen.c dri_fill_in_modes(): disable
> all the modes that are not z24s8 -- this is probably the worst option,
> because z32 must also be disabled or it gets chosen over z24s8 (BTW is it
> really necessary to advertise 600 fbconfigs? fglrx only has about 50)

No, we don't need 600 fbconfigs.

We can also add an app-specific workaround and add it into drirc.

Marek