Am 18.01.2013 20:29, schrieb Marek Olšák:
On Fri, Jan 18, 2013 at 5:20 PM, Christian König
<deathsim...@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.
Christian.
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
