[Mesa-dev] [PATCH 6/6] radeonsi: Actually keep track if we are using depth textures for samplers.

Christian König deathsimple at vodafone.de
Mon Jan 21 01:43:00 PST 2013

Am 18.01.2013 20:29, schrieb Marek Olšák:
> On Fri, Jan 18, 2013 at 5:20 PM, Christian König
> <deathsimple at vodafone.de> wrote:
>> Am 18.01.2013 16:40, schrieb Marek Olšák:
>> [SNIP]
>> Having common base classes for all three radeon drivers sounds like a good
>> idea to me and sharing the texture code between r600g and SI also.
> Well, I'd like to keep r300g out of this. Even though a lot of r600g
> code is based on the same ideas now, the two have very
> different/incompatible codebases.
>> We just need to keep in mind that the PM4 state handling is quite a bit
>> different on the different generations:
>> 1. R300: IIRC nearly 100% register based state
>> 2. R600: Mostly register based, but also some specialized PM4 commands
>> (Streamout etc..)
>> 3. SI: Few registers and allot of specialized PM4 commands, sometimes even
>> with embedded data. And ontop of that a second command stream for preloading
>> data (not implemented yet).
> Whether the states are register-based or based on special packets
> doesn't matter at all. It's only about reserving enough space for
> state objects and other hw commands in a command stream and the
> mechanism must have very small overhead, which isn't the case with
> r600g yet, but we're getting there. (r300g is 20% faster than r600g if
> rendering is CPU-bound)

Well that sounds interesting, what is the r300g state handling doing 
better than the r600g version?

If I remember correctly at least that part of radeonsi should be pretty 
close to the optimum.

>> VM on Cayman is only optional, but on SI it is mandatory. So on SI we don't
>> have NOP packets for relocation for example and the state handling can be a
>> bit tighter, but on the other hand we need to deal with embedded data inside
>> the command stream.
> Both r300g and r600g embed indices inside the command stream in some cases.

Yeah, but that's quite a bit different to what radeonsi is doing. On SI 
we embed data that is referenced by scalar shader registers, which makes 
the resulting PM4 packet unrelocatable.


> Marek

More information about the mesa-dev mailing list