[Mesa-dev] [PATCH 2/2] gallium: expose ARB_map_buffer_alignment on Radeon
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).
More information about the mesa-dev