[Mesa-dev] [PATCH 6/6] radeonsi: Actually keep track if we are using depth textures for samplers.
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:
>> 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.
More information about the mesa-dev