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

[Christian König]

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.

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

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.

Christian.