On 06/14/2011 03:28 PM, Chad Versace wrote:
[snip]
@@ -355,26 +355,48 @@ static void emit_depthbuffer(struct brw_context *brw)
ADVANCE_BATCH();
}
- /* Emit hiz buffer. */
if (hiz_region || stencil_irb) {
- BEGIN_BATCH(3);
- OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER<< 1
On 06/14/2011 12:32 PM, Ian Romanick wrote:
From: Ian Romanick
Previously it was up to the driver or later code generator to reject
these shaders. It turns out that nobody did this.
This will need changes to support geometry shaders.
NOTE: This is a candidate for the stable branches.
Bugzill
Today I attempted to run some closed source GLSL 1.30 texturing tests
we have lying around. I spent the rest of the day fixing unsigned
integer support in our compiler. Never did get the tests running.
There are more bugs. But this squashes quite a few of them. :)
_
From: Bryan Cain
These are necessary to handle int/uint constructor conversions. For
example, the following code currently results in a type mismatch:
int x = 7;
uint y = uint(x);
In particular, uint(x) still has type int.
This commit simply adds the new operations; it does not generate them,
Reverts commit f41e1db3273a31285360241c4342f0a403ee0b03
"fix conversions from uint to bool and from float/bool to uint"
f2i, b2i, and b2i should not accept uint types. Use i2u and u2i.
---
src/glsl/ir_validate.cpp |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/
Mesa IR actually stores all numbers as floating point, so this is
totally a farce, but we may as well keep it going.
Signed-off-by: Kenneth Graunke
---
src/mesa/program/ir_to_mesa.cpp |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/sr
No MOV is necessary since signed/unsigned integers share the same
bit-representation; it's simply a question of interpretation. In
particular, the fs_reg::imm union shouldn't need updating.
Signed-off-by: Kenneth Graunke
---
.../dri/i965/brw_fs_channel_expressions.cpp|2 ++
src/mesa
Inspired by a patch from Bryan Cain .
Fixes piglit tests:
- ctor-int-uint.vert
- ctor-ivec4-uvec4.vert
- ctor-uint-int.vert
- ctor-uvec4-ivec4.vert
Signed-off-by: Kenneth Graunke
---
src/glsl/ast_function.cpp | 35 +--
1 files changed, 29 insertions(+), 6 delet
Previously, ir_function::matching_signature had a fatal bug: if a
function had more than one non-exact match, it would simply return NULL.
This occured, for example, when looking for max(uvec3, uvec3):
- max(vec3, vec3) -> score 1 (found first)
- max(ivec3, ivec3) -> score 1 (found second...used
Previously, it would simply say "type error" in three different cases:
- The LHS is not an integer
- The RHS is not an integer
- The LHS and RHS have different types (int vs. uint)
Now the error messages state the specific problem.
Signed-off-by: Kenneth Graunke
---
src/glsl/ast_to_hir.cpp |
f2i results in an int/ivec; we need i2u to get a uint/uvec.
Signed-off-by: Kenneth Graunke
---
src/glsl/lower_instructions.cpp |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp
index a5f61f2..94b8c4a
MOD_TO_FRACT was designed to lower the GLSL 1.20 mod() function, which
operates on floating point values. However, we also use ir_binop_mod
for GLSL 1.30's % operator, which operates on integers.
For now, make MOD_TO_FRACT only apply to floating-point mod operations.
In the future, we may want to
https://bugs.freedesktop.org/show_bug.cgi?id=38301
jukari...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
I'd really like to land this for 7.11---apparently Wine applications
really want GL_ARB_shader_texture_lod in place for SM3 shaders.
The extension adds two parts: textureLod in the fragment shader, and
textureGrad in both targets. Lod works fine. Grad...is tricky.
Much more testing is required.
Prior to this patch, it would attempt to optimize and allocate registers
for the program even if it failed to compile. This seems wasteful.
More importantly, the "message length > 11" failure seems to choke the
instruction scheduler, making it somehow use an undefined value and
segmentation fault
This is somewhat ugly, but I couldn't think of a nicer way to handle the
interleaved coordinate/derivative parameter loading.
Ironlake and Sandybridge will still hit an assertion in visit().
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_defines.h |1 +
src/mesa/drive
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_emit.cpp|4 ++-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 37 +-
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
b/src/mesa/drivers
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_emit.cpp|1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 32 +-
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
b/src/mesa/drivers/d
This makes it available earlier, which will soon be necessary.
(Separating code motion from actual changes.)
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/
The next patch will add a few additional uses.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.h |2 ++
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 25 ++---
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/src/mesa/driver
Gen4-6 don't have a sample_d_c message, so we have to do a regular
sample_d and emit instructions to manually perform the comparison.
This requires a state dependent recompile whenever ctx->Depth.Func
changes. do_wm_prog looks for a compiled program in the cache based off
of brw_wm_prog_key, and
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36987
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel
Hello,
I've tried 2.6.39.1 and the gem_objects leak still exists.
I found the leak also on a i915 not only on a i965.
It only disappears if I set LIBGL_ALLWAYS_SOFTWARE (not really an opinion ;-).
Now I can try to update user space libraries, what lib would you suspect most?
libdrm 2.4.23
xorg
Hi!
I just pushed an initial commit of an X Acceleration state tracker to
the xa_branch.
The idea is that in the long run it will be replacing the Xorg state
tracker, which can then move back to a modular xf86-video-modesetting.
It will also be responsible for the acceleration part of an upd
On Wed, 2011-06-15 at 11:29 +0200, Thomas Hellstrom wrote:
> Hi!
>
> I just pushed an initial commit of an X Acceleration state tracker to
> the xa_branch.
>
> The idea is that in the long run it will be replacing the Xorg state
> tracker, which can then move back to a modular xf86-video-modese
On 06/15/2011 11:42 AM, Keith Whitwell wrote:
On Wed, 2011-06-15 at 11:29 +0200, Thomas Hellstrom wrote:
Hi!
I just pushed an initial commit of an X Acceleration state tracker to
the xa_branch.
The idea is that in the long run it will be replacing the Xorg state
tracker, which can then mov
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #8 from Tony Mechelynck 2011-06-15
05:40:10 PDT ---
(In reply to comment #4)
> > Questions:
>
> I don't know the answers to these questions. I'll check if the user who
> reported this is interested in further debugging this and I'll
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #9 from Benoit Jacob 2011-06-15 05:42:32 PDT
---
(In reply to comment #3)
> Questions:
>
> 1. In the 'if (!framebuffer)' case, is there a GL error?
>
> 2. If you initialize framebuffer to, say, 0xDEADBEEF before calling
> glGetInte
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #10 from Benoit Jacob 2011-06-15 05:59:49 PDT
---
(In reply to comment #6)
> I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html) could
> capture a trace for Mesa developers to replay...
I heard about it but how e
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #11 from Benoit Jacob 2011-06-15 06:02:58 PDT
---
How easy would it be for me to try swrast? I'm using Debian Testing, but with
the NVIDIA driver.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Y
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #12 from Brian Paul 2011-06-15 06:09:43
PDT ---
(In reply to comment #10)
> (In reply to comment #6)
> > I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html)
> > could
> > capture a trace for Mesa developers to re
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #13 from José Fonseca 2011-06-15 06:24:33 PDT
---
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #6)
> > > I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html)
> > > could
> > > cap
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #14 from Brian Paul 2011-06-15 06:29:08
PDT ---
Between the call to glBindFramebuffer() and
glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()? That
would change the context's framebuffer binding. We might have
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #15 from Benoit Jacob 2011-06-15 06:36:53 PDT
---
(In reply to comment #14)
> Between the call to glBindFramebuffer() and
> glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()?
As far as I can see, no, we don't ca
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #16 from Benoit Jacob 2011-06-15 06:43:14 PDT
---
Tony, if you have time, could you please try running firefox with apitrace as
explained in comment 13?
Note: you'll need to install cmake and you'll need to cd to the apitrace
direct
If --disable-gallium is passed, llvm-config isn't checked for, so mark
it explicitly as absent, through LLVM_CONFIG=no.
Passing --disable-gallium would result in:
| ../configure: line 9739: --version: command not found
| ../configure: line 9740: --cppflags: command not found
| ../configure: line 9
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #17 from Brian Paul 2011-06-15 07:02:31
PDT ---
(In reply to comment #15)
> (In reply to comment #14)
> > Between the call to glBindFramebuffer() and
> > glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()?
>
> As
On 06/14/2011 07:24 PM, Jeremy Huddleston wrote:
Ok, 1e16c34c5c86690b26739fbad82617768b1bd837 should fix the warnings for those
still using compilers based in the 1980's ;p
That worked. Thanks.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freed
On Wed, Jun 15, 2011 at 3:50 PM, Cyril Brulebois wrote:
> If --disable-gallium is passed, llvm-config isn't checked for, so mark
> it explicitly as absent, through LLVM_CONFIG=no.
>
> Passing --disable-gallium would result in:
> | ../configure: line 9739: --version: command not found
> | ../config
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #18 from Tony Mechelynck 2011-06-15
08:08:45 PDT ---
Created an attachment (id=48001)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48001)
firefox.bin.trace
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?ta
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #19 from Tony Mechelynck 2011-06-15
08:10:04 PDT ---
Created an attachment (id=48002)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48002)
firefox-bin.1.trace
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #20 from Tony Mechelynck 2011-06-15
08:11:48 PDT ---
Created an attachment (id=48003)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48003)
minefield.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=em
On Wed, 15 Jun 2011 01:24:53 -0700, Kenneth Graunke
wrote:
> The next patch will add a few additional uses.
This isn't just shadow, but also EXT_texture_swizzle. I'd just drop
"shadow" from the name.
pgpmuPSRue6i2.pgp
Description: PGP signature
___
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #21 from José Fonseca 2011-06-15 08:19:16 PDT
---
It looks like firefox is trying to destroy the currently bound context:
$ tracedump firefox-bin.1.trace | grep ctx
17 glXMakeCurrent(dpy = 0x62ea00, drawable = 125830043, ctx = 0x29
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #22 from Tony Mechelynck 2011-06-15
08:21:35 PDT ---
(In reply to comment #16)
> Tony, if you have time, could you please try running firefox with apitrace as
> explained in comment 13?
>
> Note: you'll need to install cmake and you
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #23 from Benoit Jacob 2011-06-15 08:27:16 PDT
---
(In reply to comment #21)
> According to glXDestroyContext's documentation, the context destruction should
> be deferred until it's no longer current to any thread.
Oh, I didn't know
On Wed, 15 Jun 2011 01:24:54 -0700, Kenneth Graunke
wrote:
> Gen4-6 don't have a sample_d_c message, so we have to do a regular
> sample_d and emit instructions to manually perform the comparison.
>
> This requires a state dependent recompile whenever ctx->Depth.Func
> changes. do_wm_prog looks
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #24 from José Fonseca 2011-06-15 08:43:18 PDT
---
(In reply to comment #23)
> (In reply to comment #21)
> > According to glXDestroyContext's documentation, the context destruction
> > should
> > be deferred until it's no longer curr
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #25 from Benoit Jacob 2011-06-15 08:49:01 PDT
---
New tryserver build: http://tbpl.mozilla.org/?tree=Try&rev=2a3c576f5adf
When the builds are done they will be available at:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #26 from Benoit Jacob 2011-06-15 08:52:59 PDT
---
(In reply to comment #24)
> Sorry, I was ambiguous. It's the GL driver's responsibility to defer the
> destruction internally. See:
>
> http://www.opengl.org/sdk/docs/man/xhtml/glX
This patch set adds support for switch statements to the GLSL compiler. We
modify the grammar for the compiler with productions for switch statements
and case labels, while adding supporting supporting productions not already
present. New AST classes are defined to support those productions. Howev
The grammar is modified to support switch statements. Rather than follow the
grammar in the appendix, which allows case labels to be placed ANYWHERE
as a regular statement, we follow the development of the grammar as
described in the body of the GLSL.
In this variation, the switch statement has a
Data structures for switch statement and case label are created that parallel
the structure of other AST data.
---
src/glsl/ast.h | 27 +++
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 878f48b..48d1795 100644
--- a/
Previously we added productions for:
switch_body
case_label_list
case_statement
case_statement_list
Now add AST structs corresponding to those productions.
---
src/glsl/ast.h | 49 +
1 files changed, 49 insertions(+)
We now tie the grammar to the ctors of the ASTs they reference.
This requires that we actually have definitions of the ctors.
In addition, we also need to define "print" and "hir" methods for the AST
classes. At this stage of the development, we simply stub out the "print"
and "hir" methods and f
Pretty trivial stuff. Simply print the structure of the ASTs. No magic here.
---
src/glsl/glsl_parser_extras.cpp | 38 --
1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index a3
A loop is generated for the wrapper of the switch statement. We need to force
the exit of that loop after all cases are processed. Therefore, generate
an implicit break at the very end of the loop.
---
src/glsl/ast_to_hir.cpp |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff
Beware! Here be dragons!
Up until now modyfing the GLSL compiler has been pretty straightforward.
This is where things get interesting.
Switch statement processing leverages infrastructure that was previously
created (specifically for break statements, which are encountered in both
loops and swit
On 06/15/2011 08:27 AM, Eric Anholt wrote:
On Wed, 15 Jun 2011 01:24:54 -0700, Kenneth Graunke
wrote:
Gen4-6 don't have a sample_d_c message, so we have to do a regular
sample_d and emit instructions to manually perform the comparison.
This requires a state dependent recompile whenever ctx->D
On first compile...
- brw_prepare_wm_prog populates the key with depth_compare_func = 0
and searches the cache. No hit.
- It then sets depth_compare_func and searches the cache again. No hit.
(This is an additional cost.)
- It resets depth_compare_func to 0 and compiles.
- During compilation,
Does line anti aliasing work for r600 and r700 processors? It does not seem to
change anything visually when I set PA_SC_AA_MASK.u32All,
PA_SC_AA_SAMPLE_LOCS_MCTX.u32All, PA_SC_AA_SAMPLE_LOCS_8S_WD1_MCTX.u32All and
PA_SC_AA_CONFIG.u32All to what would seem to be reasonable values in
r700InitSt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/15/2011 11:00 AM, Kenneth Graunke wrote:
> On 06/15/2011 08:27 AM, Eric Anholt wrote:
>> On Wed, 15 Jun 2011 01:24:54 -0700, Kenneth
>> Graunke wrote:
>>> Gen4-6 don't have a sample_d_c message, so we have to do a regular
>>> sample_d and emit i
On Wed, Jun 15, 2011 at 2:14 PM, Jeffrey Collins wrote:
> Does line anti aliasing work for r600 and r700 processors? It does not seem
> to change anything visually when I
> set PA_SC_AA_MASK.u32All, PA_SC_AA_SAMPLE_LOCS_MCTX.u32All, PA_SC_AA_SAMPLE_LOCS_8S_WD1_MCTX.u32All
> and PA_SC_AA_CONFIG.u32
On 06/15/2011 09:33 AM, Dan McCabe wrote:
Data structures for switch statement and case label are created that parallel
the structure of other AST data.
---
src/glsl/ast.h | 27 +++
1 files changed, 23 insertions(+), 4 deletions(-)
Dan, thanks for sending this out!
On Wed, 15 Jun 2011 11:03:34 -0700, Kenneth Graunke
wrote:
> On first compile...
> - brw_prepare_wm_prog populates the key with depth_compare_func = 0
> and searches the cache. No hit.
> - It then sets depth_compare_func and searches the cache again. No hit.
> (This is an additional cost.)
s_readpix.c looks bogus in the depth fastpaths, where it's changing
GetRow results based on rb->Format instead of only looking at
rb->DataType vs type. I came up with these tests trying to hit those,
but they're passing for me. Have I missed something obvious?
___
We have a few tests that read depth, but they all read GL_FLOAT, so
they don't cover the fast paths in swrast.
---
tests/all.tests |1 +
tests/fbo/CMakeLists.gl.txt |1 +
tests/fbo/fbo-readpixels-depth-formats.c | 279 ++
3
The existing glean test only covers window system framebuffers, not an
actual packed depth/stencil FBO like this.
---
tests/all.tests|1 +
tests/spec/CMakeLists.txt |1 +
.../ext_packed_depth_stencil/CMakeLists.gl.txt | 17
https://bugs.freedesktop.org/show_bug.cgi?id=38312
Tony Mechelynck changed:
What|Removed |Added
Attachment #48001|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #28 from Benoit Jacob 2011-06-15 14:12:39 PDT
---
(In reply to comment #27)
> Created an attachment (id=48014)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48014)
> minefield.log.bz2 (no crash at the end)
Thanks a lot!
The
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #29 from Benoit Jacob 2011-06-15 14:13:32 PDT
---
Also the log shows that glXMakeCurrent is not called between the two points in
question.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are r
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #30 from Benoit Jacob 2011-06-15 14:14:21 PDT
---
Note that with the NVIDIA driver, nonzero FB bindings are correctly reported by
this build.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You ar
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #31 from Brian Paul 2011-06-15 14:25:18
PDT ---
(In reply to comment #28)
> (In reply to comment #27)
> > Created an attachment (id=48014)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48014)
> > minefield.log.bz2 (no crash at
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #32 from Benoit Jacob 2011-06-15 14:28:44 PDT
---
(In reply to comment #31)
> I just hacked a piglit fbo test to query GL_FRAMEBUFFER_BINDING after
> glBindFramebuffer() and assert that the value returned matches the bind call.
> It
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #33 from Benoit Jacob 2011-06-15 14:31:23 PDT
---
Anyway, since the crash is fixed, we don't have anymore a reason to blacklist.
Firefox just recognizes at runtime when the bug occurs and fails the WebGL
context creation.
--
Config
My work on the GLSL IR to TGSI translator I announced on the list this
April is now at the point where I think it is ready to be merged into
Mesa. It is stable and doesn't regress any piglit tests on softpipe or
nv50.
It adds native integer support as required by GLSL 1.30, although it is
current
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #34 from Tony Mechelynck 2011-06-15
14:46:19 PDT ---
(In reply to comment #32)
> (In reply to comment #31)
> > I just hacked a piglit fbo test to query GL_FRAMEBUFFER_BINDING after
> > glBindFramebuffer() and assert that the value re
Bryan,
Thanks for your work on this! I'm glad to see GLSL IR->TGSI happening.
A few quick comments on "mesa,st/mesa: add native support for integers
in shaders"...
glsl_type::get_vec4_type(base) is equivalent to
glsl_type::get_instance(base, 4, 1) except that it returns error_type
instead
On Thu, Jun 16, 2011 at 7:38 AM, Bryan Cain wrote:
> My work on the GLSL IR to TGSI translator I announced on the list this
> April is now at the point where I think it is ready to be merged into
> Mesa. It is stable and doesn't regress any piglit tests on softpipe or
> nv50.
For anyone not gith
On Tue, Jun 14, 2011 at 10:35 PM, Benjamin Franzke
wrote:
> Removing this flag seems right to me, but always building the egl
> state tracker when gallium and egl is enabled not.
> So when --with-state-trackers is also removed, we'd need a new
> --with-egl-drivers=auto|gallium,dri2,glx or so.
Isn
The current dri context unbind logic will leak drawables until the process
dies (they will then get released by the GEM code). There are two ways to fix
this: either always call driReleaseDrawables every time we unbind a context
(but that costs us round trips to the X server at getbuffers() time) o
On 06/15/2011 04:59 PM, Kenneth Graunke wrote:
> Bryan,
>
> Thanks for your work on this! I'm glad to see GLSL IR->TGSI happening.
>
> A few quick comments on "mesa,st/mesa: add native support for integers
> in shaders"...
>
> glsl_type::get_vec4_type(base) is equivalent to
> glsl_type::get_instan
Replace instances of
irb->region = region
with
intel_region_reference(&irb->region, region)
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.c | 49 ++-
1 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri
A valid criticism. It hadn't occured to me at the time, but you are right.
The problem I was trying to sovle was gitting visibility to the test
expression IR and the fall through state IR during case label processing.
Another solution is to to add those IR pointers to struct
_mesa_glsl_parse_stat
On Wed, 15 Jun 2011 15:54:13 -0700, Chad Versace wrote:
> Replace instances of
> irb->region = region
> with
> intel_region_reference(&irb->region, region)
The comment is slightly misleading, as you are performing a replacement
of
irb->region = intel_region_alloc();
with
struct intel_
On Thu, Jun 16, 2011 at 7:04 AM, Marek Olšák wrote:
> On Tue, Jun 14, 2011 at 10:35 PM, Benjamin Franzke
> wrote:
>> Removing this flag seems right to me, but always building the egl
>> state tracker when gallium and egl is enabled not.
>> So when --with-state-trackers is also removed, we'd need
Previously, the builtins in OES_texture_3D.{frag,vert} were only
compiling properly as a consequence of bug 38015, which allows
unsupported extensions to be enabled. This fix eliminates the builtin
compiler's reliance on bug 38015, so that bug 38015 can be fixed.
---
src/glsl/main.cpp |1 +
1
For some extensions, _mesa_glsl_process_extension() only checked
whether the extension was supported *after* enabling it. Modified the
logic to always check first, and only enable supported extensions.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38015 and piglit
test glsl-link-bug38015.
--
Only patch 1 affects core mesa; the remaining patches are in the intel shared
driver.
Patch 6 is just a clean-up leading to patch 7.
Chad Versace (7):
mesa: Add field gl_renderbuffer.Unwrapped
intel: Unconditionally enable support for S8_Z24 texture format
intel: Support renderbuffer unwra
If a renderbuffer wraps multiple renderbuffers, then Unwrapped points to
the them.
For example, if hardware requires separate depth and stencil buffers
(X8_Z24 and S8), then glRenderbufferStorage(GL_DEPTH24_STENCIL8) may
create a fake S8_Z24 renderbuffer for which Unwrapped[BUFFER_DEPTH] and
Unwra
Commit b5c847c7ca06823af3b72324056a2e478caca70b erroneously disabled
support for S8_Z24 texture format when the context required separate
stencil (intel_context.must_use_separate_stencil).
But the GL spec requires implementations to support GL_DEPTH24_STENCIL8.
So we better find a way to fake it..
Now, if the renderbuffer contains an unwrapper for the requested
attachment, intel_get_renderbuffer returns the unwrapper.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.h | 21 +
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/mesa
If Attachment[X] was a wrapper (s8_z24) around separate depth (x8_z24) and
stencil (s8) buffers, then intel_renderbuffer_map was passed the wrapper
instead of the real renderbuffer. This was no good; the wrapper has no
intel_region.
Using intel_get_renderbuffer() ensures that we map the real rende
Replace instances of
irb->region = region
with
intel_region_reference(&irb->region, region)
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.c | 49 ++-
1 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri
Hiz buffer allocation can only occur if the 'else' branch has been taken,
so move the hiz buffer allocation into the 'else' branch.
Having the hiz buffer allocation dangling outside of the if-tree was just
damn confusing.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.c |
This adds support only for *pure* renderbuffers. Support for texture
renderbuffers is added in a subsequent patch.
Fixes the following Piglit tests from abort to pass on gen5 when
intel_screen.hw_must_use_separate_stencil and .hw_has_hiz are manually
enabled.
hiz-depth-read-fbo-d24s8
hiz-
(Some comments from Chris Wilson revealed that patch 5/7 of this series' first
submission was incorrect. That patch has been removed.)
Only patch 1 affects core mesa; the remaining patches are in the intel shared
driver.
Patch 5 is just a clean-up leading to patch 6.
Chad Versace (6):
mesa: A
If a renderbuffer wraps multiple renderbuffers, then Unwrapped points to
the them.
For example, if hardware requires separate depth and stencil buffers
(X8_Z24 and S8), then glRenderbufferStorage(GL_DEPTH24_STENCIL8) may
create a fake S8_Z24 renderbuffer for which Unwrapped[BUFFER_DEPTH] and
Unwra
Commit b5c847c7ca06823af3b72324056a2e478caca70b erroneously disabled
support for S8_Z24 texture format when the context required separate
stencil (intel_context.must_use_separate_stencil).
But the GL spec requires implementations to support GL_DEPTH24_STENCIL8.
So we better find a way to fake it..
Now, if the renderbuffer contains an unwrapper for the requested
attachment, intel_get_renderbuffer returns the unwrapper.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.h | 21 +
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/mesa
1 - 100 of 116 matches
Mail list logo
