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 |
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
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
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
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
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
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
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:
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 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
-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 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
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: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: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, 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, 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 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 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
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 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
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
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
---
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
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
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
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
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: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 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 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 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/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
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 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
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
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
37 matches
Mail list logo
