Fix for T49945 - Linux AMD drivers UI glitches when Window Draw Method is set to automatic
AbandonedPublic

Authored by Edward O'Callaghan (funfunctor) on Nov 7 2016, 2:44 AM.

Diff Detail

Edward O'Callaghan (funfunctor) retitled this revision from to Fix for T49945 - Linux AMD drivers UI glitches when Window Draw Method is set to automatic.Nov 7 2016, 2:44 AM
Edward O'Callaghan (funfunctor) updated this object.

The intent here is to ensure within the function,

static int wm_automatic_draw_method(wmWindow *win)

the following falls though all the predicates to the else branch:

if (win->drawmethod == USER_DRAW_AUTOMATIC) {
        /* Windows software driver darkens color on each redraw */
        if (GPU_type_matches(GPU_DEVICE_SOFTWARE, GPU_OS_WIN, GPU_DRIVER_SOFTWARE))
                return USER_DRAW_OVERLAP_FLIP;
        else if (GPU_type_matches(GPU_DEVICE_SOFTWARE, GPU_OS_UNIX, GPU_DRIVER_SOFTWARE))
                return USER_DRAW_OVERLAP;
        /* drawing lower color depth again degrades colors each time */
        else if (GPU_color_depth() < 24)
                return USER_DRAW_OVERLAP;
        else
                return USER_DRAW_TRIPLE;
}
Sergey Sharybin (sergey) requested changes to this revision.Nov 8 2016, 10:07 AM

This doesn't seem to be a correct fix. It might fix one of your particular cases but it's logically incorrect and can cause breakage somewhere else.

This revision now requires changes to proceed.Nov 8 2016, 10:07 AM

This doesn't seem to be a correct fix. It might fix one of your particular cases but it's logically incorrect and can cause breakage somewhere else.

Alright, can you please elaborate on what exactly is illogical about it and where you expect breakage? Because right now its already broken.

Mesa is not necessarily supporting hardware acceleration and your change forces it to be considered a hardware accelerated. Can imagine it'll cause problems with blender-softwaregl at least, which is the way we troubleshoot OpenGL things. it might also cause issues with other hardware/driver configurations.

Some fine-grained checks here might solve your problem (like, consider Mesa AMD driver as non-software). Or if all drivers from out support period supports triple buffer without glicthes we should fix this on the WM level.

Mesa is not necessarily supporting hardware acceleration and your change forces it to be considered a hardware accelerated. Can imagine it'll cause problems with blender-softwaregl at least, which is the way we troubleshoot OpenGL things. it might also cause issues with other hardware/driver configurations.

Right, in mesa we provide a couple of fallback options here, softpipe and llvmpipe are typical configurations. How much they are "hardware" accelerated should not really be a concern unless you have serious performance issues with using one of these or we are missing a GL ext you perhaps need? I am not convinced either case applies here, however I could be wrong so I would be interested to hear otherwise.

Some fine-grained checks here might solve your problem (like, consider Mesa AMD driver as non-software). Or if all drivers from out support period supports triple buffer without glicthes we should fix this on the WM level.

OK, all mesa drivers should work with triple buffering afaik for quite a long time now. I think it would be worth trying to derive a counter example before creating all these possibly unnecessary edge cases that may not even exist.

This is not about performance in this case, it is about covering such extreme cases (as forced software fallback) with something which works when Automatic option is used.

Ideally we would go triple buffer default everywhere, but that's for blender2.8 branch, not for master.

For master we can do similar thing to this check. Not only this will solve your report, but it'll also enable Occlusion Queries selection method by default on new AMD Mesa driver (as far as i can follow GPU_select_query_check_active()).

This is not about performance in this case, it is about covering such extreme cases (as forced software fallback) with something which works when Automatic option is used.

So that is what I was saying above. In the case of software fallback we provide llvmpipe and softpipe, what is it exactly that is missing from these that stops you just treating all mesa drivers equally? Mesa should automatically deal with OpenGL software fallback for you, we will dispatch to the appropriate driver on the users platform so that you can still get a working GL context.

Ideally we would go triple buffer default everywhere, but that's for blender2.8 branch, not for master.

Do it.

For master we can do similar thing to this check. Not only this will solve your report, but it'll also enable Occlusion Queries selection method by default on new AMD Mesa driver (as far as i can follow GPU_select_query_check_active()).

Its not my problem, I don't use Blender! I have to deal with bug reports over at mesa from Blender problems..

My proposal is (based on safest way to go from compatibility and support point of views).

Add something like this to gpu_extensions_init() (modify it to match new AMD driver):

else if (strstr(renderer, "Mesa DRI R") || (strstr(renderer, "Gallium ") && strstr(renderer, " on ATI "))) {
  GG.device = GPU_DEVICE_ATI;
  GG.driver = GPU_DRIVER_OPENSOURCE;
}

Reasoning:

  • Can be applied to master already, without too worry about hardware compatibility break.
  • Will enable Occlusion Queries selection by default as well.

Everything else which potentially causes problems to existing users should happen in 2.8 branch (where we'll need to revisit all existing exceptions and so on).

Adding other developers who are interested in keeping Blender stable and working in this area.

Committed the safe short-term solution to master branch. Should avoid us wasting time in figuring out possible regressions on old cards which we still have to support there.

In 2.8 branch we'll switch to triple as the window draw mode sooner than later.