On 12/14/2011 01:47 PM, Marek Olšák wrote:
On Wed, Dec 14, 2011 at 6:30 PM, Ian Romanick<i...@freedesktop.org> wrote:
On 12/13/2011 04:32 PM, Marek Olšák wrote:
---
src/gallium/drivers/r300/r300_screen.c | 3 ++-
src/gallium/include/pipe/p_defines.h | 3 ++-
src/glsl/linker.cpp | 6 ++++++
src/mesa/main/mtypes.h | 9 +++++++++
src/mesa/state_tracker/st_extensions.c | 3 +++
5 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index 0bae065..a761939 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -102,6 +102,7 @@ static int r300_get_param(struct pipe_screen* pscreen,
enum pipe_cap param)
case PIPE_CAP_TEXTURE_BARRIER:
case PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS:
case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
+ case PIPE_CAP_SEPARATE_COLOR_VARYINGS:
return 1;
/* r300 cannot do swizzling of compressed textures. Supported
otherwise. */
@@ -182,7 +183,7 @@ static int r300_get_shader_param(struct pipe_screen
*pscreen, unsigned shader, e
* R500 has the ability to turn 3rd and 4th color into
* additional texcoords but there is no two-sided color
* selection then. However the facing bit can be used
instead. */
- return 10;
+ return 8;
Why are you trying to make r300g behave differently the every other driver
that has existed for that same hardware? This doesn't make any sense. This
is not Apple's driver works for r300 hardware, and it's not how AMD's
Windows driver works (worked, anyway) for r300 hardware.
This feels like an unnecessary hack.
Hi Ian,
Simple. I cannot pass the test glsl-max-varyings if I report 40
varying components, because I have only 32 texcoord components + 8
color components. I could re-use the color varyings, but it's not full
single-precision. r300 uses a fixed-point type S3.12 for color
interpolators, which can represent values in the range [-7.9999,
7.9999]. That's unusable for used-defined varyings. r500 uses a 20-bit
float, which is better, but I am not sure if it's good enough.
The desktop GL spec isn't very specific about range or precision before
either a late 3.x version or one of the 4.x versions (I don't recall
which). However, I'm pretty sure ES2 requires 24-bit float. Is 20-bits
even a real computer number? :)
This also means that r300 and r500 can't handle unclamped colors.
Right? I'm thinking of the scenario:
- The driver advertises 32 varying components.
- The application calls glClampColorARB(GL_CLAMP_VERTEX_COLOR_ARB,
GL_FALSE).
- The shader uses gl_Color and 32 components worth of other varyings.
What happens? Are the colors partially clamped or what? Since color
clamping is set independent of compiling or linking, you don't have an
opportunity to generate any errors up front.
It sounds like the colors have to go through different interpolators
anyway if glClampColorARB(GL_CLAMP_VERTEX_COLOR_ARB, GL_FALSE) is used.
Is that handled correctly?
Now I'm really curious to see glsl-max-varyings run on an Apple system
with an r300. Scouting around, that looks like it would have to be a G5
iMac or PowerMac. Hrm...
Also, r500 actually has 10 texcoord interpolators, but we don't use
the last two yet (it's non-trivial, there is a special PS3 mode for
it). Whether color interpolators can be enabled in that mode is
undocumented, though I am almost sure the back colors cannot be. (the
DX9 ps_3_0 shader profile doesn't have color inputs at all)
If colors are counted, you don't need to worry about that. 40 varyings
means 40 varyings. Clamped colors would go to the usual slots (leaving
2 texcoords unused), and clamped colors would go in two of the texcoord
slots.
Yes, the patch is a hack. However modifying glsl-max-varyings to only
test MAX_VARYING_FLOATS - 8 doesn't feel right either. Do you have a
better idea?
What about the other patch?
I need to do some research about that. I'm pretty sure i915 needs a
slot for WPOS. I want to collect some more data and see if there's a
coherent architecture that works for the various platforms. We're
starting to get a big pile of band-aids, and that can't hold up in the
long run.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
