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

[Martin Steigerwald]

According to KMail this went out as replay to all. Strange.

Am Donnerstag, 24. Januar 2013 schrieb 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