Hi Dave,
I think Keith is right. It's very likely that some application will use the
same slow path u_blitter uses, so it makes sense to fix it in the driver
instead. I believe r300g has exactly the same problem, we just manage to
hide it for u_blitter by overriding the u_blitter::draw_rectangle c
On 11/23/2010 05:06 AM, Dave Airlie wrote:
> Hi Marek,
>
> So I was looking at some perf traces from r600g, and I see a stall on
> the blitter quad vbuf, every clear will cause the CPU to block on the
> mapping of the vbuf to upload the new coords. On r300g I can see this
> not mattering as the im
On Mon, 2010-11-22 at 20:06 -0800, Dave Airlie wrote:
> Hi Marek,
>
> So I was looking at some perf traces from r600g, and I see a stall on
> the blitter quad vbuf, every clear will cause the CPU to block on the
> mapping of the vbuf to upload the new coords. On r300g I can see this
> not matterin
Hi Marek,
So I was looking at some perf traces from r600g, and I see a stall on
the blitter quad vbuf, every clear will cause the CPU to block on the
mapping of the vbuf to upload the new coords. On r300g I can see this
not mattering as the immediate upload path takes care of things,
however I thi
