[Mesa-dev] RFC: ctx->Driver.Map/UnmapTextureImage() hooks

[Eric Anholt]

On Sat, 23 Jul 2011 11:58:22 -0600, Brian Paul <brian.e.paul at gmail.com> wrote:
> On Sat, Jul 23, 2011 at 9:14 AM, Eric Anholt <eric at anholt.net> wrote:
> > On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul <brianp at vmware.com> wrote:
> >> On 07/22/2011 01:32 PM, Eric Anholt wrote:
> >> > On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paul<brianp at vmware.com>  wrote:
> >> >>
> >> >> I'd like to overhaul the part of Mesa related to texture memory
> >> >> reading/writing.
> >> >
> >> > OK, I'm taking a look at map-texture-image-v4.  I like what I'm seeing
> >> > overall, I just want to be sure that this isn't something that gets
> >> > squash-merged.  There's going to be breakage, and I want to be able to
> >> > bisect into it.
> >> >
> >> > In the metaops code, please use glBufferData instead of
> >> > glBufferSubData.  If you BufferSubData, I have to block on the GPU if it
> >> > was using that buffer already.
> >>
> >> It looks like we'd have to change that in several other places too.
> >> Can we do that change later?
> >>
> >>
> >> > In the comments for void (*MapTextureImage), please note what the units
> >> > of rowStride are.  I see that's present in swrast later, but I think the
> >> > mtypes.h and dd.h files are used for reference a lot (I do, certainly).
> >>
> >> Will do.  The parameter comments in s_texture.c are out of date too.
> >>
> >>
> >> > c029312ad62039904818a8b1765c6bcdf50044df is huge, and it doesn't even
> >> > build.  Ouch.  I think there's some room for splitting some of this up
> >> > so that we can get a nice series.
> >>
> >> Where's the build breakage?  I don't remember that.
> >>
> >> This was originally a long series of sometimes ugly WIP patches.  At
> >> one point I had a git mishap and trashed some of the intermediate
> >> patches.  I agree that splitting up this commit would be good, but it
> >> would be a lot of work that I don't really have time for.
> >>
> >> It would be great if you could do a full piglit run with the branch
> >> and check for i965/i915 regressions.  I'm not aware of any with swrast
> >> or gallium.  I'd help diagnose any regressions.
> >
> > The piglit run was in bad shape and then hung the GPU, something that
> > piglit hasn't done for me in a long time.
> >
> > I think I'm going to need to split up the commits to make progress.
> 
> OK, I'll try to find some time to do a piglit run on my i945 and see
> what's up (I don't have a i965 handy).  I may not get to it for a few
> days though.

I'm cutting up your patches into a reasonable series so that we can
actually review and bisect the code.  So far I've run my mti-tested
branch on snb, and mti is your code I'm rebasing onto it as I cut chunks
out.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110727/edb1c580/attachment.pgp>