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.
Keith
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
