Roland Scheidegger wrote:
> Jerome Glisse wrote:
>> How storing state will done is yet to be determined but the idea is that
>> finding state with a given id would have to be fast, very fast. Each
>> state class will have at much 64dword and i think that there will be
>> somethings around 30 differ
Jerome Glisse wrote:
> How storing state will done is yet to be determined but the idea is that
> finding state with a given id would have to be fast, very fast. Each
> state class will have at much 64dword and i think that there will be
> somethings around 30 differents class so this isn't much me
Garry Hurley wrote:
> Gentlemen, let me see if I understand this properly. You want to
> create a finite number of states, store them in a list and switch
> amongst them on a whim, right? If my understanding is correct, I am
> wondering how much data you are going to store in these states, and
>
Gentlemen, let me see if I understand this properly. You want to
create a finite number of states, store them in a list and switch
amongst them on a whim, right? If my understanding is correct, I am
wondering how much data you are going to store in these states, and
how many states you wish to cr
Keith Whitwell wrote:
> Jerome Glisse wrote:
>> Hi all,
>>
>> While playing with modesetting & ttm i have put some thought on how
>> we send
>> things to card. And i would like to test the following scheme:
>> -split card state into a bunch of separate chunk (z state, fog state,
>> ...)
>> -the d
Jerome Glisse wrote:
> Hi all,
>
> While playing with modesetting & ttm i have put some thought on how we send
> things to card. And i would like to test the following scheme:
> -split card state into a bunch of separate chunk (z state, fog state, ...)
> -the driver build the state it want and reg
