https://bugs.freedesktop.org/show_bug.cgi?id=68524
--- Comment #38 from Aaron Watry <[email protected]> --- (In reply to comment #30) > (In reply to comment #27) > > Known caveats: Tiling needs to be disabled, as software fallbacks may now > > access the GPU buffers directly. > > On further thought, this may be a deal breaker for this approach. > > The only feasible way for improving performance of software fallbacks may be > via persistent separate storage for software fallbacks, with transfers of > changed pixels between that and the GPU accessible storage on demand, as is > done by EXA and SNA. Yeah, that's the shadow copy idea that I was talking about in a prior post. I guess that we're not doing that currently. I believe that catalyst keeps a cpu-side buffer and the gpu-side buffer to speed up map/unmap for read/write oeprations in the driver. Not sure if that's something that should be added to the drivers themselves, or if there's a way to handle it in glamor for all drivers. Might be complicated to code either way. (In reply to comment #27) > (In reply to comment #25) > > It's not amazingly fast this way, but it is a 10x performance improvement. > > That's a nice improvement in performance, but it's still an order of > magnitude slower than EXA, so I feel it would be better to either go > directly for full-blown shader-based acceleration of diagonal lines, or to > work on improving the performance of software fallbacks in general. Upon a good night's sleep I also had an idea for an improvement to my patch which might be worth doing. Currently, it reallocs the rects collection every time that it splits a line. We already pre-calculate the maximum number of rectangles that can be added by this method, so we might as well realloc to that size initially, and then trim the list at the end to reflect how many rectangles we actually added. I honestly don't know if remalloc (and the copies that it might trigger) is a bottleneck here, but it shouldn't hurt. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
