On 12/19/2015 12:24 AM, Marek Olšák wrote:
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).On Fri, Dec 18, 2015 at 11:45 PM, Miklós Máté<mtm...@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é<mtm...@gmail.com> wrote:On 12/16/2015 05:27 PM, Marek Olšák wrote:What is this good for?MarekKotOR 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? MarekThey 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
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)
I just filed bugreport #93955 with a test code about the first issue mentioned in 00/11; that test code also demonstrates this issue (see the comments in the code).
MM _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
