[Mesa-dev] [PATCH V2 00/17] Newbie Project : Enable ARB_map_buffer_alignment in all drivers

Eric Anholt eric at anholt.net
Mon Dec 9 16:58:23 PST 2013


Ian Romanick <idr at freedesktop.org> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/03/2013 10:44 AM, Eric Anholt wrote:
>> Siavash Eliasi <siavashserver at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131209/0ce0c2b3/attachment.pgp>


More information about the mesa-dev mailing list