Page MenuHome

Radeon HD, MESA Linux Gallium r600, Light and Shadows Broken
Open, NormalPublic


System Information
Operating system: Ubuntu 18,10
Graphics card: Radeon HD 7600m
Drivers: MESA Devel 19 (there are better, but some problems on blender? on the drivers? must be solved)

Blender Version

blender-2.80-5e091de0dc6-linux-glibc224-x86_64 ( 30 october 2018)

Short description of error
Linux, Gallium r600, Mesa 19-devel, Light and Shadows Broken totally ..
ESM, VSM shadows not work,
Lights broken

see videos

I tried an 30 October build with the same drivers and it works (I do not have any more recent ones)
(ESM shadows only thing that did not work with these drivers with this build)

screenshot with the working well October 30 build



Event Timeline

Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.Dec 31 2018, 12:55 PM

Attach the output of --debug-gpu and also try if --debug-gpu-force-workarounds helps.

I tried ... no improvement with "debug - gpu - workaround" and does not produce any results in the console ...
probably these gpu workarounds are useful only for windows ..

with "debug - gpu" ... no improvement, but it produces these results in the console: that from ignorant they seem "clean" .. they do not produce errors in the console ..

I think they are visual errors, some algorithms that are not well interpreted .. maybe errors of mesa-gallium drivers that have different APIs to produce a certain result ....

in case I sent this bug report to the mesa drivers guys,
someone a few months ago there was dedicated and had greatly improved these drivers on this generation of video cards ...

now the problem with the shadows ESM and VSM has worsened ..
and the problem of lights emerged ..

I think that only someone who has these GPU with linux can solve this problem ..
perhaps communicating with the boys of MESA-devel Gallium ...

@Germano Cavalcante (mano-wii) this is bread for your teeth

Sebastian Parborg (zeddb) raised the priority of this task from Needs Information from User to Normal.Jan 1 2019, 1:58 AM

From the mesa ticket, this does sound like a driver issue. However, let's hope @Clément Foucault (fclem) can give us some more insight.

in case it may serve, this is the result of the apitrace as subjected here:
(note* are post made on 2018-08-13)

the file can be analyzed with the apitrace-gui app

noki paike (amonpaike) updated the task description. (Show Details)

I made a 6 minute video playing with blender and with the console "debug-gpu" in the foreground .. maybe it could be useful to investigate what happens

I think that only someone who has these GPU with linux can solve this problem ..
perhaps communicating with the boys of MESA-devel Gallium ...

@Germano Cavalcante (mano-wii) this is bread for your teeth

The videos are very descriptive and will definitely help!
However I use windows exclusively and I can't replicate the problem.
If Clément doesn't find out what is happening and the problem continues for a long time, I can switch to Linux to replicate and try to solve ;)

Come on, @Germano Cavalcante (mano-wii) put a Mint 19.1 in a flashusb and try what happens without installing anything on the hard disk ...

do not forget this if you have a laptop with two gpu like mine .. otherwise blender starts with the intel gpu

DRI_MODE=1 ./blender

for mesa-devel drivers updated daily ..
(mint is compatible with ubuntu but more friendly interface for windows users)

there is also the ppa padoka .. do not like it .. but on the page there is a list of many features that can be enabled via the console with the gallium drivers ... (also work with oibaf and maybe even with the official mesa)

@noki paike (amonpaike) Hello again.
It's been a while, I was really busy and when I actually had the chance to work with Blender, I used a 2.79.
In another thread ( you've asked me about this kind of viewport bugs. After long and uneven fight with the GPU on my laptop and finally switching it on (problems with oibaf ppa on mint 18.3) I can tell that Eevee renderer looks almost exactly like in the videos above, so... yeah they look glittering-crappy.


this^ suffix doesn't change anything actually.

Please let me know if I could help in any way. Seems like we're somewhat unique about the laptops we use for Blender ;) so maybe I can recreate some of your issues.
Please be patient with my noobie-ness.

My setup for now:
intel i5
HP Pavillion DV7 with Radeon 6770M
Linux Mint 19.1

Blender 2.8 build:


I'm a linux only user with an old AMD PC, experiencing the same problem.

System Information
Operating system(s): Ubuntu 17.10 and Ubuntu 18.04
CPU: AMD A10 5800K
RAM: 4x4GB DDR3 1600Mhz
Graphics card: (integrated graphics only: Trinity [Radeon HD 7660D])

Not long ago In another thread ( ) I've already posted the errors I'm getting with --debug-gpu-force-workarounds. Let me know If I can help.

@Wojtek (ototto)

Please let me know if I could help in any way.

in addition to the guys of blender to find some solution ...
I think that another way is to urge the boys of mesa devel in some way

good and bad news...

I've just tested the latest blender build with the latest mesa-devel driver..

the standard settings situation remained predominantly the same.
the good news is that if you launch blender with these parameters:
"DRI_PRIME=1 R600_DEBUG=nosb ./blender"
( DRI_PRME=1 ...My radeon gpu is a discrete GPU, and the R600_DEBUG=nosb disable the shader backend acceleration) blender with eevee works perfectly.

the bad news is that the performance goes fuckoff ..

so the problem is of the gallium drivers in particular of the shader compiler ...
in case anyone wants to test ... here some drivers parameters for


"nosb" Disable sb backend for graphics shaders
"sbcl" Enable sb backend for compute shaders
"sbdry" Do not use optimized bytecode (just print the dumps)
"sbstat" Print optimization for shaders
"sbdump" Print IR dumps after some optimization passes
"sbnofallback" Abort on errors instead of fallback
"sbdisasm" Use sb disassembler for shader dumps
"sbsafemath" Disable unsafe math optimisations


"tex" "Print texture info"
"texmip" Print texture info (mipmapped only)"
"compute" Print compute info
"vm" Print virtual addresses when creating resources
"trace_cs" Trace cs and write rlockup_<csid>.c file with faulty cs
"info" Print driver information

-SHADERS- (debugging)

"fs" Print fetch shaders
"vs" Print vertex shaders
"gs" Print geometry shaders
"ps" Print pixel shaders
"cs" Print compute shaders
"tcs" Print tessellation control shaders
"tes" Print tessellation evaluation shaders
"noir" Don't print the LLVM IR
"notgsi" Don't print the TGSI
"noasm" Don't print disassembled shaders


"nodma" Disable asynchronous DMA
"nohyperz" Disable Hyper-Z
"noinvalrange" (GL uses the word INVALIDATE, gallium uses DISCARD) Disable handling of INVALIDATE_RANGE map flags
"no2d" Disable 2D tiling
"notiling" Disable tiling
"switch_on_eop" Program WD/IA to switch on end-of-packet
"precompile" Compile one shader variant at shader creation
"nowc" Disable GTT write combining
"check_vm" Check VM faults and dump debug information
"llvm" Enable the LLVM shader compiler
"sisched" Enable the SI scheduler in the LLVM backend
"forcedma" Use asynchronous DMA for all operations when possible
"nocpdma" Disable CP DMA

if someone understands what happens with the damned shader backend compiler ... here the sources ...

in my opinion it is some trivial parameter wrongly interpreted, which breaks the proper functioning of lights and shadows in blender ...

without the acceleration backend shader, eevee's performances are really poor