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

Brian Paul brian.e.paul at gmail.com
Wed Jul 27 19:52:00 PDT 2011


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.

-Brian


More information about the mesa-dev mailing list