Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
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.p...@gmail.com wrote: On Wed, Jul 27, 2011 at 7:29 PM, Eric Anholt e...@anholt.net wrote: On Sat, 23 Jul 2011 11:58:22 -0600, Brian Paul brian.e.p...@gmail.com wrote: On Sat, Jul 23, 2011 at 9:14 AM, Eric Anholt e...@anholt.net wrote: On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul bri...@vmware.com wrote: On 07/22/2011 01:32 PM, Eric Anholt wrote: On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paulbri...@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Wed, 27 Jul 2011 20:52:00 -0600, Brian Paul brian.e.p...@gmail.com wrote: On Wed, Jul 27, 2011 at 7:29 PM, Eric Anholt e...@anholt.net wrote: On Sat, 23 Jul 2011 11:58:22 -0600, Brian Paul brian.e.p...@gmail.com wrote: On Sat, Jul 23, 2011 at 9:14 AM, Eric Anholt e...@anholt.net wrote: On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul bri...@vmware.com wrote: On 07/22/2011 01:32 PM, Eric Anholt wrote: On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paulbri...@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. 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. pgpDDg7ol3TQK.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Sat, 23 Jul 2011 11:58:22 -0600, Brian Paul brian.e.p...@gmail.com wrote: On Sat, Jul 23, 2011 at 9:14 AM, Eric Anholt e...@anholt.net wrote: On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul bri...@vmware.com wrote: On 07/22/2011 01:32 PM, Eric Anholt wrote: On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paulbri...@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. pgpcw1ygvH1bn.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Wed, Jul 27, 2011 at 7:29 PM, Eric Anholt e...@anholt.net wrote: On Sat, 23 Jul 2011 11:58:22 -0600, Brian Paul brian.e.p...@gmail.com wrote: On Sat, Jul 23, 2011 at 9:14 AM, Eric Anholt e...@anholt.net wrote: On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul bri...@vmware.com wrote: On 07/22/2011 01:32 PM, Eric Anholt wrote: On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paulbri...@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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul bri...@vmware.com wrote: On 07/22/2011 01:32 PM, Eric Anholt wrote: On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paulbri...@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. pgp8X0JTjO8bN.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Sat, Jul 23, 2011 at 9:14 AM, Eric Anholt e...@anholt.net wrote: On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul bri...@vmware.com wrote: On 07/22/2011 01:32 PM, Eric Anholt wrote: On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paulbri...@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. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paul bri...@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.
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).
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.
2025416f5090ee776a5c3291201f003e7c090718 -- if we're going to have
asserts that the array got initialized in the right order, I think I'd
rather see the array initialized by hand in an init function so that we
don't even need them (assuming tha the reason for this is that you're
still supporting compilers that don't do array[] = { [ELEMENT] = value,
}).
pgpG0r4Z0quum.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On 07/22/2011 01:32 PM, Eric Anholt wrote:
On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paulbri...@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.
I'd be happy to incorporate any fixes into a new map-texture-image-v5
branch before merging to master.
2025416f5090ee776a5c3291201f003e7c090718 -- if we're going to have
asserts that the array got initialized in the right order, I think I'd
rather see the array initialized by hand in an init function so that we
don't even need them (assuming tha the reason for this is that you're
still supporting compilers that don't do array[] = { [ELEMENT] = value,
}).
I could do that. But I think there's a few other places where we do
this. Inserting a new MESA_FORMAT_x in the middle of the enum list
would definitely cause breakage.
Thanks for reviewing.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On 07/15/2011 02:59 PM, Pekka Paalanen wrote: On Fri, 15 Jul 2011 12:22:41 -0600 Brian Paulbri...@vmware.com wrote: On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com wrote: The map-texture-image-v4 branch that I just pushed implements this change. It really cleaned things up for the better and will lead to a few more follow-on improvements. There's no obvious regressions with swrast or the gallium drivers. I updated the intel driver code and tested i915 and it seems OK too, but I didn't do a full piglit run on it. I also updated the legacy r600 driver in case anyone cares but didn't do any testing of it. I didn't update any of the other legacy DRI drivers. Would anyone object if we simply stop building mach64, r128, unichrome, sis, etc? I'd be happy to remove those drivers altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. Sounds good to me. I think we'd only keep the swrast, intel and maybe r300/r600 drivers. Opinions? Um, don't kill nouveau_vieux, please. Does the old nouveau driver support some GPUs that the gallium nv50/nvc0 drivers don't support? If we want to keep the older driver someone will need to volunteer to update the code to support the new driver hooks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
The classic nouveau driver supports nv04, nv1x, nv2x IIRC. I'm definitely not the right person for the job, but I'll look at it if nobody else can. ~ C. On Mon, Jul 18, 2011 at 7:09 AM, Brian Paul bri...@vmware.com wrote: On 07/15/2011 02:59 PM, Pekka Paalanen wrote: On Fri, 15 Jul 2011 12:22:41 -0600 Brian Paulbri...@vmware.com wrote: On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com wrote: The map-texture-image-v4 branch that I just pushed implements this change. It really cleaned things up for the better and will lead to a few more follow-on improvements. There's no obvious regressions with swrast or the gallium drivers. I updated the intel driver code and tested i915 and it seems OK too, but I didn't do a full piglit run on it. I also updated the legacy r600 driver in case anyone cares but didn't do any testing of it. I didn't update any of the other legacy DRI drivers. Would anyone object if we simply stop building mach64, r128, unichrome, sis, etc? I'd be happy to remove those drivers altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. Sounds good to me. I think we'd only keep the swrast, intel and maybe r300/r600 drivers. Opinions? Um, don't kill nouveau_vieux, please. Does the old nouveau driver support some GPUs that the gallium nv50/nvc0 drivers don't support? If we want to keep the older driver someone will need to volunteer to update the code to support the new driver hooks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On 07/18/2011 01:00 PM, Pekka Paalanen wrote: On Mon, 18 Jul 2011 08:09:17 -0600 Brian Paulbri...@vmware.com wrote: On 07/15/2011 02:59 PM, Pekka Paalanen wrote: On Fri, 15 Jul 2011 12:22:41 -0600 Brian Paulbri...@vmware.com wrote: On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.comwrote: The map-texture-image-v4 branch that I just pushed implements this change. It really cleaned things up for the better and will lead to a few more follow-on improvements. There's no obvious regressions with swrast or the gallium drivers. I updated the intel driver code and tested i915 and it seems OK too, but I didn't do a full piglit run on it. I also updated the legacy r600 driver in case anyone cares but didn't do any testing of it. I didn't update any of the other legacy DRI drivers. Would anyone object if we simply stop building mach64, r128, unichrome, sis, etc? I'd be happy to remove those drivers altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. Sounds good to me. I think we'd only keep the swrast, intel and maybe r300/r600 drivers. Opinions? Um, don't kill nouveau_vieux, please. Does the old nouveau driver support some GPUs that the gallium nv50/nvc0 drivers don't support? Yes. Like Corbin said, 'nouveau_vieux' is for NV04-NV2x, while the gallium driver 'nouveau' supports NV30 and later. http://nouveau.freedesktop.org/wiki/MesaDrivers If we want to keep the older driver someone will need to volunteer to update the code to support the new driver hooks. Sorry, I cannot promise that. Nouveau_vieux seems to have been missing a maintainer for some time now. Any of the older DRI drivers that get dropped could easily be revived later if someone wants to do the work. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paul bri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly when
glGetTexImage() returns texture data. swrast would also use these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers. I
updated the intel driver code and tested i915 and it seems OK too, but
I didn't do a full piglit run on it. I also updated the legacy r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis, etc?
I'd be happy to remove those drivers altogether for that matter.
we could EOL those in 7.11, and if anyone wants to ship them, they can
just build 7.11 for them.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On 07/15/2011 10:07 AM, Dave Airlie wrote:
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paulbri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly when
glGetTexImage() returns texture data. swrast would also use these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers. I
updated the intel driver code and tested i915 and it seems OK too, but
I didn't do a full piglit run on it. I also updated the legacy r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis, etc?
I'd be happy to remove those drivers altogether for that matter.
we could EOL those in 7.11, and if anyone wants to ship them, they can
just build 7.11 for them.
Sounds good to me. I think we'd only keep the swrast, intel and maybe
r300/r600 drivers. Opinions?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
- Original Message -
On 07/15/2011 10:07 AM, Dave Airlie wrote:
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com
wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paulbri...@vmware.com
wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI).
Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data.
Similarly when
glGetTexImage() returns texture data. swrast would also use
these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and
get rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I
think I'd like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead
to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers.
I
updated the intel driver code and tested i915 and it seems OK too,
but
I didn't do a full piglit run on it. I also updated the legacy
r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis,
etc?
I'd be happy to remove those drivers altogether for that matter.
we could EOL those in 7.11, and if anyone wants to ship them, they
can
just build 7.11 for them.
Sounds good to me. I think we'd only keep the swrast, intel and
maybe
r300/r600 drivers. Opinions?
Sounds good to me FWIW.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On 07/15/2011 11:22 AM, Brian Paul wrote:
On 07/15/2011 10:07 AM, Dave Airlie wrote:
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com
wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paulbri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly when
glGetTexImage() returns texture data. swrast would also use these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and
get rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think
I'd like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers. I
updated the intel driver code and tested i915 and it seems OK too, but
I didn't do a full piglit run on it. I also updated the legacy r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis, etc?
I'd be happy to remove those drivers altogether for that matter.
we could EOL those in 7.11, and if anyone wants to ship them, they can
just build 7.11 for them.
Sounds good to me. I think we'd only keep the swrast, intel and maybe
r300/r600 drivers. Opinions?
-Brian
Sounds good to me as well.
--Kenneth
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Fri, Jul 15, 2011 at 2:22 PM, Brian Paul bri...@vmware.com wrote:
On 07/15/2011 10:07 AM, Dave Airlie wrote:
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com
wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paulbri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly when
glGetTexImage() returns texture data. swrast would also use these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get
rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd
like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers. I
updated the intel driver code and tested i915 and it seems OK too, but
I didn't do a full piglit run on it. I also updated the legacy r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis, etc?
I'd be happy to remove those drivers altogether for that matter.
we could EOL those in 7.11, and if anyone wants to ship them, they can
just build 7.11 for them.
Sounds good to me. I think we'd only keep the swrast, intel and maybe
r300/r600 drivers. Opinions?
Maybe radeon and r200 as well for now. Most of the radeon code is
shared across the classic drivers.
Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Fri, 15 Jul 2011 12:22:41 -0600 Brian Paul bri...@vmware.com wrote: On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com wrote: The map-texture-image-v4 branch that I just pushed implements this change. It really cleaned things up for the better and will lead to a few more follow-on improvements. There's no obvious regressions with swrast or the gallium drivers. I updated the intel driver code and tested i915 and it seems OK too, but I didn't do a full piglit run on it. I also updated the legacy r600 driver in case anyone cares but didn't do any testing of it. I didn't update any of the other legacy DRI drivers. Would anyone object if we simply stop building mach64, r128, unichrome, sis, etc? I'd be happy to remove those drivers altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. Sounds good to me. I think we'd only keep the swrast, intel and maybe r300/r600 drivers. Opinions? Um, don't kill nouveau_vieux, please. -- Pekka Paalanen http://www.iki.fi/pq/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paul bri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly when
glGetTexImage() returns texture data. swrast would also use these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers. I
updated the intel driver code and tested i915 and it seems OK too, but
I didn't do a full piglit run on it. I also updated the legacy r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis, etc?
I'd be happy to remove those drivers altogether for that matter.
I probably won't merge this to master until after the 7.11 release
since a lot of code is touched and it might impede cherry picking. In
the mean time, I'd appreciate other people looking at the branch and
testing it. I probably won't have any more time for it until sometime
next week.
For a quick overview of the changes, do a git-diff on mtypes.h and dd.h
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paul bri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly
when glGetTexImage() returns texture data. swrast would also use
these before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get
rid of all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd
like to do these things step by step to avoid too much disruption.
I'm thoroughly in favor of this plan. Also, thanks for making stride in
bytes -- strides in pixels is one of the things I want to get rid of in
our driver.
pgpTcxXAwfmvk.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On 06/24/2011 11:27 AM, Eric Anholt wrote:
On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paulbri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly
when glGetTexImage() returns texture data. swrast would also use
these before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get
rid of all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd
like to do these things step by step to avoid too much disruption.
I'm thoroughly in favor of this plan. Also, thanks for making stride in
bytes -- strides in pixels is one of the things I want to get rid of in
our driver.
OK, I'll be on vacation next week but I hope to have some time to work
on this then.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly
when glGetTexImage() returns texture data. swrast would also use
these before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get
rid of all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd
like to do these things step by step to avoid too much disruption.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
