---
src/gallium/auxiliary/tgsi/tgsi_dump.c |1 +
src/gallium/auxiliary/tgsi/tgsi_scan.c |3 +++
src/gallium/auxiliary/tgsi/tgsi_scan.h |1 +
src/gallium/auxiliary/tgsi/tgsi_text.c |1 +
src/gallium/include/pipe/p_shader_tokens.h |5 +++--
5 files changed, 9
Broken by addition of SYSTEM_VALUE_VERTEX_ID in
919c53e87a1f6f5322bc1f1486bb3e6b954b00d5.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |1 +
src/mesa/state_tracker/st_mesa_to_tgsi.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git
On 11.11.2011 23:59, Brian Paul wrote:
On 11/11/2011 03:18 PM, Christoph Bumiller wrote:
---
src/gallium/auxiliary/tgsi/tgsi_dump.c |1 +
src/gallium/auxiliary/tgsi/tgsi_scan.c |3 +++
src/gallium/auxiliary/tgsi/tgsi_scan.h |1 +
src/gallium/auxiliary/tgsi
On 12.11.2011 00:30, Brian Paul wrote:
On 11/11/2011 04:18 PM, Christoph Bumiller wrote:
On 11.11.2011 23:59, Brian Paul wrote:
On 11/11/2011 03:18 PM, Christoph Bumiller wrote:
---
src/gallium/auxiliary/tgsi/tgsi_dump.c |1 +
src/gallium/auxiliary/tgsi/tgsi_scan.c |3
On 13.11.2011 17:10, Marek Olšák wrote:
I am guessing there is no type info because TGSI shaders are allowed
to use uint, sint, and float instructions on the same register without
type conversions (it would be possible to generate such usage with
GL_ARB_shader_bit_enconding, also
On 13.11.2011 17:32, Christoph Bumiller wrote:
On 13.11.2011 17:10, Marek Olšák wrote:
I am guessing there is no type info because TGSI shaders are allowed
to use uint, sint, and float instructions on the same register without
type conversions (it would be possible to generate such usage
On 14.11.2011 11:33, Jose Fonseca wrote:
- Original Message -
On 13.11.2011 17:32, Christoph Bumiller wrote:
On 13.11.2011 17:10, Marek Olšák wrote:
I am guessing there is no type info because TGSI shaders are
allowed
to use uint, sint, and float instructions on the same register
On 11/14/2011 03:14 PM, Henri Verbeet wrote:
On 14 November 2011 14:49, Vadim Girlin vadimgir...@gmail.com wrote:
By the way, which drivers do not support reading outputs? I haven't done
a full piglit run with llvmpipe, but IIRR the single test mentioned
above was also fixed for llvmpipe
On 11/14/2011 08:23 PM, Jose Fonseca wrote:
- Original Message -
The next open question I have is whether this warrants additions to
the tgsi_opcode_info struct, mainly whether the return value is
uint/int/float,
and whether then src regs are uint/int/float, I'm not 100% that all
On 11/14/2011 09:24 PM, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 08:23 PM, Jose Fonseca wrote:
- Original Message -
The next open question I have is whether this warrants additions
to
the tgsi_opcode_info struct, mainly whether the return value is
On 11/14/2011 09:48 PM, Christoph Bumiller wrote:
On 11/14/2011 09:24 PM, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 08:23 PM, Jose Fonseca wrote:
- Original Message -
The next open question I have is whether this warrants additions
to
the tgsi_opcode_info
On 11/14/2011 10:13 PM, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 09:48 PM, Christoph Bumiller wrote:
On 11/14/2011 09:24 PM, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 08:23 PM, Jose Fonseca wrote:
- Original Message -
The next open
On 11/14/2011 10:36 PM, Christoph Bumiller wrote:
On 11/14/2011 10:13 PM, Jose Fonseca wrote:
My other reply was about this particular case.
But I'm not convinced we can ignore this case at all. I'm fine with drivers
cutting corners. By I can't accept an interface that's broken
On 11/15/2011 04:11 PM, Vadim Girlin wrote:
On Tue, 2011-11-15 at 06:48 -0800, Jose Fonseca wrote:
- Original Message -
On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM,
---
src/gallium/drivers/nouveau/nv_object.xml.h| 13 ++-
src/gallium/drivers/nvc0/nvc0_3d.xml.h |8 +-
src/gallium/drivers/nvc0/nvc0_context.c|2 +-
src/gallium/drivers/nvc0/nvc0_context.h| 25 +++--
src/gallium/drivers/nvc0/nvc0_program.c| 42
On 11/30/2011 09:10 PM, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
This fixes the firefox crash but I've no idea if its correct.
I don't think it is.
Visual.samples is the value passed to RenderbufferStorageMultisample,
and 1 here means a desired minimum number of samples so the
On 03.12.2011 17:14, Vincent Lejeune wrote:
glsl to tgsi pass now queries for reading output register cap
from drivers. This made nvc0/nvfx complain about unknow
PIPE_CAP that breaks piglit tests. This patch fix this.
---
src/gallium/drivers/nv50/nv50_screen.c |2 ++
On 11/19/2011 09:44 PM, Marek Olšák wrote:
Hi everyone,
this patch series implements all the core Mesa and Gallium support for
EXT_transform_feedback and ARB_transform_feedback2. It's been tested by me on
Radeons and by Christoph Bumiller on Nouveau. I have verified that all
transform
and by Christoph Bumiller on Nouveau. I
have verified that all transform feedback piglit tests (except the
one that requires GLSL 1.3) pass with this code.
Since we were discussing this last time, the Gallium interface has
been slightly modified to make it easier to implement by drivers
On 12/06/2011 10:19 AM, Thomas Hellstrom wrote:
Some hardware can't reinterpret the format of hardware buffers and thus
the X server needs to know the format when the buffer is created.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/state_trackers/dri/drm/dri2.c |
From: Marek Olšák mar...@gmail.com
I am going to make interface changes and I don't want to break compilation.
---
src/gallium/drivers/llvmpipe/lp_state_so.c |7 +++
src/gallium/drivers/nvc0/nvc0_state.c |7 +++
src/gallium/drivers/softpipe/sp_context.c |2 +-
---
src/gallium/drivers/trace/tr_context.c | 73
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/trace/tr_context.c
b/src/gallium/drivers/trace/tr_context.c
index 6021bb9..240d85c 100644
---
From: Marek Olšák mar...@gmail.com
---
src/gallium/drivers/noop/noop_state.c | 35 +
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/noop/noop_state.c
b/src/gallium/drivers/noop/noop_state.c
index 58ea8be..9d8dbfc 100644
---
From: Marek Olšák mar...@gmail.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c|9 +++--
src/gallium/auxiliary/tgsi/tgsi_ureg.h| 18 ++
src/gallium/auxiliary/util/u_debug_describe.c | 10 ++
src/gallium/auxiliary/util/u_debug_describe.h |2 ++
From: Marek Olšák mar...@gmail.com
It's like DrawArrays, but the count is taken from a transform feedback
object.
This removes DrawTransformFeedback from dd_function_table and adds the same
function to GLvertexformat (with the function parameters matching GL).
The vbo_draw_func callback has a
From: Marek Olšák mar...@gmail.com
---
src/gallium/auxiliary/util/u_blitter.c | 18 ++
src/gallium/auxiliary/util/u_blitter.h | 18 ++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
From: Marek Olšák mar...@gmail.com
---
src/gallium/auxiliary/util/u_blitter.c | 87 +++-
src/gallium/auxiliary/util/u_blitter.h | 11
2 files changed, 96 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
---
.../state_trackers/d3d1x/dxgi/src/dxgi_native.cpp |4 +-
.../state_trackers/d3d1x/gd3d11/d3d11_context.h| 104 +---
.../state_trackers/d3d1x/gd3d11/d3d11_objects.h| 25 +-
.../state_trackers/d3d1x/gd3d11/d3d11_screen.h | 86 ++--
From: Marek Olšák mar...@gmail.com
---
src/gallium/auxiliary/cso_cache/cso_context.c | 101 ++
src/gallium/auxiliary/cso_cache/cso_context.h |8 ++
src/gallium/auxiliary/util/u_blit.c |6 +
src/gallium/auxiliary/util/u_gen_mipmap.c |3 +
---
src/gallium/drivers/nouveau/nv_object.xml.h| 13 ++-
src/gallium/drivers/nvc0/nvc0_3d.xml.h |8 +-
src/gallium/drivers/nvc0/nvc0_context.c|2 +-
src/gallium/drivers/nvc0/nvc0_context.h| 25 +++--
src/gallium/drivers/nvc0/nvc0_program.c| 43
On 10.12.2011 20:19, Ian Romanick wrote:
On 12/09/2011 07:14 PM, Marek Olšák wrote:
This is only temporary until a better solution is available.
---
I haven't given up yet because reporting incorrect driver limits
may cause more troubles than this. I made it pretty small this
time.
It
On 12/13/2011 09:29 PM, Christoph Bumiller wrote:
On 12/13/2011 09:11 PM, Jose Fonseca wrote:
- Original Message -
This is an updated version of the patch set I sent to the list a few
hours
ago.
There is now a TGSI property called
TGSI_PROPERTY_NUM_CLIP_DISTANCES
that drivers
On 12/13/2011 09:58 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 09:11 PM, Jose Fonseca wrote:
- Original Message -
This is an updated version of the patch set I sent to the list a
few
hours
ago.
There is now a TGSI property called
On 12/12/2011 05:37 PM, Jose Fonseca wrote:
- Original Message -
On 12/12/2011 02:49 PM, Jose Fonseca wrote:
- Original Message -
From: Marek Olšák mar...@gmail.com
It's like DrawArrays, but the count is taken from a transform
feedback
object.
This removes
On 12/13/2011 10:48 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan Cain wrote:
On 12/13/2011 02:11 PM, Jose
On 12/14/2011 12:24 AM, Marek Olšák wrote:
On Tue, Dec 13, 2011 at 11:22 PM, Jose Fonseca jfons...@vmware.com wrote:
Another approach would be just to add the property, and kill output mask.
Two ways of doing the same is what I'd like to avoid. I'll need a day (it's
late here) to think about
On 12/14/2011 12:58 AM, Ian Romanick wrote:
On 12/13/2011 01:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan Cain wrote:
On 12/13/2011 02:11 PM, Jose Fonseca wrote:
-
On 15.12.2011 20:09, Jose Fonseca wrote:
- Original Message -
On 12/14/2011 12:58 AM, Ian Romanick wrote:
On 12/13/2011 01:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan
On 16.12.2011 19:27, Ian Romanick wrote:
On 12/13/2011 05:08 PM, Christoph Bumiller wrote:
On 12/14/2011 12:58 AM, Ian Romanick wrote:
On 12/13/2011 01:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12
On 17.12.2011 15:45, Marek Olšák wrote:
---
This was suggested by Keith Whitwell in this email addressed to me on
8/6/2010:
http://lists.freedesktop.org/archives/mesa-dev/2010-August/001810.html
src/gallium/include/pipe/p_defines.h |2 +-
src/gallium/include/pipe/p_state.h | 14
On 17.12.2011 20:54, Marek Olšák wrote:
On Sat, Dec 17, 2011 at 4:45 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 17.12.2011 15:45, Marek Olšák wrote:
---
This was suggested by Keith Whitwell in this email addressed to me on
8/6/2010:
http://lists.freedesktop.org
---
src/mesa/state_tracker/st_draw.c | 63 +++--
src/mesa/state_tracker/st_draw.h |2 +-
src/mesa/state_tracker/st_draw_feedback.c |3 +-
3 files changed, 62 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c
On 19.12.2011 18:10, Dave Airlie wrote:
Hi guys,
So we have some piglit tests
generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_FrontColor-smooth-none.shader_test
that piglit fails
This seems to be due to its linear interpolation not producing the
correct answers
Ping ...
Integer attributes shouldn't be exposed with any drivers that don't
support native integers, so there shouldn't be any extra checks necessary.
On 12/19/2011 04:45 PM, Christoph Bumiller wrote:
---
src/mesa/state_tracker/st_draw.c | 63
+++--
src
On 01/06/2012 04:35 PM, Brian Paul wrote:
On 01/06/2012 08:26 AM, Dave Airlie wrote:
On Fri, Jan 6, 2012 at 3:13 PM, Brian Paulbri...@vmware.com wrote:
On 01/06/2012 06:57 AM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
Brian mentioned that mesa-demos/reflect was broken on
On 01/06/2012 08:26 PM, Ian Romanick wrote:
On 01/06/2012 09:04 AM, Dave Airlie wrote:
Hi guys,
Just a quick note, I've just spent a week or so trying to see where
gallium and softpipe were w.r.t GL3.0 support.
I've pushed a branch to my repo called softpipe-gl3. It contains
patches in
Enabled only for nvc0 at the moment.
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/drivers/i915/i915_screen.c |1 +
src/gallium/drivers/llvmpipe/lp_screen.c |2 ++
src/gallium/drivers/nv50/nv50_screen.c |2 ++
src/gallium/drivers/nvc0/nvc0_screen.c |1 +
---
src/mesa/state_tracker/st_extensions.c |8
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 14 +++---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index a9d4054..c8171ef
On 10.01.2012 04:52, Stéphane Marchesin wrote:
Hi Dave,
This regresses interpolation-none-gl_FrontColor-flat-vertex.shader_test
piglit test on i915g.
That's likely. You're probably not using the ClipVertex but instead
gl_Position for clipping since the prior was not identifiable before.
The
On 10.01.2012 12:29, Jose Fonseca wrote:
Still catching up on email traffic during holidays...
I agree that user buffer uploads should be moved out of drivers, but I don't
think this is the way to go.
I don't. If the state tracker uploads user buffers and presents them to
the driver as
On 01/10/2012 01:13 PM, Jose Fonseca wrote:
- Original Message -
On 10.01.2012 12:29, Jose Fonseca wrote:
Still catching up on email traffic during holidays...
I agree that user buffer uploads should be moved out of drivers,
but I don't think this is the way to go.
I don't. If the
On 01/10/2012 10:09 PM, Dave Airlie wrote:
On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt e...@anholt.net wrote:
On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
Things can get confused if you expose one without the other which can
The nvc0 gallium driver is advertising 128 MAX_INTERLEAVED_COMPS
which made it always assert in the linker when TFB was used.
The new size corresponds to the maximum number of possible unique
outputs when varying packing is used.
NOTE: This is a candidate for the 8.0 branch.
---
Trivial fix (I hope), came across this when testing multisampling via
RenderbufferMultisample.
Christoph
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 07/22/2011 11:50 PM, Christoph Bumiller wrote:
Trivial fix (I hope), came across this when testing multisampling via
RenderbufferMultisample.
Christoph
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org
power of 2) which can
presently not be done through the gallium interface.
From b35a1ce7248237ac0cf4209eb8703d13c380ff5a Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Sat, 23 Jul 2011 00:55:20 +0200
Subject: [PATCH 3/6] st/mesa: determine Const.MaxSamples
, where
some hw can easily do a backwards copy (yflip).
From cc990d3a7a96c3b04939d21cba001d988ce43327 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Mon, 25 Jul 2011 14:11:38 +0200
Subject: [PATCH 4/6] gallium: extend resource_resolve to accommodate
BlitFramebuffer
...
From 2d57a1ee06b9d370bae6f9b8d8e59de180d2584a Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Mon, 25 Jul 2011 14:14:01 +0200
Subject: [PATCH 5/6] st/mesa: implement multisample resolve via BlitFramebuffer
---
src/gallium/auxiliary/util/u_box.h | 25
...
From 3a63ebc31e91d7bf927c55c7fca9fe190984b16c Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Mon, 25 Jul 2011 14:21:29 +0200
Subject: [PATCH 6/6] nv50: implement resource_resolve with custom blit
---
src/gallium/drivers/nv50/nv50_context.h|3
On 07/25/2011 02:47 PM, Christoph Bumiller wrote:
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size parameters are needed.
The mask parameter was added because resolving
On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size parameters are needed.
The mask parameter was added because resolving
On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size parameters are
On 07/25/2011 10:43 PM, Roland Scheidegger wrote:
On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other
On 07/26/2011 01:49 AM, Roland Scheidegger wrote:
(Strange thought sent that before - mail client going crazy...)
Resolving color buffers is pretty well defined (for standard msaa at
least). I have no idea how that's supposed to be defined for depth
and stencil values. Frankly I'm not sure
v2: Check for non-pow2 sample counts as well.
---
src/mesa/state_tracker/st_extensions.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index b5f6d35..8e90093 100644
---
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, and, with a new extension, even scaling. Therefore,
location and size parameters are needed.
The mask parameter was added because resolving only depth
---
src/mesa/state_tracker/st_cb_blit.c | 116 +--
1 files changed, 111 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_blit.c
b/src/mesa/state_tracker/st_cb_blit.c
index 416be19..a79c891 100644
--- a/src/mesa/state_tracker/st_cb_blit.c
---
src/gallium/drivers/nv50/nv50_context.h|3 +-
src/gallium/drivers/nv50/nv50_formats.c|4 +-
src/gallium/drivers/nv50/nv50_screen.c |4 +
src/gallium/drivers/nv50/nv50_screen.h |6 +
src/gallium/drivers/nv50/nv50_shader_state.c | 11 +-
On 28.07.2011 15:59, Christoph Bumiller wrote:
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, and, with a new extension, even scaling. Therefore,
location and size parameters are needed
.
I'm deactivating the viewport transform and flipping the non-normalized
texture coordinates instead ...
Visualize a fixed destination region, then that you cut out some source,
turn it around and stretch it, then sticking it where you want it :-)
Roland
On 28.07.2011 15:59, Christoph
On 17.08.2011 18:56, Lauri Kasanen wrote:
On Wed, 17 Aug 2011 09:13:24 -0600
Brian Paul bri...@vmware.com wrote:
I don't know if this is possible, but could the post-processor be
constructed as another gallium driver that wraps other drivers? For
example, the rbug driver is a wrapper
On 20.08.2011 22:07, Dan McCabe wrote:
On 08/20/2011 12:16 AM, Kenneth Graunke wrote:
On 08/19/2011 05:56 PM, Eric Anholt wrote:
We have to actually convert the values on the way out. Fixes piglit
ARB_shader_objects/getuniform.
---
src/mesa/main/uniforms.c | 32
On 21.08.2011 06:00, Kenneth Graunke wrote:
On 08/20/2011 02:47 PM, Christoph Bumiller wrote:
On 20.08.2011 22:07, Dan McCabe wrote:
On 08/20/2011 12:16 AM, Kenneth Graunke wrote:
On 08/19/2011 05:56 PM, Eric Anholt wrote:
We have to actually convert the values on the way out. Fixes piglit
On 25.08.2011 06:42, Zack Rusin wrote:
On Wednesday, August 24, 2011 10:14:48 PM Bryan Cain wrote:
Like Dave said, the GLSL-TGSI translator needs to account for this.
Probably not, at least yet. All of those instructions are DX10.1 level
instructions which support splitting of samplers and
On 25.08.2011 22:40, Zack Rusin wrote:
On Thursday, August 25, 2011 04:30:26 PM Christoph Bumiller wrote:
Putting the resource type in the resource declaration instead of the
instruction isn't necessarily smart considering indirect resource access
... I just hope the person implementing
On 25.08.2011 22:42, Christoph Bumiller wrote:
On 25.08.2011 22:40, Zack Rusin wrote:
On Thursday, August 25, 2011 04:30:26 PM Christoph Bumiller wrote:
Putting the resource type in the resource declaration instead of the
instruction isn't necessarily smart considering indirect resource access
On 26.08.2011 17:37, Lauri Kasanen wrote:
On Fri, 26 Aug 2011 17:21:02 +0200
Christoph Bumiller e0425...@student.tuwien.ac.at wrote:
We cannot rely on pipe drivers to default to non-zero.
Fixes pp being a no-op on nv50.
Reviewed-by: Lauri Kasanen c...@gmx.com
Appears to be a no-op
On 26.08.2011 20:57, Ian Romanick wrote:
On 08/26/2011 09:26 AM, Dave Airlie wrote:
I've involuntarily started looking into this when I tried to add TXF
support, so we need to expand TGSI to add support for texture offsets.
Requirements:
the extreme requirement so far is for
On 27.08.2011 04:58, Bryan Cain wrote:
This fixes all of the piglit regressions in softpipe when native integers are
enabled.
---
src/mesa/main/uniforms.c |8 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 45
++--
2 files changed, 43
A change in sampleBuffers affects the final enable value.
---
src/mesa/main/state.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 7ad50bc..457a730 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@
The window system buffer will be BGRA and applications will try to
directly resolve to it, which would trigger an INVALID_OPERATION in
BlitFramebuffer if the multisample renderbuffer is RGBA.
---
src/gallium/drivers/nv50/nv50_screen.c |7 ++-
src/gallium/drivers/nvc0/nvc0_screen.c | 12
On 29.08.2011 19:22, Ian Romanick wrote:
On 08/27/2011 08:44 AM, Bryan Cain wrote:
On 08/27/2011 05:39 AM, Christoph Bumiller wrote:
On 27.08.2011 04:58, Bryan Cain wrote:
This fixes all of the piglit regressions in softpipe when native
integers are
enabled.
---
src/mesa/main
On 08/30/2011 04:43 PM, Brian Paul wrote:
On Mon, Aug 29, 2011 at 7:38 AM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
This adds tokens for texture offsets, to store 4 * swizzled vec 3
for use in TXF and other opcodes.
It also contains TGSI exec changes for
On 01.09.2011 17:02, Younes Manton wrote:
On Thu, Sep 1, 2011 at 10:56 AM, Michel Dänzer mic...@daenzer.net wrote:
On Don, 2011-09-01 at 15:50 +0200, Christian König wrote:
Start with correctly defining IA44 and AI44 formats.
Signed-off-by: Christian König deathsim...@vodafone.de
---
On 01.09.2011 18:05, Christian König wrote:
Am Donnerstag, den 01.09.2011, 17:08 +0200 schrieb Christoph Bumiller:
On 01.09.2011 17:02, Younes Manton wrote:
On Thu, Sep 1, 2011 at 10:56 AM, Michel Dänzer mic...@daenzer.net wrote:
On Don, 2011-09-01 at 15:50 +0200, Christian König wrote:
Start
I encountered some failures in piglit's tests of builtins because a
vector constructor that is given only 1 single argument does not
replicate the argument into the yzw components, for example:
diff --git a/src/glsl/builtins/ir/cosh b/src/glsl/builtins/ir/cosh
index 45e0ae4..8bf3ad2 100644
---
On 05.09.2011 23:44, Marek Olšák wrote:
---
src/gallium/include/pipe/p_defines.h |1 +
src/mesa/state_tracker/st_extensions.c |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index
On 02.09.2011 18:09, Bryan Cain wrote:
They are needed by glsl_to_tgsi for an efficient implementation using native
integers.
UCMP:
NVC0 and R600 have a hardware op for this, so it would be really nice to
have for selection.
UARL:
The normal ARL expects a float source so this saves a
On 12.09.2011 13:09, Dave Airlie wrote:
At line 585 in st_cb_clear.c
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_cb_clear.c#n585
we translate the clear color, but never use the result, maybe someone
knows what should have happened here.
The intention probably was to
the device.
Best regards, Christoph
From c7f38f3a09f457e26736c79bcdf62050226987ce Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Mon, 19 Sep 2011 11:21:38 +0200
Subject: [PATCH] d3d1x: fix refcounting of GalliumD3D11DeviceChild objects
---
.../state_trackers
This is required for D3D1x and supported by hardware.
---
src/gallium/auxiliary/draw/draw_pipe_offset.c |6 ++
src/gallium/auxiliary/util/u_dump_state.c |1 +
src/gallium/docs/source/cso/rasterizer.rst|2 ++
src/gallium/drivers/trace/tr_dump_state.c |1 +
---
.../state_trackers/d3d1x/gd3d11/d3d11_screen.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/d3d1x/gd3d11/d3d11_screen.h
b/src/gallium/state_trackers/d3d1x/gd3d11/d3d11_screen.h
index 3674731..ef23b7d 100644
---
---
src/gallium/drivers/nv50/nv50_3d.xml.h |2 +-
src/gallium/drivers/nv50/nv50_state.c|2 ++
src/gallium/drivers/nv50/nv50_stateobj.h |2 +-
src/gallium/drivers/nvc0/nvc0_3d.xml.h |2 ++
src/gallium/drivers/nvc0/nvc0_state.c|2 ++
---
src/gallium/drivers/r600/evergreen_state.c |2 +-
src/gallium/drivers/r600/r600_state.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 3b7844f..7a6b246 100644
---
On 25.09.2011 00:32, Brian Paul wrote:
On Sat, Sep 24, 2011 at 7:47 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
This is required for D3D1x and supported by hardware.
---
src/gallium/auxiliary/draw/draw_pipe_offset.c |6 ++
src/gallium/auxiliary/util/u_dump_state.c
On 07.10.2011 04:04, Marek Olšák wrote:
On Fri, Oct 7, 2011 at 3:21 AM, Zack Rusin za...@vmware.com wrote:
On Thursday, October 06, 2011 04:58:45 PM Marek Olšák wrote:
I am cc'ing Zack, because he was the one to design the first interface.
Hi Marek.
I'm swamped right now and won't have time
This is required for d3d1x's CheckFormatSupport query.
It also seems generally useful for state trackers, which could
choose alternative rendering paths or formats if blending would
come at a significant performance loss.
---
src/gallium/docs/source/screen.rst |3 +++
On 12.10.2011 16:12, Brian Paul wrote:
On 10/10/2011 01:53 PM, Christoph Bumiller wrote:
This is required for d3d1x's CheckFormatSupport query.
It also seems generally useful for state trackers, which could
choose alternative rendering paths or formats if blending would
come at a significant
---
.../state_trackers/d3d1x/gd3d11/d3d11_screen.h |9 ---
.../state_trackers/d3d1x/gd3d1x/d3d_enums.cpp | 26 ++--
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/src/gallium/state_trackers/d3d1x/gd3d11/d3d11_screen.h
---
src/gallium/docs/source/context.rst | 63 ++---
src/gallium/include/pipe/p_defines.h | 19 ++
2 files changed, 68 insertions(+), 14 deletions(-)
diff --git a/src/gallium/docs/source/context.rst
b/src/gallium/docs/source/context.rst
index
1 - 100 of 317 matches
Mail list logo
