https://bugs.freedesktop.org/show_bug.cgi?id=30484
Jos van Wolput wol...@onsneteindhoven.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mit, 2011-12-07 at 23:43 -0600, David Fries wrote:
Package: libgl1-mesa-glx
Version: 7.11-6
Severity: normal
Tags: patch
When dri is used the character device /dev/dri/card0 is opened. That
file descriptor should be set with the close on exec file as currently
those resources are
Invalid shaders containing the character % at an unexpected location
would cause Bison to call yyerror with a message of:
syntax error, unexpected '%'
Bison expects yyerror() to take a string, while _mesa_glsl_error() is a
printf-style function. This hit the classic printf string escape
No point in having it when just having sampler_view_planes is good enough.
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
Changes since v2:
- fixed borked ureg_MOV, I have no idea how it worked when I tested this
on r600 to begin with, it renders correctly now with XvMC
Maarten Lankhorst wrote:
No point in having it when just having sampler_view_planes is good enough.
Signed-off-by: Maarten Lankhorstm.b.lankho...@gmail.com
---
Changes since v2:
- fixed borked ureg_MOV, I have no idea how it worked when I tested this
on r600 to begin with, it renders
https://bugs.freedesktop.org/show_bug.cgi?id=43629
Bug #: 43629
Summary: mesa# gmake freebsd-dri-amd64 breaks
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: FreeBSD
From: José Fonseca jfons...@vmware.com
It sets the wrong values (GL_XXX_LEFT instead of GL_XXX), and no other
Mesa driver does this, given that Mesa sets the right draw/read buffers
provided the Mesa visual has the doublebuffer flag filled correctly
which is the case.
---
https://bugs.freedesktop.org/show_bug.cgi?id=43629
--- Comment #2 from zap...@berentweb.com 2011-12-08 06:17:57 PST ---
dri2proto from ports (I assumed ports collection was up-to-date on
dri2proto since link is to 1.1.tar.gz on the wiki page:
Hey Andy,
On 12/08/2011 01:24 PM, Andy Furniss wrote:
Maarten Lankhorst wrote:
No point in having it when just having sampler_view_planes is good enough.
Signed-off-by: Maarten Lankhorstm.b.lankho...@gmail.com
---
Changes since v2:
- fixed borked ureg_MOV, I have no idea how it worked
On 12/08/2011 07:00 AM, jfons...@vmware.com wrote:
From: José Fonsecajfons...@vmware.com
It sets the wrong values (GL_XXX_LEFT instead of GL_XXX), and no other
Mesa driver does this, given that Mesa sets the right draw/read buffers
provided the Mesa visual has the doublebuffer flag filled
---
tests/all.tests|4 +
tests/spec/CMakeLists.txt |1 +
.../arb_uniform_buffer_object/CMakeLists.gl.txt| 17 ++
.../spec/arb_uniform_buffer_object/CMakeLists.txt |1 +
.../arb_uniform_buffer_object/standard-layout.c
---
tests/all.tests|1 +
.../arb_uniform_buffer_object/CMakeLists.gl.txt|1 +
tests/spec/arb_uniform_buffer_object/draw_test.c | 227
3 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644
Maarten Lankhorst wrote:
Softpipe is working, that's handy - last time I tried it was too borked to be
of use, but now I can actually see which errors are software and which are
added by R600.
My observation for softpipe working correctly only seems to apply for
XVMC_MOCOMP,
if I try with
Andy Furniss wrote:
There are minor errors - when I said Softpipe is working I was
comparing to the past when it would render mainly junk with a shrunken
portion of the vid and later when that went away, it would render with
blocks of frame -1 mixed with current frame.
Actually with vdpau
There has been quite a bit of skew between what's in Mesa and what's
needed in the xserver. This patch series cleans that up. Most of the
changes are quite mundane and just make the code compile inside the
xserver. However, the changes in patch 6/7 modify the way the
availability and use of
From: Ian Romanick ian.d.roman...@intel.com
glext.h doesn't have GL_MIN_PROGRAM_TEXEL_OFFSET_EXT or
GL_MAX_PROGRAM_TEXEL_OFFSET_EXT. Using them in the XML causes code to
be generated for the xserver that won't compile. Use the names that
exist instead.
Signed-off-by: Ian Romanick
From: Ian Romanick ian.d.roman...@intel.com
The versions in the xserver and in libGL have diverged enough that the
xserver doesn't want these.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/Makefile |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/Makefile |6 --
src/mapi/glapi/gen/glX_proto_recv.py |2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mapi/glapi/gen/Makefile
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/gl_table.py |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_table.py b/src/mapi/glapi/gen/gl_table.py
index f6182b6..7f3b915
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/gl_gentable.py | 38
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_gentable.py
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/glX_proto_recv.py | 15 ---
src/mapi/glapi/gen/glX_proto_send.py | 16
src/mapi/glapi/gen/glX_proto_size.py | 19 +--
3 files
Here's the last stuff I think I need to be happy to push
GL_ARB_depth_buffer_float under the GL 3.0 override. Mostly I needed
to remove a bunch of code in order to make handling separate
stencil/HiZ for Z32_FLOAT_X24S8 sane. I've tested the series on gen6
with hiz enabled and disabled for float
We were doing it in the caller in the renderbuffer code, but it was
missed in the separate stencil creation for textures. Apparently our
testing was using renderbuffers or pre-aligned sizes.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 44 +--
Now there's the thing that CALLOCs and sets up window system vtable,
and the thing that CALLOCs and sets up user renderbuffer vtable. The
user renderbuffer vtable gets replaced later by
intel_renderbuffer_update_wrapper for wrapped renderbuffers (things
with name == ~0).
---
There were too many things making intel_renderbuffer *s and tweaking
their bits.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 128 +---
1 files changed, 52 insertions(+), 76 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
This used to be needed because irb-mt would be unset for fake packed
depth/stencil, but no longer.
---
src/mesa/drivers/dri/intel/intel_fbo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
There were only two places it was really used at this point, which was
in the batchbuffer emit of the separate stencil packets for gen6/7.
Just write in the -stencil_mt reference in those two places and ditch
all this flailing around with allocation and refcounts.
---
The comment said they deserved to be in emit_depthbuffer, and at this
point they were all there already.
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 15 ---
1 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
Now that we have miptrees for everything, we can more easily test for
!has_separate_stencil completeness. Also, test for whether the
stencil rb is the wrong kind of format for separate stencil, or if we
are trying to do packed to different images of a single miptree.
---
All the operations were just trying to get at irb-wrapped_depth-mt,
which is the same as irb-mt now.
---
src/mesa/drivers/dri/i965/brw_vtbl.c |1 -
src/mesa/drivers/dri/intel/intel_fbo.c | 91 +++-
src/mesa/drivers/dri/intel/intel_fbo.h | 27 +-
3
On 12/08/2011 01:47 PM, Ian Romanick wrote:
There has been quite a bit of skew between what's in Mesa and what's
needed in the xserver. This patch series cleans that up. Most of the
changes are quite mundane and just make the code compile inside the
xserver. However, the changes in patch 6/7
Fixes a regression since d2235b0f4681f75d562131d655a6d7b7033d2d8b,
in my new textureSize sampler(1DArrayShadow|2DShadow|2DArrayShadow)
piglit tests, though I'm not honestly sure how this ever worked.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
This series adds vertex shader texturing support to the i965 driver, as
required by OpenGL 3.0. Only two things remain: textureGrad() on shadow
samplers (which isn't supported in hardware), and coordinate clamping to
support proper filtering at texture borders.
While I added code for texturing
We forgot to implement the color conversions in the new fragment shader
backend, so YCBCR + GLSL has been broken since Mesa 7.10. Additionally,
with the fixed function fragment shader rework, YCBCR + FF is broken in
master. The only combination that should still work is YCBCR + ARB_fp.
We'll be reusing most of these for the VS shortly. The one exception is
TXB (texturing with LOD bias), which is explicitly forbidden in the VS.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_defines.h | 14 +++-
Copy and pasted from fs_inst::is_tex(), but without TXB.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 10 ++
src/mesa/drivers/dri/i965/brw_vec4.h |1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git
This will be especially useful for loading texturing parameters, where I
need to (for example) reference m3.xzD.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
Not strictly
This is the part that takes the vec4_instruction IR and turns it into
actual Gen ISA.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4.h|4 ++
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 79 +++
2 files changed,
This translates the GLSL compiler's IR into vec4_instruction IR,
generating code to load coordinates, LOD info, shadow comparitors, and
so on into the appropriate message registers.
It turns out that the SIMD4x2 parameters are identical on Gen 5-7, and
the Gen4 code is similar enough that, unlike
We'll want to reuse this for the VS, and it's complex enough that I'd
rather not cut and paste it.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 19 +--
src/mesa/drivers/dri/i965/brw_shader.cpp | 23
The visit() half computes the values to put in the header based on the
IR and simply stuffs that in the vec4_instruction; the emit() half uses
this to set up the message header. This works out well since emit() can
use brw_reg directly and access individual DWords without kludgery.
The idea is to reuse this for the VS and (in the future) GS as well.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp |4 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 26 +++---
src/mesa/drivers/dri/i965/brw_program.h | 54
This should avoid state-dependent FS recompiles when samplers that are
only used by the VS change.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_wm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git
Now that this is all factored out, it's trivial to do.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vs.c |8
src/mesa/drivers/dri/i965/brw_vs.h |3 +++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4.h |2 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 51 +++-
2 files changed, 52 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
On Fri, Dec 9, 2011 at 2:02 PM, Chia-I Wu o...@lunarg.com wrote:
On Thu, Dec 8, 2011 at 10:00 PM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
It sets the wrong values (GL_XXX_LEFT instead of GL_XXX), and no other
Mesa driver does this, given that Mesa sets the right
46 matches
Mail list logo
