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);
> }
>
> }
It seems to me that in ctx->Driver.ProgramStringNotify() you can add
any extra parameters you need to the program's parameters list.
Then, during state validation in the driver you can load/update any
parameters you might have added.
In _mesa_fetch_state() we could change the default case for switch
(state[i]) to be silent when it sees any state tokens it doesn't
understand (rather than call _mesa_problem()).
Does that sound feasible?
-Brian
-------------------------------------------------------------------------
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
