[Bug 68524] radeonsi with glamor has very poor performance with primitives drawing

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=68524

--- Comment #38 from Aaron Watry <awatry at gmail.com> ---
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-driver-ati/attachments/20140110/70067dd0/attachment.html>