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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
