[Mesa-dev] [PATCH 2/6] r600g: Add r600_rat_buffer_create()

Marek Olšák maraeo at gmail.com
Mon Sep 24 08:54:15 PDT 2012


On Mon, Sep 24, 2012 at 4:06 PM, Tom Stellard <tom at stellard.net> wrote:
> Hi Marek,
>
> On Sat, Sep 22, 2012 at 05:31:51AM +0200, Marek Olšák wrote:
>> Hi Tom,
>>
>> First I'd like to say that even though I don't agree with the
>> direction you're taking, I'd be okay with it for initial bring-up of
>> the compute support.
>>
>> I am not in favor of using radeon_surface for plain untyped 1D
>> buffers, where the only thing that really matters is the buffer
>> alignment, right? I am also curious about what is so special about
>> radeon_surface that we need to use it to allocate the RAT buffers.
>>
>
> There are two reasons I went with the radeon_surface approach.
>
> First, is that I wanted to reuse as much of the current r600g code
> as possible.  When I first tried to get RATs working I had trouble
> manually programming the CB registers to satisfy the CS checker, and
> since using radeon_surface for emitting the CB registers was already
> implemented and well tested, it made sense to go with that approach.
> It may not be ideal, but there are other more critical parts of the
> compute stack that need work, so I wanted to come up with a working
> solution as quickly as possible.

I think proper CS checker support is inevitable and having it would be
the most secure and cleanest solution. You would also be able to avoid
emitting some useless registers that RATs don't need.

>
> Second, is that I thought in the future we might be able to take advantage
> of 2D tiling for compute buffers, so I wanted to keep that option open.

Tiling is efficient only if you can say the resource will be accessed
with 2D spatial locality (i.e. there is higher probability that the
next accessed sample will be on the same tile as the last one than on
the same row). I don't think we can assert that for 1D buffers.

Marek


More information about the mesa-dev mailing list