We also had a case when the CPU accidentally corrupted shaders, because the shaders were mapped after textures and a CPU texture upload overflowed and overwrote shaders. I suppose we should have unmapped the shaders.
Marek On Wed, Jan 21, 2015 at 12:31 PM, Christian König <deathsim...@vodafone.de> wrote: > In general I don't think that modifying shader code with the GPU is such a > good idea. We already had quite a number of occasions where the GPU > accidentally corrupted the shader data which usually leads to lockups. > > Because of this I already wanted to suggest that everything that the GPU > executes (e.g. Rings, IB, shader etc...) is only mapped readonly into the > GPU address space. > > Regards, > Christian. > > Am 21.01.2015 um 12:20 schrieb Marek Olšák: >> >> On Wed, Jan 21, 2015 at 3:03 AM, Michel Dänzer <mic...@daenzer.net> wrote: >>> >>> On 20.01.2015 22:39, Marek Olšák wrote: >>>> >>>> The problem with CPDMA (DMA_DATA and WRITE_DATA) is that the ordering >>>> of flushes must be correct. First, partial flushes must be done, so >>>> that the shaders are idle. >>> >>> That's only necessary when reusing a single BO for the shader code, not >>> when allocating a new BO when the relocations change, right? >> >> Yes. >> >>> >>>> Then you can use CP DMA to update the binary. After that, ICACHE should >>>> be invalidated. >>> >>> ICACHE has to be invalidated when writing with the CPU as well, right? >> >> Yes, but the invalidation at the beginning of IBs is sufficient for >> all CPU accesses, so nothing needs to be done. >> >>> >>>> The problem with mapping VRAM can be avoided by keeping a CPU copy of >>>> the binary from the beginning. We would only need a CPU copy of those >>>> shaders that use the scratch buffer. Then, you wouldn't have to read >>>> VRAM at all, which would make it even simpler. >>> >>> Right, but CPU writes to the new BO in VRAM could cause stalls anyway. >> >> If CPU writes are the problem, we can create a temporary BO in GTT, >> upload and update the shader there, and copy it to the shader BO in >> VRAM using CPDMA. In this case, the shader BO in VRAM doesn't have to >> be reallocated, and shader state doesn't have to be re-emitted. Only >> the ICACHE should be flushed after CPDMA. >> >> One copy packet is better than a lot of small WRITE_DATA packets. >> >> Marek >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
