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

[Lucas Stach]

Am Mittwoch, den 03.08.2011, 22:55 -0700 schrieb Eric Anholt:
> On Wed, 27 Jul 2011 20:52:00 -0600, Brian Paul <brian.e.paul at gmail.com> wrote:
> > On Wed, Jul 27, 2011 at 7:29 PM, Eric Anholt <eric at anholt.net> wrote:
> > > 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.
> > 
> > Thanks for doing that.
> > 
> > I found that the map-texture-image-v4 branch is missing some stuff
> > that I lost during my git accident.  I think I'm nearly done restoring
> > it.  I'll push it to the branch asap, maybe tonight.
> 
> New mti-tested branch is up.  Splitting up commits has paid off for at
> least 3 regressions due to driver bugs so far that would have been awful
> to work out otherwise.  I'd like to land these bits before we try
> tackling the rest of this mess (particularly the move of fields to
> swrast didn't look like it was going to work for hardware driver
> fallbacks, the way it was done).  I'd also love to see some serious
> review of this code.
> 
> mti-tested is not regressing on intel.
> 
> radeon is down to 1 regression on the very tip commit now that I got
> some hardware -- gen-compressed-teximage fails because the GetTexImage()
> of the meta-decompressed texture returns garbage.
> 
> softpipe is thoroughly regressed, probably because I missed a required
> change there.  Just noticed it tonight, will look into it next.
> 
> I expect nouveau is rather broken for compressed textures, because I
> didn't catch it up to things I noticed while working on other drivers.
> I'm hoping I have some hardware that works (is gf 7600/7800 the right
> kind for this driver?), but I might not get to it before siggraph.

No, gf7xxx is nvfx generation and has only a gallium driver. To test the
vieux driver the newest card generation you could use is a geforce 4.

> 
> My DRI1 system is so slow and buggy that I'm having a hard time testing
> it.  This branch shouldn't break anything there as far as I can see, but
> I'll try again on testing.  Also, we could delete a bunch of dri1 driver
> code by implementing mapteximage in them instead.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev