[Mesa-dev] [PATCH RFC v1] i965: Implement CopyTexSubImage2D via BLORP (and use it by default).

[Martin Steigerwald]

Am Sonntag, 20. Januar 2013 schrieb Paul Berry:
> > ---
> >
> >  src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 106
> >
> > +++++++++++++++++++++++++++
> >
> >  src/mesa/drivers/dri/i965/brw_context.h      |   8 ++
> >  src/mesa/drivers/dri/intel/intel_tex_copy.c  |  32 ++++++--
> >  3 files changed, 138 insertions(+), 8 deletions(-)
> >
> > Paul,
> > 
> > I'd appreciate your feedback on this patch.  It's my first time really
> > working with BLORP, so I'm bound to have screwed up something. :)
> > 
> > I'm not sure about the HiZ and downsample resolves (hence the //'d out
> > lines).
> 
> Your interaction with blorp looks good.  But I think there are some bugs
> in the resolves.  My rules of thumb for depth/HiZ resolves are:
> 
> - Resolves take care of the mismatch in access patterns between HiZ-aware
> components (i.e. the depth buffer bound to the rendering pipeline) and
> non-HiZ-aware components (texture units, blorp, and swrast).  After
> writing data using a HiZ-aware component and reading it using a
> non-HiZ-aware component, you need to do a depth resolve.  After writing
> data using a non-HiZ-aware component and reading it using a HiZ-aware
> component, you need to do a HiZ resolve.  For this determination,
> writing to a portion of the buffer (but not all of it) counts as both a
> write and a read.
> 
> - We do resolves at the last possible minute, so the way this is actually
> accomplished is to call
> intel_{miptree_slice,renderbuffer}_resolve_{depth,hiz} before
> reading/writing a buffer and
> intel_{miptree_slice,renderbuffer}_set_needs_{depth,hiz}_resolve after
> writing to a buffer.  The latter calls simply flag a future resolve as
> being necessary; the former calls do the resolve only if it was
> previously flagged.
> 
> I'll comment below on the specific changes I think are necessary.

I am currently testing this patch and I am the reporter of the spell effects 
slowness in Planeshift [1].

Can this lead to refresh issues like floating around triagnles on ground or 
so? Funnily I think I didn´t have these while SNA was enabled, but with SNA 
enabled I had some other wierd issues like high CPU usage for X.org.

Well I also put it the driver I compiled with mesa git master from fdo into 
a 9.0.1 debian package built. Maybe I have to use all of git master of mesa?

Anyway for spell effect speed this patch is a *huge* improvement.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=59086

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7