Brian Paul wrote:
Rune Petersen wrote:
Keith Whitwell wrote:
Rune Petersen wrote:
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
Rune Petersen wrote:
Brian Paul wrote:
It seems to me that in ctx-Driver.ProgramStringNotify() you can add any
extra parameters you need to the program's parameters list.
I would prefer to make driver specific version of
_mesa_add_state_reference() for internal state vars.
No matter how
Brian Paul wrote:
Rune Petersen wrote:
Brian Paul wrote:
It seems to me that in ctx-Driver.ProgramStringNotify() you can add any
extra parameters you need to the program's parameters list.
I would prefer to make driver specific version of
_mesa_add_state_reference() for internal state
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
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
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
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.
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
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
Roland Scheidegger wrote:
Keith Whitwell wrote:
Now I remember why I can't use radeon-dri.drawable, at least not
directly when the shader code is added:
When the window size changes the constants have to be updated.
Is there a way for the driver to update a constant after construction?
Keith Whitwell wrote:
Rune Petersen wrote:
Rune Petersen wrote:
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work
Rune Petersen wrote:
Keith Whitwell wrote:
Rune Petersen wrote:
Rune Petersen wrote:
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I
Keith Whitwell wrote:
Now I remember why I can't use radeon-dri.drawable, at least not
directly when the shader code is added:
When the window size changes the constants have to be updated.
Is there a way for the driver to update a constant after construction?
This is an age-old
Keith Whitwell wrote:
Rune Petersen wrote:
Rune Petersen wrote:
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work
Rune Petersen wrote:
Keith Whitwell wrote:
Rune Petersen wrote:
Rune Petersen wrote:
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work similar to what is used for position invariant
programs, instead of
Rune Petersen wrote:
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work similar to what is used for position invariant
Rune Petersen wrote:
Rune Petersen wrote:
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work similar to what is used
It turns out I missed something obvious...
The parameters are passed correctly, I have just not transformed the
vertex.position to the fragment.position
Now I just need to figure out how =)
Rune Petersen
Rune Petersen wrote:
Hi,
Found some time to have a look at routing fragment.position
Rune Petersen wrote:
It turns out I missed something obvious...
The parameters are passed correctly, I have just not transformed the
vertex.position to the fragment.position
I guess that's the viewport transformation, or maybe a perspective
divide followed by viewport transformation.
But I
Keith Whitwell wrote:
Rune Petersen wrote:
It turns out I missed something obvious...
The parameters are passed correctly, I have just not transformed the
vertex.position to the fragment.position
I guess that's the viewport transformation, or maybe a perspective
divide followed by
Rune Petersen wrote:
Keith Whitwell wrote:
Rune Petersen wrote:
It turns out I missed something obvious...
The parameters are passed correctly, I have just not transformed the
vertex.position to the fragment.position
I guess that's the viewport transformation, or maybe a perspective
divide
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work similar to what is used for position invariant
programs, instead of using
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work similar to what is used for position invariant
programs, instead of
Hi,
Found some time to have a look at routing fragment.position from the
vertex shader.
Patch notes:
x y appear correct, but z is 0 % w is 1.
z appears to be 0 in the vertex shader, because swizzling Z to
position.x is is also 0.
Most of the patch is the select_vertex_shader changes by Aapo
25 matches
Mail list logo