https://bugs.freedesktop.org/show_bug.cgi?id=101596
Bug ID: 101596 Summary: Blender renders black UI elements Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: darkdefende@gmail.com QA Contact: dri-devel@lists.freedesktop.org
Created attachment 132251 --> https://bugs.freedesktop.org/attachment.cgi?id=132251&action=edit glxinfo output
It seems like a recent change to llvm or mesa broke blender on radeonsi. It works fine with llvm 4 and mesa 17.1.3.
Steps to reproduce:
1. Open the blender default cube scene.
2. Open the "N" panel by pressing N while your mouse cursor is in the 3d view.
3. Scroll down to the "Shading" tab and check "Matcap"
4. Now UI elements becomes black (and more and more will become black as you use the program)
See the attached screenshots
I should also point out that it is not only matcaps that triggers this. However, it is the fastest way to trigger this.
I have attached the output of glxinfo.
BTW, there is also a other long standing problem where you have to use tripple buffering in blender with radeonsi or the UI is messed up. I didn't find any bug for this either, but it has been a problem for a long time so I don't know if this is known?
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #1 from Sebastian Parborg darkdefende@gmail.com --- Created attachment 132252 --> https://bugs.freedesktop.org/attachment.cgi?id=132252&action=edit Blender before matcap
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #2 from Sebastian Parborg darkdefende@gmail.com --- Created attachment 132253 --> https://bugs.freedesktop.org/attachment.cgi?id=132253&action=edit blender after matcap
https://bugs.freedesktop.org/show_bug.cgi?id=101596
Sebastian Parborg darkdefende@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Hardware|Other |x86-64 (AMD64) OS|All |Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #3 from Sebastian Parborg darkdefende@gmail.com --- I've narrowed it down to this commit: https://cgit.freedesktop.org/mesa/mesa/commit/?id=56a28ace35c513ba22d7541921...
It seems like that is the one that breaks it.
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #4 from Matias N. Goldberg dark_sylinc@yahoo.com.ar --- +1 I get this error too.
This bug is NOT https://bugs.freedesktop.org/show_bug.cgi?id=97059 which gets fixed by either using DRI2 or selecting Triple Buffer in Blender.
This error started after I pulled latest git; and a faster way to reproduce it is to simply click on the Materials pane; where automatically everything starts going wrong within Blender.
I tried debugging the problem but came out short. My guess was either in the vertex shader's key.clamp_color would become true for the same variant where it used to be false, or that the same would happen in the pixel shader with clamp_color/persample_shading/ati_fs/external (i.e. test if any of st_fp_variant_key members changed but the same variant was being used).
However all shaders appear to be using consistent settings, which leaves me puzzled.
As Sebastian Parborg, undoing the changes "st_update_fp" fixes the problem.
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #5 from Matias N. Goldberg dark_sylinc@yahoo.com.ar --- Mystery solved:
When I click the material button, this function is hit:
1 st_get_fp_variant st_program.c 1326 0x7fbb34c5c595 2 get_color_fp_variant st_cb_drawpixels.c 963 0x7fbb34c0ae87 3 st_DrawPixels st_cb_drawpixels.c 1115 0x7fbb34c0b3ea 4 _mesa_DrawPixels drawpix.c 163 0x7fbb3499d954 5 ?? 0x55b9c4a159d5 6 ?? 0x55b9c4a15d20 7 ?? 0x55b9c4a3e15c 8 ?? 0x55b9c4a3f956 9 ui_draw_but 0x55b9c4a428cb 10 UI_block_draw 0x55b9c49f700a 11 UI_panels_draw 0x55b9c4a23ede 12 ED_region_panels 0x55b9c4b11bbd 13 ?? 0x55b9c484050e 14 ED_region_do_draw 0x55b9c4b10837 15 wm_draw_update 0x55b9c4817a96 16 WM_main 0x55b9c4813008 17 main 0x55b9c47d015e
get_color_fp_variant ends up calling st_get_fp_variant even though st->has_shareable_shaders is set; and st_get_fp_variant ends up creating a new variant.
st_get_fp_variant will create a new variant and add it to the front of the linked list: fpv->next = stfp->variants; stfp->variants = fpv;
Therefore later on st_update_fp thinks only one variant should be there, and tries to use the first one, which is the new one created by _mesa_DrawPixels; which is wrong, triggering all the glitches.
https://bugs.freedesktop.org/show_bug.cgi?id=101596
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maraeo@gmail.com
--- Comment #6 from Michel Dänzer michel@daenzer.net --- Marek, any ideas?
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #7 from Matias N. Goldberg dark_sylinc@yahoo.com.ar --- As I keep reading the code and getting familiar, everything starts making sense:
/** * If a shader can be created when we get its source. * This means it has only 1 variant, not counting glBitmap and * glDrawPixels. */ boolean shader_has_one_variant[MESA_SHADER_STAGES];
The problem is that after glDrawPixels creates its own variant; st_update_fp will end up using glDrawPixels' variant, instead of the non-glDrawPixels one.
The same problem happens if glBitmap is used.
One simple solution would be to add the variant to the end of the linked list, but this may affect the performance profile of radeonsi (i.e. assuming variations created last are more likely to be used than variations created first). The performance concerns can be negated by adding the variation to the end of the linked list ONLY if glDrawPixels or glBitmap is the caller.
https://bugs.freedesktop.org/show_bug.cgi?id=101596
Matias N. Goldberg dark_sylinc@yahoo.com.ar changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark_sylinc@yahoo.com.ar
--- Comment #8 from Matias N. Goldberg dark_sylinc@yahoo.com.ar --- Created attachment 132462 --> https://bugs.freedesktop.org/attachment.cgi?id=132462&action=edit Patch to fix bug
This patch fixes the problem by correctly handling glDrawPixel & glBitmap variations (both the cases where glDrawPixel was called before or after the standard variation has been generated), and fixes Blender.
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #9 from Sebastian Parborg darkdefende@gmail.com --- Thanks for fixing it, the patch seems to work nicely for me too.
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #10 from Michel Dänzer michel@daenzer.net --- Please send the patch to the mesa-dev mailing list for review.
https://bugs.freedesktop.org/show_bug.cgi?id=101596
Marek Olšák maraeo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #11 from Marek Olšák maraeo@gmail.com --- Pushed the fix as f728435e1f872af3efcd6b9215e8d722d35090cc. Closing.
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #12 from Matias N. Goldberg dark_sylinc@yahoo.com.ar --- Thank you for adding this commit despite my futile email!
I am getting up to speed with Mesa's patch submission process, but I wouldn't have had the time to fully read it until next week and resubmit the patch.
Thanks for taking the time to review it and include it!
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org