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);
}
}
Rune Petersen
-------------------------------------------------------------------------
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
