[Mesa-dev] [PATCH 2/2] gallium: expose ARB_map_buffer_alignment on Radeon

Ian Romanick idr at freedesktop.org
Mon Oct 29 12:19:41 PDT 2012

On 10/29/2012 11:41 AM, Marek Olšák wrote:
> On Mon, Oct 29, 2012 at 6:29 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 10/28/2012 09:55 AM, Marek Olšák wrote:
>> How does Gallium handle GL_WRITE_ONLY mappings of busy buffers?  In the
>> past, this would cause drivers to allocate a temporary buffer (of some sort)
>> and return that to the application.  In at least some cases, that temporary
>> buffer came from malloc... which might not meet the alignment requirement.
> It's up to Gallium drivers how they handle it. They can use
> align_malloc from u_memory.h. (r300g uses malloced indexed and vertex
> buffers on chipsets without TCL, a newer version of this patch adds
> align_malloc to several places in that driver)
> I think it's only legal to allocate a temporary buffer if one of the
> DISCARD(=INVALIDATE) flags is used.

Right... that's the easiest way to hit that path.  I had to do some 
archaeology to figure out how some other drivers did this in the past. 
There are two ways:

- Keep a (malloced) shadow copy of the VBO in system memory.

- Malloc a temporary buffer and read-out in the CPU memory.

I'm pretty sure NVIDIA did (does?) the first one for some buffers in 
some cases.  To make a long story short, we probably don't care about 
that for Mesa.  Sorry for that distraction.

> The plan for radeons is to allocate a temporary buffer in GTT (which
> is always aligned to the page size). On unmap, we will copy the
> temporary buffer to the busy one on the GPU. It's not clear to me how
> a malloced buffer can be used to implement a wait-free transfer (I can
> only imagine the malloced buffer is copied into the GPU command stream
> and the GPU will read it and copy it to the busy buffer).
> Marek

More information about the mesa-dev mailing list