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

[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:
>
>> On Fri, Jan 18, 2013 at 2:46 PM, Christian König
>> <deathsimple at vodafone.de> wrote:
>>>
>>> Am 17.01.2013 23:54, schrieb Alex Deucher:
>>>
>>>> On Thu, Jan 17, 2013 at 12:32 PM, Michel Dänzer <michel at daenzer.net>
>>>> wrote:
>>>>>
>>>>> On Don, 2013-01-17 at 18:02 +0100, Michel Dänzer wrote:
>>>>>>
>>>>>> On Don, 2013-01-17 at 17:56 +0100, Marek Olšák wrote:
>>>>>>>
>>>>>>> Forking r600g was obviously a bad idea, because now radeonsi is just
>>>>>>> as horrible as r600g used to be.
>>>>>>
>>>>>> What do you suggest?
>>>>>
>>>>> That's an honest question, BTW. It's certainly becoming increasingly
>>>>> painful to port changes from r600g to radeonsi. The question is how we
>>>>> could start sharing at least some code again. E.g. the state handling
>>>>> has diverged quite a bit. Christian, any thoughts?
>>>>
>>>> Perhaps we could restructure things a bit and maybe add a few chip
>>>> specific function pointers and share a number of source files like we
>>>> do for the radeon/r200 (and formerly r300c/r600c).
>>>
>>>
>>> I think we should place more common code under
>>> src/gallium/drivers/radeon.
>>> For the unreleased code that I wrote for more than one chipset generation
>>> I
>>> even opened up a new directory under "src/gallium/drivers/".
>>>
>>> On the other hand the state handling between SI and previous generations
>>> needs to be quite a bit different (virtual memory and allocating space
>>> inside the IB), so merging those state handling things again might not be
>>> a
>>> practical approach.
>>
>> What is allocating space inside the IB? Right now, the r600g state
>> management and emission is pretty much the same as r300g, and I also
>> think the ideas applied there are completely hardware-independent.
>> What is so special about the SI hw that it needs something different
>> now?
>>
>> Also what does virtual memory have anything to do with it? Cayman has
>> virtual memory too.
>>
>> I think we should make new radeon_context a subclass of pipe_context
>> for the common code, and making r600_context and si_context subclasses
>> of radeon_context, the same for the screen, unless the evergreen and
>> SI code can co-exist just like r600, evergreen, and cayman do.
>
>
> 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)

>
> 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.

Marek