On Fri, Dec 9, 2011 at 2:02 PM, Chia-I Wu wrote:
> On Thu, Dec 8, 2011 at 10:00 PM, wrote:
>> From: José Fonseca
>>
>> 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 ha
On Thu, Dec 8, 2011 at 10:00 PM, wrote:
> From: José Fonseca
>
> 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 c
Previously, we advertised 0 VS texture units. Now that we have proper
support for using the sampling engine in the VS, we can advertise 16,
which is conveniently the number required for OpenGL 3.0.
While all the support is in place for Gen4+, it's received essentially
no testing on Gen4-5. So fo
Signed-off-by: Kenneth Graunke
---
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
b/src/mesa/drivers/dri/
Now that this is all factored out, it's trivial to do.
Signed-off-by: Kenneth Graunke
---
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 a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/m
This should avoid state-dependent FS recompiles when samplers that are
only used by the VS change.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_wm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/driv
The idea is to reuse this for the VS and (in the future) GS as well.
Signed-off-by: Kenneth Graunke
---
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 +
src/mesa/driv
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.
Signed-off-by:
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
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 19 +--
src/mesa/drivers/dri/i965/brw_shader.cpp | 23 +++
src/mesa/dri
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
This is the part that takes the vec4_instruction IR and turns it into
actual Gen ISA.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.h|4 ++
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 79 +++
2 files changed, 83 insertions(+), 0 del
This will be especially useful for loading texturing parameters, where I
need to (for example) reference m3.xz.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
Not strictly necessary, but seems really u
Copy and pasted from fs_inst::is_tex(), but without TXB.
Signed-off-by: Kenneth Graunke
---
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 a/src/mesa/drivers/dri/i965/brw_vec
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
---
src/mesa/drivers/dri/i965/brw_defines.h | 14 +++-
src/mesa/drivers/dri/i965/brw_fs.cpp | 1
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.
Presumabl
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 on
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
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |3 +++
1 fi
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 m
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 f
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.
---
src/mesa/drivers/dri/inte
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
b/src/mesa/drivers/dri/i96
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.
---
src/mesa/drivers/dri/i965/br
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 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
b/src/mesa/drivers/dri/intel
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).
---
src/mesa/drivers/dri/
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 +--
src/mesa/drivers/dri/in
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 d
From: Ian Romanick
Signed-off-by: Ian Romanick
---
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 changed, 25 insertions(+), 25 deletions(-)
diff
From: Ian Romanick
Signed-off-by: Ian Romanick
---
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
b/src/mapi/glapi/gen/gl_gentable.py
index 814238a..5657e32 100644
From: Ian Romanick
Signed-off-by: Ian Romanick
---
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 100644
--- a/src/mapi/glapi/gen/gl_table.py
+++ b/
From: Ian Romanick
Signed-off-by: Ian Romanick
---
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 b/src/mapi/glapi/gen/Makefile
index 13bd383..c409285
From: Ian Romanick
The versions in the xserver and in libGL have diverged enough that the
xserver doesn't want these.
Signed-off-by: Ian Romanick
---
src/mapi/glapi/gen/Makefile |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/src/mapi/glapi/gen/Makefile b/src/map
From: Ian Romanick
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
---
src/mapi/glapi/gen/EXT_gpu_shade
From: Ian Romanick
That file was removed from the xserver with commit:
commit a80780a7638f847c3be20e5e0c7fe85e83d9bdd1
Author: Adam Jackson
Date: Wed Nov 17 09:03:06 2010 -0500
glx: Remove swap barrier and hyperpipe support
Never implemented in any open source dr
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 back
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 so
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 X
---
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 tests/spec/arb_unifor
---
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
On 12/08/2011 07:00 AM, jfons...@vmware.com wrote:
From: José Fonseca
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 ca
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 Lankhorst
>>
>> ---
>> Changes since v2:
>> - fixed borked ureg_MOV, I have no idea how it worked when I teste
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:
2.3.tar.bz2:SIZE=95466:SHA256=b2141892a0db35feffa5e952f
From: José Fonseca
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.
---
src/mesa/state_tracker/st_manager.c | 64
https://bugs.freedesktop.org/show_bug.cgi?id=43629
--- Comment #1 from Dave Airlie 2011-12-08 05:27:44
PST ---
all the dependencies except dri2proto?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assi
https://bugs.freedesktop.org/show_bug.cgi?id=43629
zap...@berentweb.com changed:
What|Removed |Added
Priority|medium |highest
--
Configure bugmail: htt
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
Maarten Lankhorst wrote:
No point in having it when just having sampler_view_planes is good enough.
Signed-off-by: Maarten Lankhorst
---
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 accele
No point in having it when just having sampler_view_planes is good enough.
Signed-off-by: Maarten Lankhorst
---
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 acceleration
for softpipe and
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 issu
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 resourc
https://bugs.freedesktop.org/show_bug.cgi?id=30484
Jos van Wolput changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
51 matches
Mail list logo
