https://bugs.freedesktop.org/show_bug.cgi?id=38312
Karl Tomlinson bugs.freedesk...@karlt.net changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=37476
--- Comment #4 from Dave Airlie airl...@freedesktop.org 2011-06-14 23:58:39
PDT ---
Hi Mike,
you might have noticed I pushed something that worked, then found this patch,
which I preferred to mine, so I fixed up the code with your authorship on
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
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. :)
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
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36987
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #18 from Tony Mechelynck antoine.mechely...@gmail.com 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/show_bug.cgi?id=38312
--- Comment #19 from Tony Mechelynck antoine.mechely...@gmail.com 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/show_bug.cgi?id=38312
--- Comment #20 from Tony Mechelynck antoine.mechely...@gmail.com 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/show_bug.cgi?id=38312
--- Comment #22 from Tony Mechelynck antoine.mechely...@gmail.com 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
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
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
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 flesh
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
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
On 06/15/2011 08:27 AM, Eric Anholt wrote:
On Wed, 15 Jun 2011 01:24:54 -0700, Kenneth Graunkekenn...@whitecape.org
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
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
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
-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
Graunkekenn...@whitecape.org wrote:
Gen4-6 don't have a sample_d_c message, so we have to do a regular
sample_d
On Wed, Jun 15, 2011 at 2:14 PM, Jeffrey Collins tilde...@hotmail.com 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
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!
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 ++
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
--- Comment #28 from Benoit Jacob bja...@mozilla.com 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)
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #30 from Benoit Jacob bja...@mozilla.com 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/show_bug.cgi?id=38312
--- Comment #31 from Brian Paul brian.e.p...@gmail.com 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)
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
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #34 from Tony Mechelynck antoine.mechely...@gmail.com 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
On Thu, Jun 16, 2011 at 7:38 AM, Bryan Cain bryanca...@gmail.com 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.
On Tue, Jun 14, 2011 at 10:35 PM, Benjamin Franzke
benjaminfran...@googlemail.com 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
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)
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_instance(base, 4,
Replace instances of
irb-region = region
with
intel_region_reference(irb-region, region)
Signed-off-by: Chad Versace c...@chad-versace.us
---
src/mesa/drivers/dri/intel/intel_fbo.c | 49 ++-
1 files changed, 28 insertions(+), 21 deletions(-)
diff --git
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
Now, if the renderbuffer contains an unwrapper for the requested
attachment, intel_get_renderbuffer returns the unwrapper.
Signed-off-by: Chad Versace c...@chad-versace.us
---
src/mesa/drivers/dri/intel/intel_fbo.h | 21 +
1 files changed, 17 insertions(+), 4 deletions(-)
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
Replace instances of
irb-region = region
with
intel_region_reference(irb-region, region)
Signed-off-by: Chad Versace c...@chad-versace.us
---
src/mesa/drivers/dri/intel/intel_fbo.c | 49 ++-
1 files changed, 28 insertions(+), 21 deletions(-)
diff --git
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
On Wed, 15 Jun 2011 15:54:13 -0700, Chad Versace c...@chad-versace.us wrote:
Replace instances of
irb-region = region
with
intel_region_reference(irb-region, region)
Signed-off-by: Chad Versace c...@chad-versace.us
intel_region_alloc returns something with a refcount of 1 -- the
On Thu, Jun 16, 2011 at 1:21 AM, Chia-I Wu olva...@gmail.com wrote:
On Thu, Jun 16, 2011 at 7:04 AM, Marek Olšák mar...@gmail.com wrote:
On Tue, Jun 14, 2011 at 10:35 PM, Benjamin Franzke
benjaminfran...@googlemail.com wrote:
Removing this flag seems right to me, but always building the egl
On Wed, Jun 15, 2011 at 04:38:07PM -0500, 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.
Hi,
First
On Wed, 15 Jun 2011 10:53:13 +0200, Lampersperger Andreas
lampersperger.andr...@heidenhain.de wrote:
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.
I recommend focusing your debugging efforts on i965. If we solve the
On Wed, Jun 15, 2011 at 01:53, Lampersperger Andreas
lampersperger.andr...@heidenhain.de wrote:
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
On Thu, Jun 16, 2011 at 10:20 AM, Marek Olšák mar...@gmail.com wrote:
On Thu, Jun 16, 2011 at 1:21 AM, Chia-I Wu olva...@gmail.com wrote:
On Thu, Jun 16, 2011 at 7:04 AM, Marek Olšák mar...@gmail.com wrote:
On Tue, Jun 14, 2011 at 10:35 PM, Benjamin Franzke
benjaminfran...@googlemail.com
47 matches
Mail list logo
