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

Marek Olšák maraeo at gmail.com
Fri Jan 18 07:40:19 PST 2013


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.

Marek


More information about the mesa-dev mailing list