On Thu, Jun 16, 2011 at 3:22 PM, Dave Airlie wrote:
> 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 an
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.
I just pulled it in
On Thu, Jun 16, 2011 at 10:20 AM, Marek Olšák wrote:
> On Thu, Jun 16, 2011 at 1:21 AM, Chia-I Wu wrote:
>> 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 eg
https://bugs.freedesktop.org/show_bug.cgi?id=37476
--- Comment #5 from Mike Kaplinskiy 2011-06-15
20:12:39 PDT ---
Hey Dave,
Seems to work fine here on barts. That "slight hack to make gradients always go
into same cf" is what my patch was missing :(.
My patch had some error checks for the cas
OK, I take the scons patches back. I thought scons was only good for
building llvmpipe and svga on Windows.
scons --help is not very helpful, it doesn't describe how to build
drivers. Is there a way to exactly reproduce the following configure
options in scons?
--prefix=/usr --enable-glx-tls --en
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 o
On Wed, 15 Jun 2011 10:53:13 +0200, Lampersperger Andreas
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
problem in the new driver, and s
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,
Fir
FramebufferTextureLayer is an alias of FramebufferTextureLayerEXT, so
FramebufferTextureLayerARB needs to be listed as an alias of
FramebufferTextureLayerEXT rather than FramebufferTextureLayer.
Signed-off-by: Jeremy Huddleston
---
src/mapi/glapi/gen/ARB_geometry_shader4.xml |2 +-
1 files
On 06/15/2011 05:34 PM, Chad Versace wrote:
> 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 f
On 06/15/2011 03:54 PM, Chad Versace wrote:
On Thu, 16 Jun 2011 00:06:11 +0100, Chris Wilson
wrote:
> I'm curious, what's the advantage? i.e. what am I not understanding that
> needs to be explained in the changelog?
> -Chris
Oops, I was wrong. NAK this patch.
I thought these regions were neve
On Thu, Jun 16, 2011 at 1:21 AM, Chia-I Wu wrote:
> 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.
>>>
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)
>
> Signed-off-by: Chad Versace
intel_region_alloc returns something with a refcount of 1 -- the
reference you got from the return
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-
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 |
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
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
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..
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
(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
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-
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 |
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
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
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
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..
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
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
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.
--
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
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
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_
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
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
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
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 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
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
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
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
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 #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
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 #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 #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 #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 #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
Tony Mechelynck changed:
What|Removed |Added
Attachment #48001|0 |1
is obsolete|
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
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
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?
___
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.)
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, 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
-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
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
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,
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
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
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
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
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
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(+)
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/
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
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
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
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 #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
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 #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
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 #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
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 #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
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 #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
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
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
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
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 #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
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 #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 #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 #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 #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 #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 #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 #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
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
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
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
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
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
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
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
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/
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
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
1 - 100 of 116 matches
Mail list logo
