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
