Re: [r300] partly working fragment.position patch

[Rune P. <ru...@me...>]

Keith Whitwell wrote:
> Rune Petersen wrote:
>> Keith Whitwell wrote:
>>> Rune Petersen wrote:
>>>> Keith Whitwell wrote:
>>>>> Roland Scheidegger wrote:
>>>>>> Keith Whitwell wrote:
>>>>>> I think Rune is rather refering to the fact that you can't change
>>>>>> (not
>>>>>> with "legal" means at least) the constant you got with
>>>>>> _mesa_add_unnamed_constant.
>>>>> Ah right.  I missed that.
>>>>>
>>>>>> I think there exist at least 2 solutions for that. The clean way
>>>>>> would
>>>>>> probably be to add some more INTERNAL_STATE (like i965 driver
>>>>>> uses) so
>>>>>> you use _mesa_add_state_reference instead, in this case mesa's shader
>>>>>> code would need to update program parameter based on the drawable
>>>>>> information - I'm not sure if accessing a driver's drawable
>>>>>> information there would get messy). The easier solution would
>>>>>> probably
>>>>>> be to just directly manipulate the ParameterValues entry associated
>>>>>> with the constant you added, easy though it might be considered
>>>>>> somewhat hackish. Just don't forget you not only have to update the
>>>>>> "constant" within r300UpdateWindow (if the currently bound fp
>>>>>> requires
>>>>>> it), but also when the active fp is switched to another one (and make
>>>>>> sure that a parameter upload is actually triggered if it not already
>>>>>> is upon drawable changes).
>>>>> I think the parameter approach is probably the right one.  This would
>>>>> require that there be a callback into the driver to get this state,
>>>>> and
>>>>> more importantly, the driver would have to set a bit in ctx->NewState
>>>>> (perhaps _NEW_BUFFERS) to indicate that a statechange has occurred
>>>>> which
>>>>> would affect that internal state atom.
>>>> Thank you.
>>>>
>>>>
>>>> I've hit a bit of a problem:
>>>> I was planning to have state flags returned from a callback
>>>> make_state_flags().
>>>> something like:
>>>> ctx->Driver.GetGenericStateFlags(state);
>>>>
>>>> The problem being that the context ctx is not a parameter in
>>>> make_state_flags().
>>>>
>>>> Is there smart way of solving this?
>>> Rune,
>>>
>>> I don't quite understand what you want to do here.  Can you show me
>>> the code you'd like to have (ignoring the ctx argument issue)?  I
>>> would have thought that we could determine the state statically and
>>> just rely on the driver to set that state in ctx->NewState when
>>> necessary.
>>>
>>
>> I am trying to make generic state vars that the drivers can use.
>>
>> the way I read these functions:
>> make_state_flags()  - returns the state flags should trigger an update
>>                       of the state var.
>>
>> _mesa_fetch_state() - fetches the state var.
>>
>> In order to make generic state vars.
>> - I need to get the flags via a callback to the driver from
>> make_state_flags().
>>
>> I need to fetch the vars via a callback to the driver from
>> _mesa_fetch_state().
>>
>>
>> make_state_flags()
>> {
>>     .....
>>     case STATE_INTERNAL:
>>     {
>>          switch (state[1]) {
>>             case STATE_NORMAL_SCALE:
>>         .....
>>                break;
>>             case STATE_TEXRECT_SCALE:
>>         .....
>>                break;
>>             case STATE_GENERIC1:
>>                assert(ctx->Driver.FetchGenericState);
>>                ctx->Driver.FetchGenericState(ctx, state, value);
>>                break;
>>          }
>>     }
>> }
>>
>> _mesa_fetch_state()
>> {
>>     .....
>>     case STATE_INTERNAL:
>>         switch (state[1]) {
>>             case STATE_NORMAL_SCALE:
>>                 return _NEW_MODELVIEW;
>>             case STATE_TEXRECT_SCALE:
>>                 return _NEW_TEXTURE;
>>             case STATE_GENERIC1:
>>                 assert(ctx->Driver.GetGenericStateFlags);
>>                 return ctx->Driver.GetGenericStateFlags(state);
>>         }
>>
>> }
> 
> I guess what I'm wondering is whether the flags you want to put into the
> driver as generics are actually things which are universal and should be
> supported across Mesa and the other drivers - is it just stuff like
> window position?  I think it would be better to create a new
> STATE_WINDOW_POSITION keyed off something like _NEW_BUFFERS for that. It
> would still be the driver's responsibility to set _NEW_BUFFERS on window
> position changes though.
> 

That would solve the problem with the callback in make_state_flags(),
but I was told that only the driver knows the window dimensions (not
position =).
So I'll still need to add a callback to _mesa_fetch_state().


Rune Petersen