Ian Romanick <i...@freedesktop.org> writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/03/2013 10:44 AM, Eric Anholt wrote: >> Siavash Eliasi <siavashser...@gmail.com> writes: >> >>> Hello, this is V2 series of patches to accomplish *Enable >>> ARB_map_buffer_alignment in all drivers* newbie project suggested >>> by Ian Romanick. >> >> I think there's a piece missing to this, which is this bit of spec >> text: >> >> "If no error occurs, the pointer value returned by MapBufferRange >> must reflect an allocation aligned to the value of >> MIN_MAP_BUFFER_ALIGNMENT basic machine units. Subtracting <offset> >> basic machine units from the returned pointer will always produce a >> multiple of the value of MIN_MAP_BUFFER_ALIGNMENT." >> >> In i965's intel_bufferobj_map_range, range_map_bo or >> range_map_buffer mappings won't have that alignment. > > Yeah... I had forgotten about that when I originally posted the > project. There are a couple ways we could handle it. The one that > occurred to me first is to modify _mesa_MapBufferRange to only call > ctx->Driver.MapBufferRange with a properly aligned offset (and do the > fix-up on the pointer before storing it in gl_buffer_object::Pointer). > We don't have to worry about gl_buffer_object::Offset being rounded > because, as far as I can tell, it's not visible to applications. We'd > just have to make sure that each driver's UnmapBuffer implementation > only uses Offset and not Pointer. > > Does that sound sensible?
No, because expanding someone's range with the INVALIDATE_RANGE flag would produce incorrect results. You just have to fix the implementations to know about the extension.
pgpdQ8NfRXWFk.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
