On Tue, Oct 20, 2015 at 2:41 PM, Ben Widawsky <b...@bwidawsk.net> wrote: > On Tue, Oct 20, 2015 at 11:56:15AM +0200, Neil Roberts wrote: >> In bfdae9149e0 I disabled the opt_sampler_eot optimisation for TG4 >> message types because I found by experimentation that it doesn't work. >> I wrote in the comment that I couldn't find any documentation for this >> problem. However I've now found the documentation and it has >> additional restrictions on further message types so this patch updates >> the comment and adds the others. >> --- >> >> That paragraph in the spec also mentions further restrictions that we >> should probably worry about like that the shader shouldn't combine >> this optimisation with any other render target data port read/writes. >> >> It also has a fairly pessimistic note saying the optimisation is only >> really good for large polygons in a GUI-like workload. I wonder >> whether we should be doing some more benchmarking to decide whether >> it's really a good idea to enable this as a general optimisation even >> for games. > > I remember seeing this before, but I cannot find it now. All I am seeing > regarding performance implications are the bits about requiring a header, and > writing to the same pixel from multiple threads. The latter one I assume is > only > going to happen with MSAA?
No, I don't think so. As I understand it, the EUs can be executing fragment shaders for multiple primitives at the same time, and those primitives might overlap. The c in sendc means that it does some extra tracking to ensure that the render target writes land in the correct order. Presumably by using sendc to texture directly to the render target, it adds some extra synchronization (before the texturing is done... or something?) that especially hurts when there's a lot of overlapping primitives (as in the case of lots of small primitives). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
