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

[Alex Deucher]

On Fri, Jan 18, 2013 at 10:40 AM, Marek Olšák <maraeo at gmail.com> wrote:
> 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?

Resource and sampler descriptors are not stored in registers, they are
stored in memory on SI.  There is a special packet that allows us to
store the descriptors in the command buffer itself rather than in a
dedicated memory pool.  That way you can emit the descriptors in the
command stream and get the right address descriptor virtual propagated
to the shaders.

Alex