Hi Lucas, 2015-10-13 10:25 GMT+02:00 Lucas Stach <l.stach@xxxxxxxxxxxxxx>: > Am Mittwoch, den 30.09.2015, 09:53 +0200 schrieb Christian Gmeiner: >> Hi Lucas, >> >> 2015-09-28 12:39 GMT+02:00 Lucas Stach <l.stach@xxxxxxxxxxxxxx>: >> > Hi Christian, >> > >> > Am Montag, den 28.09.2015, 11:46 +0200 schrieb Christian Gmeiner: >> >> Hi Lucas. >> >> >> >> I think I have run into a cache flush / cache coherency issue. I will >> >> try to reproduce this issue with a small example and will >> >> keep you updated. >> > >> > What are the symptoms of the issue you are hitting? Maybe I can >> > reproduce or see if I have an idea right away. >> > >> >> With the help of the etnaviv_2d_test in my libdrm repo on github I was able >> to test different bo flags. >> >> ETNA_BO_UNCACHED and ETNA_BO_CACHED are working as expected. >> The rendering result looks as expected. If I try ETNA_BO_WC the rendering >> result looks different for every run. >> >> debian@cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1 >> Version: 1.0.0 >> Name: etnaviv >> Date: 20150910 >> Description: etnaviv DRM >> bo cpu prep: 0 >> debian@cubox:~/libdrm$ md5sum /tmp/etna.bmp >> 052880d433e1bf495e268206addd4087 /tmp/etna.bmp >> debian@cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1 >> Version: 1.0.0 >> Name: etnaviv >> Date: 20150910 >> Description: etnaviv DRM >> bo cpu prep: 0 >> debian@cubox:~/libdrm$ md5sum /tmp/etna.bmp >> f1a02a52d81c0b79b098877e6b7d9303 /tmp/etna.bmp >> debian@cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1 >> Version: 1.0.0 >> Name: etnaviv >> Date: 20150910 >> Description: etnaviv DRM >> bo cpu prep: 0 >> debian@cubox:~/libdrm$ md5sum /tmp/etna.bmp >> de5a428eb1f6567849ef40a944a995b8 /tmp/etna.bmp >> >> etna_cmd_stream_finish() waits until the submitted command stream was >> processed by the GPU. I tried to use etna_bo_cpu_prep(..) but I that did not >> help. >> >> I am doing something wrong? Should this work in theory? >> > For the record: this is caused by the "shared attribute override enable" > bit in the AUX_CTRL register of the PL310 cache controller not being > set, which makes it non-compliant with the ARMv7 ARM specified behavior > of conflicting memory aliases. > The etnaviv kernel driver makes sure to clean the cachable alias before > handing out the pages, but without this bit set the L2 controller will > turn the userspace bufferable reads into "cachable, no allocate" which > will lead to userspace hitting stale, non-evicted cache lines. > > This can be worked around by adding a "arm,shared-override" property to > the L2 cache DT node. This will only work if the kernel is booted in > secure state and will fault on a NS kernel. So this should be considered > a hack and the bootloader/firmware should make sure to set this bit. > Is the kernel able to detect this faulty environment? It would be great if we can warn the user about this issue and 'convert' all ETNA_BO_WC request to ETNA_BO_CACHED or ETNA_BO_UNCACHED. Else there might be some bug reports in the future where something is broken due to a bad environment and these kind of bugs are hard to sort out. greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
