Re: [Mesa3d-dev] Grab bag of random questions (whoo)
Brian added a util function for copying the framebuffer state and adjusting all the refcounts... Keith From: Corbin Simpson [mostawesomed...@gmail.com] Sent: Sunday, January 31, 2010 11:11 AM To: Jose Fonseca Cc: Mesa3D-Development Subject: Re: [Mesa3d-dev] Grab bag of random questions (whoo) On Sun, Jan 31, 2010 at 6:21 AM, José Fonseca jfons...@vmware.com wrote: On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote: 5) How const is const for CSO? e.g. r300_state.c:498, we're not copying pipe_framebuffer_state but just the pointer. It appears to work, but is it actually safe? The const means the driver cannot change it. Not that it won't change. The long answer is depends on how the driver is implemented and commands batched. The next time the set_framebuffer_state is called the previous object may have been destroyed/modified, so if you have internal references to it they would cause segfault. But if by the time that happens you no longer have references to it -- e.g. you just have references to the BOs that hold the frambuffer storage -- then it would work fine. Short answer is -- it is better to just make a local copy. Alright, not hard to fix. Also, on the topic of framebuffers, is it okay to refuse to render if no MRTs or Z buffer are present? Not really. At least not as it stands. If the hardware requires these then they'll need to be created internally by the pipe driver. We could add a caps for this but I see no point for it, since it's so easy to create a dummy framebuffer internally. Again, I should have typed and. I was thinking in terms of sanity checks. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
Luca, In GL, there doesn't seem to be a requirement for sequential usage - an app using ARB_vp/fp could explicitly pass TEXCOORD[10] and ignore 0..9 if it wanted to. In ARB_vp, that effectively means the shader would be using discontiguous register numbers, ie OUTPUT[0], OUTPUT[10], etc. In DX9, there is also no requirement for sequential usage - an app can use TEXCOORD[1] without [0], or COLOR[0] and [2] without [1] or [3]. I would expect any DX9 gallium state tracker would also end up using non-sequential indices if it directly translated DX9 semantics to gallium. In DX10, it seems to be the same, but there are additional changes to simplify things. Here's a link to some msdn about DX9 and DX10 semantics: http://msdn.microsoft.com/en-us/library/ee415668%28VS.85%29.aspx#Porting_Shaders With quote: -- A semantic is a string attached to a shader input or output that conveys information about the intended use of a parameter. Semantics are required on all variables passed between shader stages. The syntax for adding a semantic to a shader variable is shown here (Variable Syntax (DirectX HLSL)). In general, data passed between pipeline stages is completely generic and is not uniquely interpreted by the system; arbitrary semantics are allowed which have no special meaning. Parameters (in Direct3D 10) which contain these special semantics are referred to as System-Value Semantics. -- This is fairly close to gallium. It's hard to tell what goes on at the assembly level in DX10, as HLSL is the public interface. But it seems that DX10 goes further than gallium, and also matches based on register number, ie PS.input[0] always corresponds to VS.output[0], though I'm not sure how that works in the face of things like the face register which appears for the first time in the PS. Here's a link: http://msdn.microsoft.com/en-us/library/ee418358%28VS.85%29.aspx With quote: -- In Direct3D 10, adjacent stages effectively share a register array, where the output shader (or pipeline stage) writes data to specific locations in the register array and the input shader must read from the same locations. The API uses shader signatures to bind shader outputs with inputs without the overhead of semantic resolution. -- So right now, we seem to actually be close to the DX9 and GL models. If we were going to change, I'd suggest moving closer to DX10 rather than coming up with some new way of doing things. Ultimately, it shouldn't be all that important as everybody should be running these shaders through a proper optimizer for their hardware, which should have no trouble translating this stuff into any format it likes. Keith From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca Barbieri [l...@luca-barbieri.com] Sent: Thursday, January 28, 2010 11:48 PM To: Brian Paul; Keith Whitwell Cc: Luca Barbieri; mesa3d-dev@lists.sourceforge.net Subject: Re: [PATCH] glsl: put varyings in texcoord slots I'd like to have some more definitive review comments on this patch (sending to Brian and Keith for this). Right now GLSL is the *only* Gallium user that does not use sequential indexes starting from 0 for vertex shader outputs and fragment shader inputs. This causes problems for some drivers such as nv30/nv40 that don't remap the indexes right now. This can be addressed in two ways: 1. Don't require Gallium users to use sequential indices, and require vertex shader inputs and fragment shader outputs to match perfectly 2. Don't require Gallium users to use sequential indices, and change nv30/nv40 and possibly other drivers to remap indices 3. Fix the only problematic user, GLSL, to use sequential indices (1) will break the Mesa state tracker in a very hard to fix way. (2) is complex and means that nv30/nv40 and maybe other drivers can no longer compile vertex and fragment shaders independently. (3) is a simple fix, provided by this patch. I feel that (3), implemented by this patch, is the best solution, since driver simplicity is one of the Gallium design goals, and I don't see any significant advantages in supporting discontiguous vertex shader output / fragment shader input values. OpenGL and DirectX 9/10 don't seem to allow arbitrary numbers for vertex shader outputs and fragment shader inputs, and instead require 0-7, 0-15 or 0-31 depending on feature level. If this is wrong, please correct me. I propose that Gallium should also require 0-x indices and not arbitrary values. Thus, GLSL should be fixed to respect that. Note that this change cannot be done in the state tracker because it requires to see both the fragment and vertex shaders at once, which only happens in the GLSL linker. Thus, while the change has been discussed with Gallium in mind, it is done at the Mesa program level, and it actually results in Mesa programs with contiguous indices. This also
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
An overview of the possible options. Let's call vertex shader outputs v and fragment shader inputs f Let v - f mean that v connects to f. NUM_INTERPOLATORS is the number of available interpolators. It is usually between 8 and 32. 1. Current Gallium v - f if and only if v == f Any values of v and f are legal 2. My proposal, basic version v - f if and only if v == f v = NUM_INTERPOLATORS and f = NUM_INTERPOLATORS are illegal 3. My proposal plus with routing tables (Corbin Simpson's idea) v - f if and only if (v, f) is an entry in the routing table v = NUM_INTERPOLATORS and f = NUM_INTERPOLATORS are illegal If no routing table is set, (2) is used instead The routing table is set via a new -set_routing_table() entry point, taking the processor linkage affected, and an array of pairs of registers to link. This may be made a CSO (it is constant for each pair of state tracker shaders). The problem with (1) is that if the hardware has no routing support, there is no way to implement it except by recompiling either the vertex or fragment shader when the other changes. Furthermore, no known user of Gallium actually needs (1) except the current GLSL linker, but only due to the particular implementation and not due to the OpenGL/GLSL API itself. Only (2) is actually needed by the APIs, and it is also supported trivially by all hardware. Additionally there is no way to implement bind by name (i.e. having GLSL varyings with the same name be linked) with either (1) or (2) without recompiling one shader in response to changing the other. With (3) instead, the state tracker can look at the symbol tables of both programs, build a routing table, and set it independently of the shaders. Functionality provided by (1) can also be emulated in this way. Thus, I propose replacing (1) with (2) and later expand to (3) if we desire to do so. I think that in particular, the bind by name argument is decisive, since binding by name is what GLSL and high level languages really want, and the added flexibility of (1) is useless for that, while coming at significant driver complexity and performance cost. What do you think? -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
This seems like a very different idea of semantics. These aren't intended to
be hardware resources, and there is no concept of querying the driver to figure
out how many the hardware supports. Further, the indices for different
semantic names are considered to be disjoint, permitting FOG[0], COLOR[0] and
GENERIC[0], each of which would potentially consume an interpolator on some
hardware, subverting the idea of a maximum semantic index.
There's currently no concept of driver-specified maximum semantic indexes, and
I don't think it's the right direction to be taking things. If we are going to
have a limit, it would be on the total number of inputs/outputs from a given
stage, not the way that individual ones are labelled.
I think if you want to improve linkage semantics, some of your other
suggestions are more promising. I'd like to dig into those a little more if
that's ok.
Keith
From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca
Barbieri [l...@luca-barbieri.com]
Sent: Monday, February 01, 2010 6:11 AM
To: Keith Whitwell
Cc: Brian Paul; mesa3d-dev@lists.sourceforge.net
Subject: Re: [PATCH] glsl: put varyings in texcoord slots
In GL, there doesn't seem to be a requirement for sequential usage - an app
using ARB_vp/fp could explicitly pass TEXCOORD[10] and ignore 0..9 if it
wanted to. In ARB_vp, that effectively means the shader would be using
discontiguous register numbers, ie OUTPUT[0], OUTPUT[10], etc.
Yes, but TEXCOORD[10] will only work if the hardware supports 11 textures.
In DX9, there is also no requirement for sequential usage - an app can use
TEXCOORD[1] without [0], or COLOR[0] and [2] without [1] or [3]. I would
expect any DX9 gallium state tracker would also end up using non-sequential
indices if it directly translated DX9 semantics to gallium.
I think there is some terminology confusion.
I'm not proposing to require indices to be sequential in the way you
are describing.
By sequential I mean that if the hardware supports 8 interpolators,
then the available semantic indices should run from 0 to 7.
Thus, the *available* semantic indices are sequential, but the user is
free to use any subset of them.
So you can start with OUTPUT[10], but only if at least 11
interpolators are supported (so that the used set {10} is a subset of
the available set [0-10]).
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
On Mon, Feb 1, 2010 at 3:38 PM, Keith Whitwell kei...@vmware.com wrote: This seems like a very different idea of semantics. These aren't intended to be hardware resources, and there is no concept of querying the driver to figure out how many the hardware supports. Further, the indices for different semantic names are considered to be disjoint, permitting FOG[0], COLOR[0] and GENERIC[0], each of which would potentially consume an interpolator on some hardware, subverting the idea of a maximum semantic index. There would be a maximum semantic index for each semantic type. Note this is exactly like the existing OpenGL limit on fragment.texcoord[i] and how ARBfp/vp work. All APIs as far as I know have such limits, simply because they indeed refer to hardware resources. Why shouldn't Gallium semantic indices refer to hardware resources too? What is the advantage of using abstract identifiers that the driver needs to map, when no API needs those, and when there is no use for them? (except for slightly simplifying the GLSL implementation at the expense of greater complexity in all drivers) I think if you want to improve linkage semantics, some of your other suggestions are more promising. I'd like to dig into those a little more if that's ok. Yes, sure. Are your referring to the routing tables idea? (actually initially suggested by Corbin Simpson) -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
On 01.02.2010 15:32, Luca Barbieri wrote: An overview of the possible options. Let's call vertex shader outputs v and fragment shader inputs f Let v - f mean that v connects to f. NUM_INTERPOLATORS is the number of available interpolators. It is usually between 8 and 32. 1. Current Gallium v - f if and only if v == f Any values of v and f are legal 2. My proposal, basic version v - f if and only if v == f v = NUM_INTERPOLATORS and f = NUM_INTERPOLATORS are illegal 3. My proposal plus with routing tables (Corbin Simpson's idea) v - f if and only if (v, f) is an entry in the routing table v = NUM_INTERPOLATORS and f = NUM_INTERPOLATORS are illegal If no routing table is set, (2) is used instead The routing table is set via a new -set_routing_table() entry point, taking the processor linkage affected, and an array of pairs of registers to link. This may be made a CSO (it is constant for each pair of state tracker shaders). I can't really use a routing table state to produce a cso, because the hw routing table I generate depends on rasterizer state, e.g. I must not put in back face colour (we have a 2 to 1 mapping here) if twoside is disabled. Also, I'm routing based on the scalar *components* the FP reads, not whole TGSI pseudo vec4 registers (NUM_INTERPOLATORS will thus be inaccurate) - set_routing_table will have to pass me the respective programs too. Well, I can still use the cso and insert it into the rest of the routing table that still need to be assembled on the fly, I did that before the 1:1 mapping between FP and VP regs was removed. On a sidenote, if a VP output is not written, I map it to 0 or 1 (4th component); FOG has all 4 components written in VP thus yzw don't become 0 or 1 in FP as is expected; I can adjust the write mask myself though ... Christoph The problem with (1) is that if the hardware has no routing support, there is no way to implement it except by recompiling either the vertex or fragment shader when the other changes. Furthermore, no known user of Gallium actually needs (1) except the current GLSL linker, but only due to the particular implementation and not due to the OpenGL/GLSL API itself. Only (2) is actually needed by the APIs, and it is also supported trivially by all hardware. Additionally there is no way to implement bind by name (i.e. having GLSL varyings with the same name be linked) with either (1) or (2) without recompiling one shader in response to changing the other. With (3) instead, the state tracker can look at the symbol tables of both programs, build a routing table, and set it independently of the shaders. Functionality provided by (1) can also be emulated in this way. Thus, I propose replacing (1) with (2) and later expand to (3) if we desire to do so. I think that in particular, the bind by name argument is decisive, since binding by name is what GLSL and high level languages really want, and the added flexibility of (1) is useless for that, while coming at significant driver complexity and performance cost. What do you think? -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] switch shaders assembly TGSI code by tgsi_ureg
Hello, Theses patchs switch all shaders code implemeted using TGSI assembly by tgsi_ureg. Igor From 6ff667cff0b3d6460a2bb0d6845348b6a2c6e6e2 Mon Sep 17 00:00:00 2001 From: Igor Oliveira igor.olive...@openbossa.org Date: Mon, 1 Feb 2010 11:11:36 -0400 Subject: [PATCH 1/2] vega: change tgsi asm by tgsi_ureg functions --- src/gallium/state_trackers/vega/asm_fill.h | 549 +++- 1 files changed, 378 insertions(+), 171 deletions(-) diff --git a/src/gallium/state_trackers/vega/asm_fill.h b/src/gallium/state_trackers/vega/asm_fill.h index 2f394ad..549e54c 100644 --- a/src/gallium/state_trackers/vega/asm_fill.h +++ b/src/gallium/state_trackers/vega/asm_fill.h @@ -27,166 +27,373 @@ #ifndef ASM_FILL_H #define ASM_FILL_H -static const char solid_fill_asm[] = - MOV %s, CONST[0]\n; - - -static const char linear_grad_asm[] = - MOV TEMP[0].xy, IN[0]\n - MOV TEMP[0].z, CONST[1].\n - DP3 TEMP[1], CONST[2], TEMP[0]\n - DP3 TEMP[2], CONST[3], TEMP[0]\n - DP3 TEMP[3], CONST[4], TEMP[0]\n - RCP TEMP[3], TEMP[3]\n - MUL TEMP[1], TEMP[1], TEMP[3]\n - MUL TEMP[2], TEMP[2], TEMP[3]\n - MOV TEMP[4].x, TEMP[1]\n - MOV TEMP[4].y, TEMP[2]\n - MUL TEMP[0], CONST[0]., TEMP[4].\n - MAD TEMP[1], CONST[0]., TEMP[4]., TEMP[0]\n - MUL TEMP[2], TEMP[1], CONST[0].\n - TEX %s, TEMP[2], SAMP[0], 1D\n; - -static const char radial_grad_asm[] = - MOV TEMP[0].xy, IN[0]\n - MOV TEMP[0].z, CONST[1].\n - DP3 TEMP[1], CONST[2], TEMP[0]\n - DP3 TEMP[2], CONST[3], TEMP[0]\n - DP3 TEMP[3], CONST[4], TEMP[0]\n - RCP TEMP[3], TEMP[3]\n - MUL TEMP[1], TEMP[1], TEMP[3]\n - MUL TEMP[2], TEMP[2], TEMP[3]\n - MOV TEMP[5].x, TEMP[1]\n - MOV TEMP[5].y, TEMP[2]\n - MUL TEMP[0], CONST[0]., TEMP[5].\n - MAD TEMP[1], CONST[0]., TEMP[5]., TEMP[0]\n - ADD TEMP[1], TEMP[1], TEMP[1]\n - MUL TEMP[3], TEMP[5]., TEMP[5].\n - MAD TEMP[4], TEMP[5]., TEMP[5]., TEMP[3]\n - MOV TEMP[4], -TEMP[4]\n - MUL TEMP[2], CONST[0]., TEMP[4]\n - MUL TEMP[0], CONST[1]., TEMP[2]\n - MUL TEMP[3], TEMP[1], TEMP[1]\n - SUB TEMP[2], TEMP[3], TEMP[0]\n - RSQ TEMP[2], |TEMP[2]|\n - RCP TEMP[2], TEMP[2]\n - SUB TEMP[1], TEMP[2], TEMP[1]\n - ADD TEMP[0], CONST[0]., CONST[0].\n - RCP TEMP[0], TEMP[0]\n - MUL TEMP[2], TEMP[1], TEMP[0]\n - TEX %s, TEMP[2], SAMP[0], 1D\n; - -static const char pattern_asm[] = - MOV TEMP[0].xy, IN[0]\n - MOV TEMP[0].z, CONST[1].\n - DP3 TEMP[1], CONST[2], TEMP[0]\n - DP3 TEMP[2], CONST[3], TEMP[0]\n - DP3 TEMP[3], CONST[4], TEMP[0]\n - RCP TEMP[3], TEMP[3]\n - MUL TEMP[1], TEMP[1], TEMP[3]\n - MUL TEMP[2], TEMP[2], TEMP[3]\n - MOV TEMP[4].x, TEMP[1]\n - MOV TEMP[4].y, TEMP[2]\n - RCP TEMP[0], CONST[1].zwzw\n - MOV TEMP[1], TEMP[4]\n - MUL TEMP[1].x, TEMP[1], TEMP[0]\n - MUL TEMP[1].y, TEMP[1], TEMP[0]\n - TEX %s, TEMP[1], SAMP[0], 2D\n; - - -static const char mask_asm[] = - TEX TEMP[1], IN[0], SAMP[1], 2D\n - MUL TEMP[0].w, TEMP[0]., TEMP[1].\n - MOV %s, TEMP[0]\n; - - -static const char image_normal_asm[] = - TEX %s, IN[1], SAMP[3], 2D\n; - -static const char image_multiply_asm[] = - TEX TEMP[1], IN[1], SAMP[3], 2D\n - MUL %s, TEMP[0], TEMP[1]\n; - -static const char image_stencil_asm[] = - TEX TEMP[1], IN[1], SAMP[3], 2D\n - MUL %s, TEMP[0], TEMP[1]\n; - - -#define EXTENDED_BLEND_OVER \ - SUB TEMP[3], CONST[1]., TEMP[1].\n \ - SUB TEMP[4], CONST[1]., TEMP[0].\n \ - MUL TEMP[3], TEMP[0], TEMP[3]\n\ - MUL TEMP[4], TEMP[1], TEMP[4]\n\ - ADD TEMP[3], TEMP[3], TEMP[4]\n - -static const char blend_multiply_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - EXTENDED_BLEND_OVER - MUL TEMP[4], TEMP[0], TEMP[1]\n - ADD TEMP[1], TEMP[4], TEMP[3]\n/*result.rgb*/ - MUL TEMP[2], TEMP[0]., TEMP[1].\n - ADD TEMP[3], TEMP[0]., TEMP[1].\n - SUB TEMP[1].w, TEMP[3], TEMP[2]\n - MOV %s, TEMP[1]\n; -#if 1 -static const char blend_screen_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - ADD TEMP[3], TEMP[0], TEMP[1]\n - MUL TEMP[2], TEMP[0], TEMP[1]\n - SUB %s, TEMP[3], TEMP[2]\n; -#else -static const char blend_screen_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - MOV %s, TEMP[1]\n; -#endif - -static const char blend_darken_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - EXTENDED_BLEND_OVER - MUL TEMP[4], TEMP[0], TEMP[1].\n - MUL TEMP[5], TEMP[1], TEMP[0].\n - MIN TEMP[4], TEMP[4], TEMP[5]\n - ADD TEMP[1], TEMP[3], TEMP[4]\n - MUL TEMP[2], TEMP[0]., TEMP[1].\n - ADD TEMP[3], TEMP[0]., TEMP[1].\n - SUB TEMP[1].w, TEMP[3], TEMP[2]\n - MOV %s, TEMP[1]\n; - -static const char blend_lighten_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - EXTENDED_BLEND_OVER - MUL TEMP[4], TEMP[0], TEMP[1].\n - MUL TEMP[5], TEMP[1], TEMP[0].\n - MAX TEMP[4], TEMP[4], TEMP[5]\n - ADD TEMP[1], TEMP[3],
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
I can't really use a routing table state to produce a cso, because the hw routing table I generate depends on rasterizer state, e.g. I must not put in back face colour (we have a 2 to 1 mapping here) if twoside is disabled. Also, I'm routing based on the scalar *components* the FP reads, not whole TGSI pseudo vec4 registers (NUM_INTERPOLATORS will thus be inaccurate) - set_routing_table will have to pass me the respective programs too. Well, I can still use the cso and insert it into the rest of the routing table that still need to be assembled on the fly, I did that before the 1:1 mapping between FP and VP regs was removed. You are right, the routing table CSO needs to contain the fragment and vertex shader handles, and ideally light_twoside should be moved to the vertex-fragment routing table since it is really an attribute of that and not polygon rasterization/setup. You can then just look at your internal data structure and construct a scalar routing table from the vec4 one provided by Gallium. We could also, as a further extension, support scalar routing tables directly in Gallium. Note however that radeon hardware presumably only supports vector ones, so we would need all 3 options with caps. A further intermediate step could be vector routing tables with swizzling. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 26317] glsl compiled wrong
http://bugs.freedesktop.org/show_bug.cgi?id=26317 Andre Maasikas amaasi...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Andre Maasikas amaasi...@gmail.com 2010-02-01 08:17:12 PST --- seems to work ok with the patch -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] RFC: gallium-embedded
I've just started another feature branch, gallium-embedded. The objectives of this branch are two-fold: - remove all inlines and os dependencies from src/gallium/include/pipe headers, so that gallium interfaces become pure interfaces and therefore everything else becomes optional - move all OS abstractions to a separate optional module so that porting to new platforms is easier -- there will be a clear list of functions that need to be implemented The only planned interface change is pipe_reference -- it will be reduced to an ordinary int32_t -- which is key to achieve the above. Implementations of gallium should use p_atomic or their version of atomic operations. For platforms without hardware-support atomic operations (I personally don't know any interesting platform that fits the profile) gallium will either be single threaded or a global mutex should be acquired before incrementing refcounts. In summary there will be three levels of integration with gallium: 1 - just the gallium interfaces, mean and lean 2 - gallium interfaces and auxiliary modules but no OS abstractions (e.g. for embedded platforms) 3 - everything (interfaces + auxiliary + os abstractions). all existing platforms (linux, windows, etc) If there are any concerns with this direction please let me know as soon as possible. Jose -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
Christoph, Luca, Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware we end up implementing it by passing both front and back colors to the fragment shader and selecting between them using the FACE variable. If we removed the implicit fixed-function support for two-side lighting in the rasterizer, it would solve the issue of how this is represented in any routing table. How does that sit with your drivers? Keith From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca Barbieri [l...@luca-barbieri.com] Sent: Monday, February 01, 2010 7:29 AM To: Christoph Bumiller Cc: Keith Whitwell; mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots I can't really use a routing table state to produce a cso, because the hw routing table I generate depends on rasterizer state, e.g. I must not put in back face colour (we have a 2 to 1 mapping here) if twoside is disabled. Also, I'm routing based on the scalar *components* the FP reads, not whole TGSI pseudo vec4 registers (NUM_INTERPOLATORS will thus be inaccurate) - set_routing_table will have to pass me the respective programs too. Well, I can still use the cso and insert it into the rest of the routing table that still need to be assembled on the fly, I did that before the 1:1 mapping between FP and VP regs was removed. You are right, the routing table CSO needs to contain the fragment and vertex shader handles, and ideally light_twoside should be moved to the vertex-fragment routing table since it is really an attribute of that and not polygon rasterization/setup. You can then just look at your internal data structure and construct a scalar routing table from the vec4 one provided by Gallium. We could also, as a further extension, support scalar routing tables directly in Gallium. Note however that radeon hardware presumably only supports vector ones, so we would need all 3 options with caps. A further intermediate step could be vector routing tables with swizzling. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
On Mon, Feb 1, 2010 at 5:31 PM, Keith Whitwell kei...@vmware.com wrote: Christoph, Luca, Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware we end up implementing it by passing both front and back colors to the fragment shader and selecting between them using the FACE variable. If we removed the implicit fixed-function support for two-side lighting in the rasterizer, it would solve the issue of how this is represented in any routing table. How does that sit with your drivers? nv40 (and perhaps r300 too?) appears to have 2 hardware back color registers in the vertex shader that are automatically routed, so it would probably be best to leave it that way. Of course, a generic face-dependent routing table could be yet another optional feature. Does any API expose such a thing, perhaps in the form of unlimited rather than 2 front/back colors? (other than by using FACE) -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
DX9 semantic indexes are apparently unlimited, and you can definitely specify COLOR 0..3, I haven't tried to go further. Keith From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca Barbieri [l...@luca-barbieri.com] Sent: Monday, February 01, 2010 8:44 AM To: Keith Whitwell Cc: Christoph Bumiller; mesa3d-dev@lists.sourceforge.net Subject: Re: light_twoside RE: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots On Mon, Feb 1, 2010 at 5:31 PM, Keith Whitwell kei...@vmware.com wrote: Christoph, Luca, Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware we end up implementing it by passing both front and back colors to the fragment shader and selecting between them using the FACE variable. If we removed the implicit fixed-function support for two-side lighting in the rasterizer, it would solve the issue of how this is represented in any routing table. How does that sit with your drivers? nv40 (and perhaps r300 too?) appears to have 2 hardware back color registers in the vertex shader that are automatically routed, so it would probably be best to leave it that way. Of course, a generic face-dependent routing table could be yet another optional feature. Does any API expose such a thing, perhaps in the form of unlimited rather than 2 front/back colors? (other than by using FACE) -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] switch shaders assembly TGSI code by tgsi_ureg
On Monday 01 February 2010 10:19:53 Igor Oliveira wrote: Hello, Theses patchs switch all shaders code implemeted using TGSI assembly by tgsi_ureg. Hey Igor, very nice work! Since I don't have the conformance framework anymore, did you test your changes with the examples that we have? Before committing it'd be nice to know that we won't get too many obvious regressions. z -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
DX9 semantic indexes are apparently unlimited According to http://msdn.microsoft.com/en-us/library/ee418355%28VS.85%29.aspx, this is not the case. Here is the relevant text: These semantics have meaning when attached to a vertex-shader parameters. These semantics are supported in both Direct3D 9 and Direct3D 10. [...] n is an optional integer between 0 and the number of resources supported. For example, POSITION0, TEXCOOR1, etc. [...] These semantics have meaning when attached to a pixel-shader input parameter. These semantics are supported in both Direct3D 9 and Direct3D 10. [...] n is an optional integer between 0 and the number of resources supported. For example, PSIZE0, COLOR1, etc. Thus, both DX9 and DX10 do not need arbitrary indices. OpenGL also doesn't, as fragment.texcoord[i] has i GL_MAX_TEXTURE_COORDS_ARB. It seems to make sense to follow those APIs in the design of Gallium semantics. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
Mike Stroyan m...@lunarg.com writes: The changes to load EGL drivers by pattern matching had the side effect of not looking in the directories specified by LD_LIBRARY_PATH or -rpath or ldconfig . This is silly. If you give dlopen a library name: dlopen(libWhatever.so, flags); then *it* will automatically search LD_LIBRARY_PATH. By giving an absolute path, one circumvents this behavior. Even better, the relative-pathness obeys platform specifics, like searching DYLD_LIBRARY_PATH (and fallbacks) on OS X. A better fix is thus to not give an absolute path for EGL. -tom -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
On 31.01.2010 18:41, Christoph Bumiller wrote: On 31.01.2010 01:37, Roland Scheidegger wrote: Marek Olšák wrote: 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in the fragment constants reads, Since Gallium doesn't support GL_ARB_shadow_ambient, this is always (0,0,0,0), right? I think the extension could be added to Gallium since the r300 compiler can generate code for it. It could. But generally, gallium doesn't implement features common hardware can't do (not only because most drivers except software based ones couldn't implement it, but those features also turn out to be rarely used, for obvious reasons). r300 is an exception here since it emulates ARB_shadow anyway. Though I think if you can make a case why this is really necessary it could be done, but that's not my call. Another comment reads, Gallium doesn't provide us with any information regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE, above the texture compare modes. I don't really like that section of code, but it probably can't get cleaner, right? Even though this is a rarely used feature in OpenGL nowadays, it should get fixed if we want to be GL-compliant. That means adding depth texture modes in pipe_sampler_state and setting them in the Mesa state tracker. The R300 compiler can already generate code for these modes as well. Note R300 is again special a bit here. Actually, I realized my earlier answer doesn't make sense. Hardware which actually supports EXT_texture_swizzle (and native ARB_shadow) should be able to implement this easily. Hardware like i965 which doesn't support EXT_texture_swizzle could do it in the shader. Maybe it would make sense to add EXT_texture_swizzle capability in gallium (in the sampler state). That would solve this in a bit more generic way than some special bits for depth texture mode. From my point of view adding a swizzle in the sampler state is a bad idea. On nv50, this would make texture setup dependent on sampler state: we have an Image and Sampler configuration buffer containing entries that can be bound to texture and sampler units. The texture swizzle would be supported by setting a different format in the image entry, like BGRA instead of RGBA, just that it also supports RGRG or whatever you like. Well, the normalization bit seems to be stored in the TIC entries instead of the TSC ones already, I guess that comes from the rectangle texture type, but let's ignore that. I don't see texture swizzle in d3d10 (but then, I don't know d3d10 very well), and OpenGL doesn't separate textures and samplers anyway, so I'd put in in texture state. Keeping a bunch of shaders for texture swizzles doesn't sound nice either. Of course, if other hardware would prefer this in sampler state, then ... ah, I should probably let go of the illusion that gallium state will continue to nicely map to my hardware ... I don't know if other hardware likes it in sampler state, but the problem is it really is sampler state. This is not a property of the texture, it can change anytime and you don't want to recreate the texture just because this changes, I think. I'm not sure how to implement this nicely neither, but I'd guess we'd at least wanted to indicate the swizzle fields to correspond to hardware channels (so for a luminance_alpha texture, the swizzle would indicate rrrg for the first and second channels respectively), not the GL-after-sampling mapping as the extension uses. Hence depth textures used as luminance would be rrr1, as alpha 000r, and as intensity . So, basically, a texture a8l8 texture would be equivalent to a r8g8 texture, when used for sampling with the same swizzling. Note that an easy solution (for depth textures) would be to add just new depth texture formats (one for each alpha, luminance, and intensity mode), but then again you make this part of the texture, which it is not. Those are just some quick thoughts however, I don't think anyone would be opposed if you can come up with a nice solution for this. Roland -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Re-using OpenGL texture names
I just noticed that alienarena fails to create an FBO for depth rendering because on st_validate_framebuffer, the depth attachment contains a pt in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp) reports as not supported in screen-is_format_supported if usage is ZS. This happens because the app seems to use a texture ID that has already been used with mipmaps, and so st_TexImage doesn't create a new pipe texture with the different format, because teximage_realloc is false (NULL passed to glTexImage2D). I'm not sure if that is to be regarded as an application bug or if we should dump the other mipmap levels an reallocate nonetheless, so I'm asking here (I guess the nvidia blob seems to permit this behaviour, I already had another issue with this game where it was too forgiving). Christoph -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
Luca, I haven't tried to probe crazy high numbers, but within reason, my experience is that the numbers are unconstrained. Certainly, within the range you're suggesting for gallium, there is no constraint in DX9. No doubt where there is a system-interpreted meaning attached to a semantic, that meaning will impose an interpretation on the index and that will imply a limit on the semantic index. For instance, in pixel shader outputs, COLOR[n] means a particular output is destined to be written to colorbuffer n. Nobody is saying there isn't a limit on the number of bound colorbuffers. By implication, the same limit already exists in gallium. Now, your particular hardware has a additional limitation which is fairly unique, and you're pushing a change to gallium which would mimic the restrictions of your hardware. I'm not actually interested in adjusting gallium to the constraints of one particular driver, but *am* quite interested in finding a way to improve linkage issues across the hardware we support. If you take a look at i965, I think you'll see that the change you're suggesting does nothing to avoid retranslating vertex shaders on that platform. Likewise the software rasterizers and any driver relying on the draw module are currently jumping through hoops to emulate a routing table, which wouldn't be improved by your change. But your change does dramatically alter the meaning of one part of gallium and introduces a new raft of hardware capabilities we'd have to be checking and respecting in every state tracker. If we are going to adjust gallium, lets figure out a way to improve linkage generally. Adding a per-driver, per-semantic maximum index query just for the benefit of one driver doesn't strike me as a good trade-off. Keith From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca Barbieri [l...@luca-barbieri.com] Sent: Monday, February 01, 2010 9:15 AM To: Keith Whitwell Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots DX9 semantic indexes are apparently unlimited According to http://msdn.microsoft.com/en-us/library/ee418355%28VS.85%29.aspx, this is not the case. Here is the relevant text: These semantics have meaning when attached to a vertex-shader parameters. These semantics are supported in both Direct3D 9 and Direct3D 10. [...] n is an optional integer between 0 and the number of resources supported. For example, POSITION0, TEXCOOR1, etc. [...] These semantics have meaning when attached to a pixel-shader input parameter. These semantics are supported in both Direct3D 9 and Direct3D 10. [...] n is an optional integer between 0 and the number of resources supported. For example, PSIZE0, COLOR1, etc. Thus, both DX9 and DX10 do not need arbitrary indices. OpenGL also doesn't, as fragment.texcoord[i] has i GL_MAX_TEXTURE_COORDS_ARB. It seems to make sense to follow those APIs in the design of Gallium semantics. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
On 01.02.2010 17:31, Keith Whitwell wrote: Christoph, Luca, Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware we end up implementing it by passing both front and back colors to the fragment shader and selecting between them using the FACE variable. If we removed the implicit fixed-function support for two-side lighting in the rasterizer, it would solve the issue of how this is represented in any routing table. How does that sit with your drivers? Keith It would work, if the COLOR semantic is completely ignored, i.e. I would appreciate the insertion of clamping instructions on the st side (I suspect earlier cards will not have 4 front color registers so clamping will go away for their back colors too ...). I can only select 2 x 8 consecutive scalar values in the routing table to be clamped, and only 1 x 8 will get through to the fragment shader. I'll not be happy to insert clamping manually, but I can do if it turns out to be the best solution to not have the st do it. It's a bit of a waste not to use that hw cap though ... otoh not many apps will use two sided lighting nowadays I suppose. From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca Barbieri [l...@luca-barbieri.com] Sent: Monday, February 01, 2010 7:29 AM To: Christoph Bumiller Cc: Keith Whitwell; mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots I can't really use a routing table state to produce a cso, because the hw routing table I generate depends on rasterizer state, e.g. I must not put in back face colour (we have a 2 to 1 mapping here) if twoside is disabled. Also, I'm routing based on the scalar *components* the FP reads, not whole TGSI pseudo vec4 registers (NUM_INTERPOLATORS will thus be inaccurate) - set_routing_table will have to pass me the respective programs too. Well, I can still use the cso and insert it into the rest of the routing table that still need to be assembled on the fly, I did that before the 1:1 mapping between FP and VP regs was removed. You are right, the routing table CSO needs to contain the fragment and vertex shader handles, and ideally light_twoside should be moved to the vertex-fragment routing table since it is really an attribute of that and not polygon rasterization/setup. You can then just look at your internal data structure and construct a scalar routing table from the vec4 one provided by Gallium. We could also, as a further extension, support scalar routing tables directly in Gallium. Note however that radeon hardware presumably only supports vector ones, so we would need all 3 options with caps. A further intermediate step could be vector routing tables with swizzling. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
On Mon, Feb 1, 2010 at 10:35 AM, tom fogal tfo...@alumni.unh.edu wrote: Mike Stroyan m...@lunarg.com writes: The changes to load EGL drivers by pattern matching had the side effect of not looking in the directories specified by LD_LIBRARY_PATH or -rpath or ldconfig . This is silly. If you give dlopen a library name: dlopen(libWhatever.so, flags); then *it* will automatically search LD_LIBRARY_PATH. By giving an absolute path, one circumvents this behavior. Tom, The reason this code is not just using dlopen with a library name is that the _eglPreloadDisplayDrivers function is attempting to find all driver libraries that match a pattern such as egl_x11_*.so. Any one of those libraries might be the best one to use. It loads them all and uses a Probe function in each driver to look for the best match for the hardware. dlopen itself cannot find libraries that match a pattern. -- Mike Stroyan - Software Architect LunarG, Inc. - The Graphics Experts Cell: (970) 219-7905 Email: m...@lunarg.com Website: http://www.lunarg.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
On 01.02.2010 18:37, Roland Scheidegger wrote: On 31.01.2010 18:41, Christoph Bumiller wrote: On 31.01.2010 01:37, Roland Scheidegger wrote: Marek Olšák wrote: 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in the fragment constants reads, Since Gallium doesn't support GL_ARB_shadow_ambient, this is always (0,0,0,0), right? I think the extension could be added to Gallium since the r300 compiler can generate code for it. It could. But generally, gallium doesn't implement features common hardware can't do (not only because most drivers except software based ones couldn't implement it, but those features also turn out to be rarely used, for obvious reasons). r300 is an exception here since it emulates ARB_shadow anyway. Though I think if you can make a case why this is really necessary it could be done, but that's not my call. Another comment reads, Gallium doesn't provide us with any information regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE, above the texture compare modes. I don't really like that section of code, but it probably can't get cleaner, right? Even though this is a rarely used feature in OpenGL nowadays, it should get fixed if we want to be GL-compliant. That means adding depth texture modes in pipe_sampler_state and setting them in the Mesa state tracker. The R300 compiler can already generate code for these modes as well. Note R300 is again special a bit here. Actually, I realized my earlier answer doesn't make sense. Hardware which actually supports EXT_texture_swizzle (and native ARB_shadow) should be able to implement this easily. Hardware like i965 which doesn't support EXT_texture_swizzle could do it in the shader. Maybe it would make sense to add EXT_texture_swizzle capability in gallium (in the sampler state). That would solve this in a bit more generic way than some special bits for depth texture mode. From my point of view adding a swizzle in the sampler state is a bad idea. On nv50, this would make texture setup dependent on sampler state: we have an Image and Sampler configuration buffer containing entries that can be bound to texture and sampler units. The texture swizzle would be supported by setting a different format in the image entry, like BGRA instead of RGBA, just that it also supports RGRG or whatever you like. Well, the normalization bit seems to be stored in the TIC entries instead of the TSC ones already, I guess that comes from the rectangle texture type, but let's ignore that. I don't see texture swizzle in d3d10 (but then, I don't know d3d10 very well), and OpenGL doesn't separate textures and samplers anyway, so I'd put in in texture state. Keeping a bunch of shaders for texture swizzles doesn't sound nice either. Of course, if other hardware would prefer this in sampler state, then ... ah, I should probably let go of the illusion that gallium state will continue to nicely map to my hardware ... I don't know if other hardware likes it in sampler state, but the problem is it really is sampler state. This is not a property of the texture, it can change anytime and you don't want to recreate the texture just because this changes, I think. I'm not sure how to implement this nicely neither, but I'd guess we'd at least wanted to indicate the swizzle fields to correspond to hardware channels (so for a luminance_alpha texture, the swizzle would indicate rrrg for the first and second channels respectively), not the GL-after-sampling mapping as the extension uses. Hence depth textures used as luminance would be rrr1, as alpha 000r, and as intensity . So, basically, a texture a8l8 texture would be equivalent to a r8g8 texture, when used for sampling with the same swizzling. Note that an easy solution (for depth textures) would be to add just new depth texture formats (one for each alpha, luminance, and intensity mode), but then again you make this part of the texture, which it is not. Those are just some quick thoughts however, I don't think anyone would be opposed if you can come up with a nice solution for this. Roland You're right, having to destroy and recreate the texture when the swizzle changes is a bad idea. And adding a mutable swizzle entry to pipe_texture is too, or at least it's equivalent to me keeping a private last_swizzle and re- uploading the image entry when it changes. That said, I'm fine with the idea of a swizzle entry in the sampler state now, in the format that each swizzle entry indicates which data element to use (the 1st, 2nd, ..., one or zero). E.g. for R8G8, swizzle = 2 / Z would be invalid ... yes, I think I'm thinking the same way you do here. Christoph -- The Planet: dedicated and managed hosting, cloud storage,
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
I propose that the following language be added to the spec: Gallium has no explicit mechanism for linking shaders. Shaders are implicitly linked in a pipeline at render time. Thus, linking must not fail and the pipe driver is permitted to change shader semantics to preserve linking. If a shader uses non-consecutive semantics, the pipe driver may remap them to be consecutive, within the bounds of other currently bound state. For example, if a shader samples from samplers 3 and 5, but the only samplers bound are 0 and 1, the driver may adjust the shader to sample from samplers 0 and 1 instead. If the bound shader pipeline does not have consistent outputs and inputs, the driver is permitted to remap them to be consistent through a driver-specific mechanism. For example, if a vertex shader writes generic 1, a fragment shader references generic 0, and there is no geometry shader bound, the pipe driver may change the vertex shader to write generic 0, or it may use a driver-specific internal routing table to route generic 1 to generic 0. If the total count of each semantic attribute written by the vertex shader does not match the counts read by the fragment shader, the driver may discard extraneous attributes and the values of missing attributes are undefined. If a geometry shader is present, this adjustment may happen on the vertex to geometry linking and geometry to fragment linking. I think this about covers it. This language seems *very* reasonable to me, while not totally ignoring the problems faced by nv50. ~ C. On Mon, Feb 1, 2010 at 7:29 AM, Luca Barbieri l...@luca-barbieri.com wrote: I can't really use a routing table state to produce a cso, because the hw routing table I generate depends on rasterizer state, e.g. I must not put in back face colour (we have a 2 to 1 mapping here) if twoside is disabled. Also, I'm routing based on the scalar *components* the FP reads, not whole TGSI pseudo vec4 registers (NUM_INTERPOLATORS will thus be inaccurate) - set_routing_table will have to pass me the respective programs too. Well, I can still use the cso and insert it into the rest of the routing table that still need to be assembled on the fly, I did that before the 1:1 mapping between FP and VP regs was removed. You are right, the routing table CSO needs to contain the fragment and vertex shader handles, and ideally light_twoside should be moved to the vertex-fragment routing table since it is really an attribute of that and not polygon rasterization/setup. You can then just look at your internal data structure and construct a scalar routing table from the vec4 one provided by Gallium. We could also, as a further extension, support scalar routing tables directly in Gallium. Note however that radeon hardware presumably only supports vector ones, so we would need all 3 options with caps. A further intermediate step could be vector routing tables with swizzling. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
olv, Here is a version of the patch that uses EGL_DRIVERS_PATH and checks for setuid/setgid before using EGL_DRIVER or EGL_DRIVERS_PATH. I want to avoid suffix matching somehow. I am not clear about the motive for a less than exact check for the library suffix in EGL_DRIVER. Are you interested in a looser need_suffix test for performance reasons? Or do you expect that there will be some driver libraries that don't end with the normal suffix? -- Mike Stroyan - Software Architect LunarG, Inc. - The Graphics Experts Cell: (970) 219-7905 Email: m...@lunarg.com Website: http://www.lunarg.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
I haven't tried to probe crazy high numbers, but within reason, my experience is that the numbers are unconstrained. No, according to that document if you use TEXCOORD[n] then n NUM_TEXCOORDS. TEXCOORD[n] Texture coordinates float4 [...] n is an optional integer between 0 and the number of resources supported. For example, POSITION0, TEXCOOR1, etc. Also look at the spec for ARB_fragment_program: fragAttribItem ::= color optColorType | texcoord optTexCoordNum [...] optTexCoordNum ::= | [ texCoordNum ] optColorType ::= | . primary | . secondary texCoordNum ::= integer from 0 to MAX_TEXTURE_COORDS_ARB-1 fragment.texcoord has the index limited by MAX_TEXTURE_COORDS_ARB. It seems to me pretty clear from the above references that *all* 3D APIs (i.e. DX9, DX10 and GL) have semantic indices in the range 0...N-1 where N is the limit appropriate for the specific semantic. I think these references contradict your hypotesis that there is no constraint in DX9. Am I misunderstanding something completely? Do you disagree with the fact that those references clearly show that semantic indices are limited by hardware resources? Now, your particular hardware has a additional limitation which is fairly unique, and you're pushing a change to gallium which would mimic the restrictions of your hardware. I'm not actually interested in adjusting gallium to the constraints of one particular driver, but *am* quite interested in finding a way to improve linkage issues across the hardware we support. No, it is a limitation that any hardware that does a direct implementation of OpenGL has. For instance, I'd guess that the VMWare driver works around that problem somewhere since it ultimately uses the host OpenGL implementation. With my proposal, it could just convert GENERIC[0] into fragment.texcoord[0] and likewise for others. But your change does dramatically alter the meaning of one part of gallium and introduces a new raft of hardware capabilities we'd have to be checking and respecting in every state tracker. Not at all. All code except the GLSL linker will work optimally as is, since it uses indices sequentially starting from 0 (or implements an API that does). I provided a patch to fix the GLSL linker. If we are going to adjust gallium, lets figure out a way to improve linkage generally. Adding a per-driver, per-semantic maximum index query just for the benefit of one driver doesn't strike me as a good trade-off. It is already necessary to have that to implement glGet of GL_MAX_TEXTURE_COORDS_ARB, for the TEXCOORD capability. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
Speaking of texture formats and texture sampling, one area of Gallium that's under-specified is what (x,y,z,w) values are returned by TEX instructions when sampling from each of the various texture formats. A while back I started a table comparing OpenGL to D3D: texture componentsOpenGL D3D --- R,G,B,A (R,G,B,A) (R,G,B,A) R,G,B (R,G,B,1) (R,G,B,1) R,G (R,G,0,1) (R,G,1,1) R (R,0,0,1) (R,1,1,1) A (0,0,0,A) (0,0,0,A) L (L,L,L,1) (L,?,?,1) (probably L,L,L,1) I (I,I,I,I) (?,?,?,?) UV(0,0,0,1)* (U,V,1,1) Z (Z,Z,Z,Z) or (0,Z,0,1) (Z,Z,Z,1) or (0,0,0,Z)** other formats?...... * per http://www.opengl.org/registry/specs/ATI/envmap_bumpmap.txt ** depends on GL_DEPTH_TEXTURE_MODE state For OpenGL, see page 141 of the OpenGL 3.1 spec. For D3D, see http://msdn.microsoft.com/en-us/library/ee422472(VS.85).aspx We should first add a column to the above table for Gallium and then decide whether to implement swizzling (and GL_DEPTH_TEXTURE_MODE) with extra GPU instructions or new texture/sampler swizzle state. -Brian -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
Luca, Where the semantic indicates some relationship to actual system resources, I agree that the number is constrained by the number of those system resources. In the case of the gallium GENERIC semantic, there is explicitly no system resource that semantic is referring to and hence no limit on the index. I feel like we're going in circles here. We agree that we want to improve linkage, you have a patch that helps your driver, but please accept that it doesn't solve the wider problem. Keith From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca Barbieri [l...@luca-barbieri.com] Sent: Monday, February 01, 2010 10:50 AM To: Keith Whitwell Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots I haven't tried to probe crazy high numbers, but within reason, my experience is that the numbers are unconstrained. No, according to that document if you use TEXCOORD[n] then n NUM_TEXCOORDS. TEXCOORD[n] Texture coordinates float4 [...] n is an optional integer between 0 and the number of resources supported. For example, POSITION0, TEXCOOR1, etc. Also look at the spec for ARB_fragment_program: fragAttribItem ::= color optColorType | texcoord optTexCoordNum [...] optTexCoordNum ::= | [ texCoordNum ] optColorType ::= | . primary | . secondary texCoordNum ::= integer from 0 to MAX_TEXTURE_COORDS_ARB-1 fragment.texcoord has the index limited by MAX_TEXTURE_COORDS_ARB. It seems to me pretty clear from the above references that *all* 3D APIs (i.e. DX9, DX10 and GL) have semantic indices in the range 0...N-1 where N is the limit appropriate for the specific semantic. I think these references contradict your hypotesis that there is no constraint in DX9. Am I misunderstanding something completely? Do you disagree with the fact that those references clearly show that semantic indices are limited by hardware resources? Now, your particular hardware has a additional limitation which is fairly unique, and you're pushing a change to gallium which would mimic the restrictions of your hardware. I'm not actually interested in adjusting gallium to the constraints of one particular driver, but *am* quite interested in finding a way to improve linkage issues across the hardware we support. No, it is a limitation that any hardware that does a direct implementation of OpenGL has. For instance, I'd guess that the VMWare driver works around that problem somewhere since it ultimately uses the host OpenGL implementation. With my proposal, it could just convert GENERIC[0] into fragment.texcoord[0] and likewise for others. But your change does dramatically alter the meaning of one part of gallium and introduces a new raft of hardware capabilities we'd have to be checking and respecting in every state tracker. Not at all. All code except the GLSL linker will work optimally as is, since it uses indices sequentially starting from 0 (or implements an API that does). I provided a patch to fix the GLSL linker. If we are going to adjust gallium, lets figure out a way to improve linkage generally. Adding a per-driver, per-semantic maximum index query just for the benefit of one driver doesn't strike me as a good trade-off. It is already necessary to have that to implement glGet of GL_MAX_TEXTURE_COORDS_ARB, for the TEXCOORD capability. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Re-using OpenGL texture names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Bumiller wrote: I just noticed that alienarena fails to create an FBO for depth rendering because on st_validate_framebuffer, the depth attachment contains a pt in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp) reports as not supported in screen-is_format_supported if usage is ZS. This happens because the app seems to use a texture ID that has already been used with mipmaps, and so st_TexImage doesn't create a new pipe texture with the different format, because teximage_realloc is false (NULL passed to glTexImage2D). I'm not sure if that is to be regarded as an application bug or if we should dump the other mipmap levels an reallocate nonetheless, so I'm asking here (I guess the nvidia blob seems to permit this behaviour, I already had another issue with this game where it was too forgiving). Just to be clear: It never calls glDeleteTextures? It calls glTexImage2D with pixels=NULL. Does it do this for every level or just for the base level? Is a mipmap filter in use? Is the LOD clamped? Based on what you've written, I believe that the app is doing something dumb that is technically legal. If the selected mipmap range (which is just the base level when a non-mipmap filter is used) is complete, then it should work. A piglit test that passes on a binary blob but fails on Mesa would be welcomed. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktnM9IACgkQX1gOwKyEAw/3LwCfZB5zVfiolqYgYGaAiLc5YsaS 5lcAn3fVytFydfcs36XkU5nAI1BR9eB3 =hi/E -END PGP SIGNATURE- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Re-using OpenGL texture names
Christoph Bumiller wrote:
I just noticed that alienarena fails to create an FBO for depth rendering
because on st_validate_framebuffer, the depth attachment contains a pt
in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp)
reports as not supported in screen-is_format_supported if usage is ZS.
This happens because the app seems to use a texture ID that has
already been used with mipmaps, and so st_TexImage doesn't create
a new pipe texture with the different format, because teximage_realloc
is false (NULL passed to glTexImage2D).
I'm not sure if that is to be regarded as an application bug or if we should
dump the other mipmap levels an reallocate nonetheless, so I'm asking here
(I guess the nvidia blob seems to permit this behaviour, I already had
another issue with this game where it was too forgiving).
Christoph, can you try the attached patch to the state tracker?
-Brian
diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src/mesa/state_tracker/st_cb_texture.c
index cee2452..0a7b222 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -543,22 +543,15 @@ st_TexImage(GLcontext * ctx,
_mesa_align_free(texImage-Data);
}
- if (width == 0 || height == 0 || depth == 0) {
- /* stop after freeing old image */
- return;
- }
-
- /* If this is the only mipmap level in the texture, could call
-* bmBufferData with NULL data to free the old block and avoid
-* waiting on any outstanding fences.
+ /*
+* See if the new image is somehow incompatible with the existing
+* mipmap. If so, free the old mipmap.
*/
if (stObj-pt) {
if (stObj-teximage_realloc ||
level (GLint) stObj-pt-last_level ||
- (stObj-pt-last_level == level
- stObj-pt-target != PIPE_TEXTURE_CUBE
- !st_texture_match_image(stObj-pt, stImage-base,
- stImage-face, stImage-level))) {
+ !st_texture_match_image(stObj-pt, stImage-base,
+ stImage-face, stImage-level)) {
DBG(release it\n);
pipe_texture_reference(stObj-pt, NULL);
assert(!stObj-pt);
@@ -566,6 +559,11 @@ st_TexImage(GLcontext * ctx,
}
}
+ if (width == 0 || height == 0 || depth == 0) {
+ /* stop after freeing old image */
+ return;
+ }
+
if (!stObj-pt) {
guess_and_alloc_texture(ctx-st, stObj, stImage);
if (!stObj-pt) {
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
Where the semantic indicates some relationship to actual system resources, I agree that the number is constrained by the number of those system resources. In the case of the gallium GENERIC semantic, there is explicitly no system resource that semantic is referring to and hence no limit on the index. GENERIC[i] refers to a slot in the output register file of the vertex shader or a slot in the input register file of the fragment shader. It also refers to the interpolator unit that interpolates data between those two registers. Since interpolators are usually available in a finite number and register files also are usually physically limited, there should be a limit on the index. I feel like we're going in circles here. We agree that we want to improve linkage, you have a patch that helps your driver, but please accept that it doesn't solve the wider problem. Yes. In the following I try to write out my reasoning step by step, in the hope of making it clearer and making it easier to both establish which facts we agree are true and pinpoint what we may disagree on. This is a list of steps that are leading me to conclusion that it is best to change the Gallium rules so that semantic indices must be in the range 0..N-1, where is N is the maximum number of simultaneously available registers with that semantic, apply my GLSL patch to fix GLSL, and after doing that, consider extending Gallium by letting the user specify a routing table to link these limited index semantics with something other than an identity mapping. Please tell me which points you find are incorrect, or why one any deduction does not follow from the antecedents. 1. All the semantic indices in OpenGL are limited, according to the ARB specification 2. All the sematic indices in DirectX 9/10 are limited, according to http://msdn.microsoft.com/en-us/library/ee418355%28VS.85%29.aspx 3. In the OpenGL/DirectX 9/10 model, there are a fixed number of interpolators, numbered from 0 to N - 1. Interpolator K reads from vertex shader output register K, interpolates and writes to fragment shader input register K. 4. Some cards (e.g. r300), but not all, allow to configure the vertex shader input register and fragment shader output register that interpolator K reads and writes. 5. Such register inputs are usually offsets in a physical register file, and thus are limited to the physical size of that register file 6. No API exposes the functionality in point 4 and all expose the more rigid model in (3.) 7. Gallium GENERIC is equivalent to OpenGL texcoord and DirectX 9/10 TEXCOORD semantics 8. texcoord is called this way because of historical reasons, since fixed pipelines could use the values only for texture sampling. GENERIC is called GENERIC instead of TEXCOORD because Gallium was designed with a programmable pipeline in mind. 9. The current Mesa implementation of ARB_fp/vp translates texcoord[i] to GENERIC[i] 10. fragment.texcoord[K] has K limited by GL_MAX_TEXTURE_COORDS_ARB 11. Because of (9.) and (10.), the current Mesa implementation of ARB_vp/fp uses GENERIC indices limited by GL_MAX_TEXTURE_COORDS_ARB (perhaps plus a very small constant) 12. Because of (2.), a straightforward Gallium DirectX state tracker would also use GENERIC indices limited by the number of interpolators 13. If GLSL did not reserve sematic indices for unused gl_TexCoord[] varyings, but allocated varyings sequentially, then it would use semantic indices sequentially starting from 0 14. My patch implements (13.) 15. The xorg, vega and g3dvl state trackers use GENERIC indices starting from 0 up to 1, 1 and 7 respectively 16. Because of (11.), (12.), (13.), (14.) and (15.), after applying my patch, limiting the value of GENERIC semantic indices to the number of interpolators would not adversely affect Mesa/Gallium functionality in any way, probably including the VMware DirectX state tracker 17. Driver code would be simplified by not having to worry about any register semantic remapping. It will be possible to separately compile fragment and vertex shaders on all hardware. The CPU usage of all drivers will be reduced, especially when switching shaders (a fast path!) 18. Thus, (16.) is a net gain for Gallium, and should go forward [Note: my current nv40 tree does exactly (16.) this and this does not seem to be a source of any problem] Points that lead me to propose a routing table CSO *IN ADDITION* to applying my GLSL patch: 19. Some current 3D APIs (ARB_fp/vp, DX PS, EXT_separate_shader_objects) link vertex and fragment shaders by matching physical register file offset, limited to index N - 1 where N is the maximum number of usage variables (see (3.)) 20. Other 3D APIs (GLSL) link by matching variable name. This forces to have the requirement, in unextended GLSL, to provide both the fragment and vertex shaders at once in the link step 21. No API links by matching abstract unlimited variable number, except some Gallium driver interfaces such as r300 22. It would be
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
This++. I've been scratching my head at some of these; having them specified would be great. Posting from a mobile, pardon my terseness. ~ C. On Feb 1, 2010 11:25 AM, Brian Paul bri...@vmware.com wrote: Speaking of texture formats and texture sampling, one area of Gallium that's under-specified is what (x,y,z,w) values are returned by TEX instructions when sampling from each of the various texture formats. A while back I started a table comparing OpenGL to D3D: texture componentsOpenGL D3D --- R,G,B,A (R,G,B,A) (R,G,B,A) R,G,B (R,G,B,1) (R,G,B,1) R,G (R,G,0,1) (R,G,1,1) R (R,0,0,1) (R,1,1,1) A (0,0,0,A) (0,0,0,A) L (L,L,L,1) (L,?,?,1) (probably L,L,L,1) I (I,I,I,I) (?,?,?,?) UV(0,0,0,1)* (U,V,1,1) Z (Z,Z,Z,Z) or (0,Z,0,1) (Z,Z,Z,1) or (0,0,0,Z)** other formats?...... * per http://www.opengl.org/registry/specs/ATI/envmap_bumpmap.txt ** depends on GL_DEPTH_TEXTURE_MODE state For OpenGL, see page 141 of the OpenGL 3.1 spec. For D3D, see http://msdn.microsoft.com/en-us/library/ee422472(VS.85).aspx We should first add a column to the above table for Gallium and then decide whether to implement swizzling (and GL_DEPTH_TEXTURE_MODE) with extra GPU instructions or new texture/sampler swizzle state. -Brian -- The Planet: dedicate... -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Re-using OpenGL texture names
On 01.02.2010 21:44, Brian Paul wrote: Christoph Bumiller wrote: I just noticed that alienarena fails to create an FBO for depth rendering because on st_validate_framebuffer, the depth attachment contains a pt in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp) reports as not supported in screen-is_format_supported if usage is ZS. This happens because the app seems to use a texture ID that has already been used with mipmaps, and so st_TexImage doesn't create a new pipe texture with the different format, because teximage_realloc is false (NULL passed to glTexImage2D). I'm not sure if that is to be regarded as an application bug or if we should dump the other mipmap levels an reallocate nonetheless, so I'm asking here (I guess the nvidia blob seems to permit this behaviour, I already had another issue with this game where it was too forgiving). Christoph, can you try the attached patch to the state tracker? -Brian Yes, that would fix the issue, since the it's the last_level == level check that sets the condition false, I figured that out already. As to Ian's questions: The app doesn't use GenTextures or DeleteTextures, except when I close it. The new texture gets GL_NEAREST as MIN / MAX filters. Pixels is NULL, as I said. I don't think I'm going to write a piglit test right now, it's late. Maybe I'll think about it when I encounter the next issue I want to write a test for ... Thanks, Christoph. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
On 01.02.2010 20:23, Brian Paul wrote: Speaking of texture formats and texture sampling, one area of Gallium that's under-specified is what (x,y,z,w) values are returned by TEX instructions when sampling from each of the various texture formats. A while back I started a table comparing OpenGL to D3D: texture componentsOpenGL D3D --- R,G,B,A (R,G,B,A) (R,G,B,A) R,G,B (R,G,B,1) (R,G,B,1) R,G (R,G,0,1) (R,G,1,1) R (R,0,0,1) (R,1,1,1) A (0,0,0,A) (0,0,0,A) L (L,L,L,1) (L,?,?,1) (probably L,L,L,1) I (I,I,I,I) (?,?,?,?) UV(0,0,0,1)* (U,V,1,1) Z (Z,Z,Z,Z) or (0,Z,0,1) (Z,Z,Z,1) or (0,0,0,Z)** other formats?...... AL. Should be (L,L,L,A) for both OGL And D3D. And yes, (L,L,L,1) is correct for D3D (that's what i965 at least does). There are no intensity textures in d3d (unless you can somehow support that via cap bits, but in that case I'd certainly expect it to be (I,I,I,I)). UV is of course really odd in OGL, since it says the sample result is constant but of course you still use the UV components for the bump target. That's just an oddity to make that fit somehow into fixed function pipeline rather than it has anything to do with hardware. Note that the D3D column is only valid for DX9 (and older). DX10 uses the same mappings as OpenGL (if it supports the format, all luminance, alpha etc. textures are gone, as are the swizzled bgra formats). * per http://www.opengl.org/registry/specs/ATI/envmap_bumpmap.txt ** depends on GL_DEPTH_TEXTURE_MODE state For OpenGL, see page 141 of the OpenGL 3.1 spec. For D3D, see http://msdn.microsoft.com/en-us/library/ee422472(VS.85).aspx We should first add a column to the above table for Gallium and then decide whether to implement swizzling (and GL_DEPTH_TEXTURE_MODE) with extra GPU instructions or new texture/sampler swizzle state. But most gpus can do arbitrary swizzling natively, hence inserting gpu instructions really must be optional. Even hardware which can't do arbitrary swizzling can sometimes do both OGL and D3D mapping, hence we don't really want additional instructions there neither (i965 being the example, though it's not easy to switch behavior, since that affects not only the format of the border color too but also how the border color is used if the particular channel isn't in the texture). I think we'd want DX10/OGL behavior, and u_format defines it that way. Except for depth/stencil formats, where the depth always ends up in the red channel and stencil in green (with the rest undefined). i965 actually has different depth/stencil formats (a24x8, l24x8, i24x8) just for those depth texture modes (though the code suggests it won't do anything if shadow comparison is enabled). Or maybe we'd want additional formats just for DX9 - sounds like overkill though. The different border color interpretation of i965 suggests to me that won't do much on its own for conformance anyway. I think the swizzle values used by u_format are nice. Using xyzw rather than rgba to refer to the first, etc. channel avoids confusion. Hence I'd propose we'd use the same for the hypothetical sampler swizzle state (that is x,y,z,w,0,1, not sure if the _ undefined makes sense there). The swizzling would be the same as that indicated in u_format for all textures initially, except depth/stencil. Roland -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Fix progs/es2/xegl/tri.c
The progs/es2/xegl/tri.c demo fails using, eglQuerySurface() with
EGL_SURFACE_TYPE.
Only eglGetConfigAttrib can query EGL_SURFACE_TYPE.
This patch replaces that with querying EGL_CONFIG_ID, then using that
ID to call eglChooseConfig and using that config to call
eglGetConfigAttrib() with EGL_SURFACE_TYPE.
--
Mike Stroyan - Software Architect
LunarG, Inc. - The Graphics Experts
Cell: (970) 219-7905
Email: m...@lunarg.com
Website: http://www.lunarg.com
From 4afd26abdeca4c0f600078abc21f000983296911 Mon Sep 17 00:00:00 2001
From: Mike Stroyan m...@lunarg.com
Date: Mon, 1 Feb 2010 14:32:40 -0700
Subject: [PATCH] Use eglGetConfigAttrib EGL_SURFACE_TYPE in tri.c
---
progs/es2/xegl/tri.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/progs/es2/xegl/tri.c b/progs/es2/xegl/tri.c
index 7729a09..bb16780 100644
--- a/progs/es2/xegl/tri.c
+++ b/progs/es2/xegl/tri.c
@@ -340,8 +340,18 @@ make_x_window(Display *x_dpy, EGLDisplay egl_dpy,
assert(val == width);
eglQuerySurface(egl_dpy, *surfRet, EGL_HEIGHT, val);
assert(val == height);
- eglQuerySurface(egl_dpy, *surfRet, EGL_SURFACE_TYPE, val);
- assert(val == EGL_WINDOW_BIT);
+ {
+ EGLConfig config;
+ EGLint num_configs;
+ static EGLint attribs[3];
+ attribs[0] = EGL_CONFIG_ID;
+ attribs[2] = EGL_NONE;
+ assert(eglQuerySurface(egl_dpy, *surfRet, EGL_CONFIG_ID, attribs[1]));
+ assert(eglChooseConfig(egl_dpy, attribs, config, 1, num_configs));
+ assert(num_configs);
+ assert(eglGetConfigAttrib(egl_dpy, config, EGL_SURFACE_TYPE, val));
+ assert(val EGL_WINDOW_BIT);
+ }
}
XFree(visInfo);
--
1.6.3.3
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 26317] glsl compiled wrong
http://bugs.freedesktop.org/show_bug.cgi?id=26317 --- Comment #9 from Brian Paul brian.e.p...@gmail.com 2010-02-01 16:36:35 PST --- Fixed on mesa 7.7 branch with commit e0d01c9d7f46ccd531f8dd1a04c5ac067200ef1e A regression test has been added to glean/glsl1 test. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Re-using OpenGL texture names
Christoph Bumiller wrote: On 01.02.2010 21:44, Brian Paul wrote: Christoph Bumiller wrote: I just noticed that alienarena fails to create an FBO for depth rendering because on st_validate_framebuffer, the depth attachment contains a pt in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp) reports as not supported in screen-is_format_supported if usage is ZS. This happens because the app seems to use a texture ID that has already been used with mipmaps, and so st_TexImage doesn't create a new pipe texture with the different format, because teximage_realloc is false (NULL passed to glTexImage2D). I'm not sure if that is to be regarded as an application bug or if we should dump the other mipmap levels an reallocate nonetheless, so I'm asking here (I guess the nvidia blob seems to permit this behaviour, I already had another issue with this game where it was too forgiving). Christoph, can you try the attached patch to the state tracker? -Brian Yes, that would fix the issue, since the it's the last_level == level check that sets the condition false, I figured that out already. The logic there for determining whether or not to free the existing texture/mipmap looked questionable. Going back through git history, it looks like the code was that way since day one. I've cleaned it and committed the change. As to Ian's questions: The app doesn't use GenTextures or DeleteTextures, except when I close it. The new texture gets GL_NEAREST as MIN / MAX filters. Pixels is NULL, as I said. I don't think I'm going to write a piglit test right now, it's late. Maybe I'll think about it when I encounter the next issue I want to write a test for ... I quickly hacked up progs/tests/fbotest3.c to test this issue. It would be great if you or someone else would make it into a piglit test. -Brian -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] switch shaders assembly TGSI code by tgsi_ureg
Hi again, Third version: removing debug messages Igor On Mon, Feb 1, 2010 at 10:08 PM, Igor Oliveira igor.olive...@openbossa.org wrote: Hi, I am resenting the patches, i fixed some bugs in ureg functions and did some clean up in shaders cache code. i tested it with all progs/openvg files. Igor On Mon, Feb 1, 2010 at 1:02 PM, Zack Rusin za...@vmware.com wrote: On Monday 01 February 2010 10:19:53 Igor Oliveira wrote: Hello, Theses patchs switch all shaders code implemeted using TGSI assembly by tgsi_ureg. Hey Igor, very nice work! Since I don't have the conformance framework anymore, did you test your changes with the examples that we have? Before committing it'd be nice to know that we won't get too many obvious regressions. z From 81a644140b7a5185d4b200a0ac6cfa3384bed152 Mon Sep 17 00:00:00 2001 From: Igor Oliveira igor.olive...@openbossa.org Date: Mon, 1 Feb 2010 22:01:51 -0400 Subject: [PATCH 1/2] vega: change tgsi asm by tgsi_ureg --- src/gallium/state_trackers/vega/asm_fill.h | 551 +++- 1 files changed, 380 insertions(+), 171 deletions(-) diff --git a/src/gallium/state_trackers/vega/asm_fill.h b/src/gallium/state_trackers/vega/asm_fill.h index 2f394ad..2777346 100644 --- a/src/gallium/state_trackers/vega/asm_fill.h +++ b/src/gallium/state_trackers/vega/asm_fill.h @@ -27,166 +27,375 @@ #ifndef ASM_FILL_H #define ASM_FILL_H -static const char solid_fill_asm[] = - MOV %s, CONST[0]\n; - - -static const char linear_grad_asm[] = - MOV TEMP[0].xy, IN[0]\n - MOV TEMP[0].z, CONST[1].\n - DP3 TEMP[1], CONST[2], TEMP[0]\n - DP3 TEMP[2], CONST[3], TEMP[0]\n - DP3 TEMP[3], CONST[4], TEMP[0]\n - RCP TEMP[3], TEMP[3]\n - MUL TEMP[1], TEMP[1], TEMP[3]\n - MUL TEMP[2], TEMP[2], TEMP[3]\n - MOV TEMP[4].x, TEMP[1]\n - MOV TEMP[4].y, TEMP[2]\n - MUL TEMP[0], CONST[0]., TEMP[4].\n - MAD TEMP[1], CONST[0]., TEMP[4]., TEMP[0]\n - MUL TEMP[2], TEMP[1], CONST[0].\n - TEX %s, TEMP[2], SAMP[0], 1D\n; - -static const char radial_grad_asm[] = - MOV TEMP[0].xy, IN[0]\n - MOV TEMP[0].z, CONST[1].\n - DP3 TEMP[1], CONST[2], TEMP[0]\n - DP3 TEMP[2], CONST[3], TEMP[0]\n - DP3 TEMP[3], CONST[4], TEMP[0]\n - RCP TEMP[3], TEMP[3]\n - MUL TEMP[1], TEMP[1], TEMP[3]\n - MUL TEMP[2], TEMP[2], TEMP[3]\n - MOV TEMP[5].x, TEMP[1]\n - MOV TEMP[5].y, TEMP[2]\n - MUL TEMP[0], CONST[0]., TEMP[5].\n - MAD TEMP[1], CONST[0]., TEMP[5]., TEMP[0]\n - ADD TEMP[1], TEMP[1], TEMP[1]\n - MUL TEMP[3], TEMP[5]., TEMP[5].\n - MAD TEMP[4], TEMP[5]., TEMP[5]., TEMP[3]\n - MOV TEMP[4], -TEMP[4]\n - MUL TEMP[2], CONST[0]., TEMP[4]\n - MUL TEMP[0], CONST[1]., TEMP[2]\n - MUL TEMP[3], TEMP[1], TEMP[1]\n - SUB TEMP[2], TEMP[3], TEMP[0]\n - RSQ TEMP[2], |TEMP[2]|\n - RCP TEMP[2], TEMP[2]\n - SUB TEMP[1], TEMP[2], TEMP[1]\n - ADD TEMP[0], CONST[0]., CONST[0].\n - RCP TEMP[0], TEMP[0]\n - MUL TEMP[2], TEMP[1], TEMP[0]\n - TEX %s, TEMP[2], SAMP[0], 1D\n; - -static const char pattern_asm[] = - MOV TEMP[0].xy, IN[0]\n - MOV TEMP[0].z, CONST[1].\n - DP3 TEMP[1], CONST[2], TEMP[0]\n - DP3 TEMP[2], CONST[3], TEMP[0]\n - DP3 TEMP[3], CONST[4], TEMP[0]\n - RCP TEMP[3], TEMP[3]\n - MUL TEMP[1], TEMP[1], TEMP[3]\n - MUL TEMP[2], TEMP[2], TEMP[3]\n - MOV TEMP[4].x, TEMP[1]\n - MOV TEMP[4].y, TEMP[2]\n - RCP TEMP[0], CONST[1].zwzw\n - MOV TEMP[1], TEMP[4]\n - MUL TEMP[1].x, TEMP[1], TEMP[0]\n - MUL TEMP[1].y, TEMP[1], TEMP[0]\n - TEX %s, TEMP[1], SAMP[0], 2D\n; - - -static const char mask_asm[] = - TEX TEMP[1], IN[0], SAMP[1], 2D\n - MUL TEMP[0].w, TEMP[0]., TEMP[1].\n - MOV %s, TEMP[0]\n; - - -static const char image_normal_asm[] = - TEX %s, IN[1], SAMP[3], 2D\n; - -static const char image_multiply_asm[] = - TEX TEMP[1], IN[1], SAMP[3], 2D\n - MUL %s, TEMP[0], TEMP[1]\n; - -static const char image_stencil_asm[] = - TEX TEMP[1], IN[1], SAMP[3], 2D\n - MUL %s, TEMP[0], TEMP[1]\n; - - -#define EXTENDED_BLEND_OVER \ - SUB TEMP[3], CONST[1]., TEMP[1].\n \ - SUB TEMP[4], CONST[1]., TEMP[0].\n \ - MUL TEMP[3], TEMP[0], TEMP[3]\n\ - MUL TEMP[4], TEMP[1], TEMP[4]\n\ - ADD TEMP[3], TEMP[3], TEMP[4]\n - -static const char blend_multiply_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - EXTENDED_BLEND_OVER - MUL TEMP[4], TEMP[0], TEMP[1]\n - ADD TEMP[1], TEMP[4], TEMP[3]\n/*result.rgb*/ - MUL TEMP[2], TEMP[0]., TEMP[1].\n - ADD TEMP[3], TEMP[0]., TEMP[1].\n - SUB TEMP[1].w, TEMP[3], TEMP[2]\n - MOV %s, TEMP[1]\n; -#if 1 -static const char blend_screen_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - ADD TEMP[3], TEMP[0], TEMP[1]\n - MUL TEMP[2], TEMP[0], TEMP[1]\n - SUB %s, TEMP[3], TEMP[2]\n; -#else -static const char blend_screen_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - MOV %s, TEMP[1]\n; -#endif -
Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
A possible limitation of this scheme is that it doesn't readily map to hardware that can configure its own interpolators to behave either as GENERIC, COLOR (or some other semantic) dynamically. However, it seems to me that at least ARB_fragment_program only requires and supports 2 COLOR registers (primary and secondary), 1 FOG register and 1 PSIZE register. I'm not sure if any API can support more than 2 COLOR, 1 FOG and 1 PSIZE register as vertex shader outputs/fragment shader inputs (note that this is totally different from COLOR as a fragment shader output, where each COLOR semantic maps to a different render target), and thus I'm not sure if such functionality is useful. A driver with that functionality wishing to let an application use more than 2 COLORs is however free to do remapping in the driver even under my proposal. It just doesn't _have_ to do it. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] switch shaders assembly TGSI code by tgsi_ureg
Hi, I am resenting the patches, i fixed some bugs in ureg functions and did some clean up in shaders cache code. i tested it with all progs/openvg files. Igor On Mon, Feb 1, 2010 at 1:02 PM, Zack Rusin za...@vmware.com wrote: On Monday 01 February 2010 10:19:53 Igor Oliveira wrote: Hello, Theses patchs switch all shaders code implemeted using TGSI assembly by tgsi_ureg. Hey Igor, very nice work! Since I don't have the conformance framework anymore, did you test your changes with the examples that we have? Before committing it'd be nice to know that we won't get too many obvious regressions. z From 81a644140b7a5185d4b200a0ac6cfa3384bed152 Mon Sep 17 00:00:00 2001 From: Igor Oliveira igor.olive...@openbossa.org Date: Mon, 1 Feb 2010 22:01:51 -0400 Subject: [PATCH 1/2] vega: change tgsi asm by tgsi_ureg --- src/gallium/state_trackers/vega/asm_fill.h | 551 +++- 1 files changed, 380 insertions(+), 171 deletions(-) diff --git a/src/gallium/state_trackers/vega/asm_fill.h b/src/gallium/state_trackers/vega/asm_fill.h index 2f394ad..2777346 100644 --- a/src/gallium/state_trackers/vega/asm_fill.h +++ b/src/gallium/state_trackers/vega/asm_fill.h @@ -27,166 +27,375 @@ #ifndef ASM_FILL_H #define ASM_FILL_H -static const char solid_fill_asm[] = - MOV %s, CONST[0]\n; - - -static const char linear_grad_asm[] = - MOV TEMP[0].xy, IN[0]\n - MOV TEMP[0].z, CONST[1].\n - DP3 TEMP[1], CONST[2], TEMP[0]\n - DP3 TEMP[2], CONST[3], TEMP[0]\n - DP3 TEMP[3], CONST[4], TEMP[0]\n - RCP TEMP[3], TEMP[3]\n - MUL TEMP[1], TEMP[1], TEMP[3]\n - MUL TEMP[2], TEMP[2], TEMP[3]\n - MOV TEMP[4].x, TEMP[1]\n - MOV TEMP[4].y, TEMP[2]\n - MUL TEMP[0], CONST[0]., TEMP[4].\n - MAD TEMP[1], CONST[0]., TEMP[4]., TEMP[0]\n - MUL TEMP[2], TEMP[1], CONST[0].\n - TEX %s, TEMP[2], SAMP[0], 1D\n; - -static const char radial_grad_asm[] = - MOV TEMP[0].xy, IN[0]\n - MOV TEMP[0].z, CONST[1].\n - DP3 TEMP[1], CONST[2], TEMP[0]\n - DP3 TEMP[2], CONST[3], TEMP[0]\n - DP3 TEMP[3], CONST[4], TEMP[0]\n - RCP TEMP[3], TEMP[3]\n - MUL TEMP[1], TEMP[1], TEMP[3]\n - MUL TEMP[2], TEMP[2], TEMP[3]\n - MOV TEMP[5].x, TEMP[1]\n - MOV TEMP[5].y, TEMP[2]\n - MUL TEMP[0], CONST[0]., TEMP[5].\n - MAD TEMP[1], CONST[0]., TEMP[5]., TEMP[0]\n - ADD TEMP[1], TEMP[1], TEMP[1]\n - MUL TEMP[3], TEMP[5]., TEMP[5].\n - MAD TEMP[4], TEMP[5]., TEMP[5]., TEMP[3]\n - MOV TEMP[4], -TEMP[4]\n - MUL TEMP[2], CONST[0]., TEMP[4]\n - MUL TEMP[0], CONST[1]., TEMP[2]\n - MUL TEMP[3], TEMP[1], TEMP[1]\n - SUB TEMP[2], TEMP[3], TEMP[0]\n - RSQ TEMP[2], |TEMP[2]|\n - RCP TEMP[2], TEMP[2]\n - SUB TEMP[1], TEMP[2], TEMP[1]\n - ADD TEMP[0], CONST[0]., CONST[0].\n - RCP TEMP[0], TEMP[0]\n - MUL TEMP[2], TEMP[1], TEMP[0]\n - TEX %s, TEMP[2], SAMP[0], 1D\n; - -static const char pattern_asm[] = - MOV TEMP[0].xy, IN[0]\n - MOV TEMP[0].z, CONST[1].\n - DP3 TEMP[1], CONST[2], TEMP[0]\n - DP3 TEMP[2], CONST[3], TEMP[0]\n - DP3 TEMP[3], CONST[4], TEMP[0]\n - RCP TEMP[3], TEMP[3]\n - MUL TEMP[1], TEMP[1], TEMP[3]\n - MUL TEMP[2], TEMP[2], TEMP[3]\n - MOV TEMP[4].x, TEMP[1]\n - MOV TEMP[4].y, TEMP[2]\n - RCP TEMP[0], CONST[1].zwzw\n - MOV TEMP[1], TEMP[4]\n - MUL TEMP[1].x, TEMP[1], TEMP[0]\n - MUL TEMP[1].y, TEMP[1], TEMP[0]\n - TEX %s, TEMP[1], SAMP[0], 2D\n; - - -static const char mask_asm[] = - TEX TEMP[1], IN[0], SAMP[1], 2D\n - MUL TEMP[0].w, TEMP[0]., TEMP[1].\n - MOV %s, TEMP[0]\n; - - -static const char image_normal_asm[] = - TEX %s, IN[1], SAMP[3], 2D\n; - -static const char image_multiply_asm[] = - TEX TEMP[1], IN[1], SAMP[3], 2D\n - MUL %s, TEMP[0], TEMP[1]\n; - -static const char image_stencil_asm[] = - TEX TEMP[1], IN[1], SAMP[3], 2D\n - MUL %s, TEMP[0], TEMP[1]\n; - - -#define EXTENDED_BLEND_OVER \ - SUB TEMP[3], CONST[1]., TEMP[1].\n \ - SUB TEMP[4], CONST[1]., TEMP[0].\n \ - MUL TEMP[3], TEMP[0], TEMP[3]\n\ - MUL TEMP[4], TEMP[1], TEMP[4]\n\ - ADD TEMP[3], TEMP[3], TEMP[4]\n - -static const char blend_multiply_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - EXTENDED_BLEND_OVER - MUL TEMP[4], TEMP[0], TEMP[1]\n - ADD TEMP[1], TEMP[4], TEMP[3]\n/*result.rgb*/ - MUL TEMP[2], TEMP[0]., TEMP[1].\n - ADD TEMP[3], TEMP[0]., TEMP[1].\n - SUB TEMP[1].w, TEMP[3], TEMP[2]\n - MOV %s, TEMP[1]\n; -#if 1 -static const char blend_screen_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - ADD TEMP[3], TEMP[0], TEMP[1]\n - MUL TEMP[2], TEMP[0], TEMP[1]\n - SUB %s, TEMP[3], TEMP[2]\n; -#else -static const char blend_screen_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - MOV %s, TEMP[1]\n; -#endif - -static const char blend_darken_asm[] = - TEX TEMP[1], IN[0], SAMP[2], 2D\n - EXTENDED_BLEND_OVER - MUL TEMP[4], TEMP[0], TEMP[1].\n - MUL
Re: [Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
On Tue, Feb 2, 2010 at 2:49 AM, Mike Stroyan m...@lunarg.com wrote: Here is a version of the patch that uses EGL_DRIVERS_PATH and checks for setuid/setgid before using EGL_DRIVER or EGL_DRIVERS_PATH. The patch seems to be missing :) I want to avoid suffix matching somehow. I am not clear about the motive for a less than exact check for the library suffix in EGL_DRIVER. Are you interested in a looser need_suffix test for performance reasons? Or do you expect that there will be some driver libraries that don't end with the normal suffix? The latter. I expect EGL_DRIVER to be a full path. It is as well to me to remove the prefixing and suffixing code. -olv -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Fix progs/es2/xegl/tri.c
On Tue, Feb 2, 2010 at 6:06 AM, Mike Stroyan m...@lunarg.com wrote: The progs/es2/xegl/tri.c demo fails using, eglQuerySurface() with EGL_SURFACE_TYPE. Only eglGetConfigAttrib can query EGL_SURFACE_TYPE. This patch replaces that with querying EGL_CONFIG_ID, then using that ID to call eglChooseConfig and using that config to call eglGetConfigAttrib() with EGL_SURFACE_TYPE. I've commited a simplified version that reuses the same config. Thanks for pointing out the error. There are many sanity checks for EGL in various demos using EGL. Gradually, it should be better to collect them and write EGL regression tests, instead of hiding them in client API demos. -olv -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
On Mon, Feb 1, 2010 at 7:34 PM, Chia-I Wu olva...@gmail.com wrote:
On Tue, Feb 2, 2010 at 2:49 AM, Mike Stroyan m...@lunarg.com wrote:
Here is a version of the patch that uses EGL_DRIVERS_PATH and checks
for setuid/setgid
before using EGL_DRIVER or EGL_DRIVERS_PATH.
The patch seems to be missing :)
Here is the missing patch file.
--
Mike Stroyan - Software Architect
LunarG, Inc. - The Graphics Experts
Cell: (970) 219-7905
Email: m...@lunarg.com
Website: http://www.lunarg.com
From 4afd26abdeca4c0f600078abc21f000983296911 Mon Sep 17 00:00:00 2001
From: Mike Stroyan m...@lunarg.com
Date: Mon, 1 Feb 2010 14:32:40 -0700
Subject: [PATCH] Use EGL_DRIVERS_PATH
---
diff --git a/src/egl/main/egldriver.c b/src/egl/main/egldriver.c
index df36369..b31b631 100644
--- a/src/egl/main/egldriver.c
+++ b/src/egl/main/egldriver.c
@@ -56,7 +56,7 @@ close_library(HMODULE lib)
static const char *
library_suffix(void)
{
- return dll;
+ return .dll;
}
@@ -64,10 +64,18 @@ static EGLBoolean
make_library_path(char *buf, unsigned int size, const char *name)
{
EGLBoolean need_suffix;
- const char *suffix = .dll;
+ const char *suffix = library_suffix();
int ret;
- need_suffix = (strchr(name, '.') == NULL);
+ /* match the suffix */
+ if (suffix) {
+ size_t name_len = strlen(name);
+ size_t suffix_len = strlen(suffix);
+ need_suffix = (name_len suffix_len
+ || strcmp(name + name_len - suffix_len, suffix) != 0);
+ } else {
+ need_suffix = EGL_FALSE;
+ }
ret = snprintf(buf, size, %s%s, name, (need_suffix) ? suffix : );
return ((unsigned int) ret size);
@@ -84,7 +92,25 @@ typedef void * lib_handle;
static void *
open_library(const char *filename)
{
- return dlopen(filename, RTLD_LAZY);
+ void *handle;
+
+ /* first try opening without an explicit directory to allow search path */
+ handle = dlopen(filename, RTLD_LAZY);
+ if (handle) {
+ return handle;
+ }
+
+ /* if plain file unfound try adding _EGL_DRIVER_SEARCH_DIR directory */
+ if (strchr(filename, '/') == NULL) {
+ char path[1024];
+ int ret;
+ ret = snprintf(path, sizeof(path), %s%s,
+_EGL_DRIVER_SEARCH_DIR/, filename);
+ if ((unsigned int) ret sizeof(path)) {
+ return dlopen(path, RTLD_LAZY);
+ }
+ }
+ return NULL;
}
static void
@@ -97,23 +123,27 @@ close_library(void *lib)
static const char *
library_suffix(void)
{
- return so;
+ return .so;
}
static EGLBoolean
make_library_path(char *buf, unsigned int size, const char *name)
{
- EGLBoolean need_dir, need_suffix;
- const char *suffix = .so;
+ EGLBoolean need_suffix;
+ const char *suffix = library_suffix();
int ret;
- need_dir = (strchr(name, '/') == NULL);
- need_suffix = (strchr(name, '.') == NULL);
-
- ret = snprintf(buf, size, %s%s%s,
- (need_dir) ? _EGL_DRIVER_SEARCH_DIR/ : , name,
- (need_suffix) ? suffix : );
+ /* match the suffix */
+ if (suffix) {
+ size_t name_len = strlen(name);
+ size_t suffix_len = strlen(suffix);
+ need_suffix = (name_len suffix_len
+ || strcmp(name + name_len - suffix_len, suffix) != 0);
+ } else {
+ need_suffix = EGL_FALSE;
+ }
+ ret = snprintf(buf, size, %s%s, name, (need_suffix) ? suffix : );
return ((unsigned int) ret size);
}
@@ -333,55 +363,39 @@ _eglPreloadUserDriver(void)
#endif
}
-
+#if defined(_EGL_PLATFORM_POSIX)
/**
- * Preload display drivers.
- *
- * Display drivers are a set of drivers that support a certain display system.
- * The display system may be specified by EGL_DISPLAY.
- *
- * FIXME This makes libEGL a memory hog if an user driver is not specified and
- * there are many display drivers.
+ * Preload display drivers found in a particular directory.
*/
-static EGLBoolean
-_eglPreloadDisplayDrivers(void)
+static void
+_eglPreloadDisplayDriversFromDir(const char *prefix, const char *suffix, const char *dir)
{
-#if defined(_EGL_PLATFORM_POSIX)
- const char *dpy, *suffix;
- char path[1024], prefix[32];
+ char path[1024];
DIR *dirp;
struct dirent *dirent;
- dpy = getenv(EGL_DISPLAY);
- if (!dpy || !dpy[0])
- dpy = _EGL_DEFAULT_DISPLAY;
- if (!dpy || !dpy[0])
- return EGL_FALSE;
-
- snprintf(prefix, sizeof(prefix), egl_%s_, dpy);
- suffix = library_suffix();
-
- dirp = opendir(_EGL_DRIVER_SEARCH_DIR);
+ dirp = opendir(dir);
if (!dirp)
- return EGL_FALSE;
+ return;
while ((dirent = readdir(dirp))) {
_EGLDriver *drv;
- const char *p;
/* match the prefix */
if (strncmp(dirent-d_name, prefix, strlen(prefix)) != 0)
continue;
/* match the suffix */
- p = strrchr(dirent-d_name, '.');
- if ((p !suffix) || (!p suffix))
- continue;
- else if (p suffix strcmp(p + 1, suffix) != 0)
- continue;
+ if (suffix) {
+ size_t d_name_len = strlen(dirent-d_name);
+ size_t
Re: [Mesa3d-dev] [PATCH] switch shaders assembly TGSI code by tgsi_ureg
On Monday 01 February 2010 21:28:53 Igor Oliveira wrote: Hi again, Third version: removing debug messages Nicely done, I just committed the patches. Thanks! (a small nitpick, in future try to be a bit more descriptive in your commit log :) ). z -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] SSE optimized software rasterizer renders fog incorrectly
I bisected the rendering problem to commit adding xmm0 zeroing code to transform functions. 4c31632817a0bde28ad6c9ee8032d838ce4b7bfb is first bad commit commit 4c31632817a0bde28ad6c9ee8032d838ce4b7bfb Author: Arthur HUILLET arthur.huil...@free.fr Date: Tue Jun 30 12:46:27 2009 +0200 mesa: fix transform_points_3d_no_rot using undefined values in %xmm0 Signed-off-by: Arthur HUILLET arthur.huil...@free.fr I don't have good enough image of what is going as whole but my guess is that xmm0 is not undefined but it is defined to be fog factor. Reverting the commit fixed prgos/tests/fog rendering with sse swrast for me. I didn't run regression test to see if it causes some others bugs. But if xmm0 is undefined sometimes in transform functions the fix should be done earlier in path where fog information is coming in. I proposal reverting the commit to fix the fog/EXT_fogcoord in sse swrast, But Someone with good image of how the code functions should check it. PS. https://bugs.freedesktop.org/show_bug.cgi?id=23494 -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
