These simply don't exist in the 1.30 specification---none of the Offset
variants allow samplerCube. This must have been a cut and paste error
from textureGrad, which /does/ allow cubemaps.
Signed-off-by: Kenneth Graunke
---
src/glsl/builtins/profiles/130.frag |4
src/glsl/built
Due to a cut and paste error, these were accidentally misnamed
textureProj() rather than textureProjOffset().
Signed-off-by: Kenneth Graunke
---
src/glsl/builtins/profiles/130.frag | 84 +-
src/glsl/builtins/profiles/130.vert | 40
2 files cha
On 11/09/2011 08:36 AM, Paul Berry wrote:
I can't help but notice that in the above section, the comment says
"textureProjOffset", but the function declarations say "textureProj".
Is this a bug? The GLSL spec clearly calls these functions
"textureProjOffset". 130.frag seems to have a similar pr
NEW_COLOR is only needed on Gen4-5 as brw_update_renderbuffer_surfaces
only uses ctx->Color when intel->gen < 6.
This should reduce unnecessary state updates.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_state.h|1 +
src/mesa/drivers/dri/i965/brw_state_upload
On 11/09/2011 02:20 PM, Ian Romanick wrote:
You mean, drop the 'var->location < FRAG_RESULT_DATA0' from the
if-statement below? That is probably true. It was a copy-and-paste from
GetAttributeLocation. The check *is* necessary there because there is no
'strncmp("gl_", name)' in that function. Get
On original gen4, the surface format didn't determine the return data
type from sampling like it does on g45 and later.
Fixes GL_EXT_texture_integer/texture_integer_glsl130
---
The dst type in your patch has already been smashed to UW for 16-wide,
so it didn't end up working.
src/mesa/drivers/d
On 11/08/2011 08:16 PM, Kenneth Graunke wrote:
On 11/08/2011 08:10 PM, Kenneth Graunke wrote:
On 11/04/2011 04:41 PM, Ian Romanick wrote:
From: Ian Romanick
Fixes piglit's getfragdatalocation test.
Signed-off-by: Ian Romanick
---
src/mesa/main/shader_query.cpp | 56 +++
On 11/09/2011 10:34 AM, Eric Anholt wrote:
On Tue, 8 Nov 2011 14:32:08 -0800, Kenneth Graunke
wrote:
Although the hardware supports separate binding tables for each pipeline
stage, we don't see much advantage over a single shared table.
Consider the contents of the binding table:
- Textures
On Tue, 08 Nov 2011 19:21:59 -0800, Kenneth Graunke
wrote:
> On 11/04/2011 03:01 PM, Eric Anholt wrote:
> > Before, I was tracking the ir_variable * found for gl_FragColor or
> > gl_FragData[]. Instead, when visiting those variables, set up an
> > array of per-render-target fs_regs to copy the o
On Tue, 08 Nov 2011 19:54:57 -0800, Kenneth Graunke
wrote:
> On 11/04/2011 03:01 PM, Eric Anholt wrote:
> > Here's a patch series to get GL_EXT_texture_integer partially working
> > on i965, hidden under the GL 3.0 override. There's a bunch of support
> > I think isn't finished yet, mostly becau
On Tue, 08 Nov 2011 19:46:13 -0800, Kenneth Graunke
wrote:
> On 11/04/2011 03:01 PM, Eric Anholt wrote:
> > This requires using a new fragment shader to get the integer color
> > output, and a new vertex shader because #version has to match between
> > the two.
>
> Hm. The extra VS is rather un
With the gl_VertexID support, everything required should now be
supported.
---
src/mesa/drivers/dri/intel/intel_extensions.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
i
We only allow 16 vec4s of attributes in our GLSL/ARB_vp programs, and
1 more element will get used for gl_VertexID/gl_InstanceID. So it
should never have been possible to hit this fallback, unless there was
another bug. If you do hit this, you're probably using gl_VertexID
and falling back to swr
---
src/glsl/builtin_variables.cpp |2 +-
src/mesa/main/mtypes.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 0d804c2..ed6b922 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/bu
The compiler setup for these VF-uploaded attributes looks a little
cheesy with mixing system values and real VBO-sourced attributes. It
would be nice if we could just compute the ATTR[] map to GRF index up
front and use it at visit time instead of using ir->location in the
ATTR file. However, we
This used to be script-generated, but now it's just a bunch of static
variables in a .h file for no good reason.
---
src/glsl/builtin_variables.cpp | 87 +++-
src/glsl/builtin_variables.h | 110
2 files changed, 86 insertion
On 31 October 2011 11:59, Ian Romanick wrote:
> On 10/28/2011 02:59 PM, Eric Anholt wrote:
>
>> On Fri, 28 Oct 2011 10:42:44 -0700, "Ian Romanick"
>> wrote:
>>
>>> From: Ian Romanick
>>> >
>>>
>>> _mesa_ir_link_shader needs to be called before cloning the IR tree so
>>> that the var->location fi
Another thing to notice that nested functions require executable stack.
This is also another reason to get rid of them.
On Wed, Nov 9, 2011 at 3:11 PM, İsmail Dönmez wrote:
> Hi;
>
> nouveau_array.c seems to be using nested functions which is not supported
> by clang (or the EDG based compilers
On Wed, 9 Nov 2011 08:36:52 -0800, Paul Berry wrote:
Non-text part: multipart/mixed
Non-text part: multipart/alternative
> On 8 November 2011 10:40, Kenneth Graunke wrote:
>
> > From the GLSL 1.30 spec, section 8.7 "Texture Lookup Functions":
> > "In all functions below, the bias parameter is op
On Wed, 9 Nov 2011 01:20:33 -0800, Kenneth Graunke
wrote:
> Although textureSize is represented as an ir_texture with op == ir_txs,
> it doesn't have a coordinate, so normalizing it doesn't make sense.
>
> Fixes crashes in oglconform glsl-bif-tex-size basic.samplerCube.* tests.
>
> Signed-off-
On Tue, 08 Nov 2011 12:28:20 -0800, Kenneth Graunke
wrote:
> On 11/04/2011 03:01 PM, Eric Anholt wrote:
> > Texture filtering is not supported on floating-point textures until
> > gen5, which showed up as failures in texwrap in particular.
> > ---
> > src/mesa/drivers/dri/intel/intel_extensions
On Tue, 08 Nov 2011 23:16:21 -0800, Kenneth Graunke
wrote:
> Ian,
>
> I just tried running Cogs (from the Humble Indie Bundle 3) and
> discovered a terrible regression: it continually keeps recompiling
> fragment shader 19 over and over again.
>
> It looks like it was caused by commit 7199096
On Tue, 8 Nov 2011 14:31:59 -0800, Kenneth Graunke
wrote:
> Patches 1 and 2 are simple bug fixes.
>
> Patches 3-10 significantly rework our binding table setup. They disable
> prefetching of SURFACE_STATE entries, use a single binding table for all
> pipeline stages, and most importantly, pave
On Tue, 8 Nov 2011 14:32:06 -0800, Kenneth Graunke
wrote:
> These were only split for historical reasons: brw_wm_constants used to
> be the "prepare" step, while brw_wm_constant_surface was "emit". Now
> that both happen at emit time, it makes sense to combine them.
>
> Call the newly combined
On Tue, 8 Nov 2011 14:32:08 -0800, Kenneth Graunke
wrote:
> Although the hardware supports separate binding tables for each pipeline
> stage, we don't see much advantage over a single shared table.
>
> Consider the contents of the binding table:
> - Textures (16)
> - Draw buffers (8)
> - Pull c
On Tue, 8 Nov 2011 14:32:09 -0800, Kenneth Graunke
wrote:
> Like for the WM pull constants, we can merge the former prepare/emit
> stages into one tracked state atom. Furthermore, the code that used to
> handle the binding table was removed in the last commit, leaving some
> rather silly lookin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/2011 01:04 AM, Kenneth Graunke wrote:
> Constant expressions which called GLSL's equal() and notEqual()
> built-ins on bvecs would hit an assertion failure; we simply forgot to
> implement them for booleans.
>
> NOTE: This is a candidate for
On 8 November 2011 14:32, Kenneth Graunke wrote:
> These were only split for historical reasons: brw_wm_constants used to
> be the "prepare" step, while brw_wm_constant_surface was "emit". Now
> that both happen at emit time, it makes sense to combine them.
>
> Call the newly combined state atom
On 8 November 2011 10:40, Kenneth Graunke wrote:
> From the GLSL 1.30 spec, section 8.7 "Texture Lookup Functions":
> "In all functions below, the bias parameter is optional for fragment
> shaders. The bias parameter is not accepted in a vertex shader."
>
> This was a cut and paste mistake.
>
>
On Wed, Nov 9, 2011 at 2:16 AM, Kenneth Graunke wrote:
> Ian,
>
> I just tried running Cogs (from the Humble Indie Bundle 3) and discovered a
> terrible regression: it continually keeps recompiling fragment shader 19
> over and over again.
>
> It looks like it was caused by commit 71990969 ("mesa:
Hi;
nouveau_array.c seems to be using nested functions which is not supported
by clang (or the EDG based compilers it seems), the reduced testcase looks
like this:
foo()
{
auto void f();
void f() {};
}
I talked to the clang developers and they don't plan to support this GNU
extension sin
https://bugs.freedesktop.org/show_bug.cgi?id=42516
--- Comment #2 from Christian Holler (:decoder)
2011-11-09 03:16:32 PST ---
Created attachment 53320
--> https://bugs.freedesktop.org/attachment.cgi?id=53320
Archive containing API trace files
Attached is a .tgz containing firefox.trace and f
Although textureSize is represented as an ir_texture with op == ir_txs,
it doesn't have a coordinate, so normalizing it doesn't make sense.
Fixes crashes in oglconform glsl-bif-tex-size basic.samplerCube.* tests.
Signed-off-by: Kenneth Graunke
---
.../drivers/dri/i965/brw_cubemap_normalize.cpp
On Thu, Nov 03, 2011 at 10:16:06AM +0800, Yuanhan Liu wrote:
> On Wed, Nov 02, 2011 at 02:18:46PM -0700, Eric Anholt wrote:
> > On Wed, 2 Nov 2011 11:12:07 +0800, Yuanhan Liu
> > wrote:
> > > On Tue, Nov 01, 2011 at 05:57:36PM +0800, Yuanhan Liu wrote:
> > > > According to bspec, MIPCnt(was set t
The original comments just tell me that I'm doing wrong. Here I sent a
patch for comments and explanation, and I may then try to write the code
to process those built-in uniform variables.
My questions is why we can't handle those built-in uniform variables
like normal uniform variables? What kin
Don't call set_unfiform_initializers if link failed, or it would trigger
a GL_INVALID_OPERATION error. That's not an expected behavior of
glLinkProgram function.
Signed-off-by: Yuanhan Liu
---
src/mesa/program/ir_to_mesa.cpp |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --g
Constant expressions which called GLSL's equal() and notEqual()
built-ins on bvecs would hit an assertion failure; we simply forgot to
implement them for booleans.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke
---
src/glsl/ir_constant_expression.cpp |
37 matches
Mail list logo
