---
src/gallium/drivers/softpipe/sp_query.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_query.c
b/src/gallium/drivers/softpipe/sp_query.c
index 88f4257..c2c48e8 100644
--- a/src/gallium/drivers/softpipe/sp_query.c
+++
On 23.01.2013 01:21, Vadim Girlin wrote:
On 01/23/2013 03:59 AM, Vincent Lejeune wrote:
- Mail original -
De : Vadim Girlin vadimgir...@gmail.com
À : Christoph Bumiller e0425...@student.tuwien.ac.at
Cc : mesa-dev@lists.freedesktop.org
Envoyé le : Mercredi 23 janvier 2013 0h44
On 23.01.2013 01:47, Vadim Girlin wrote:
On 01/23/2013 04:07 AM, Dave Airlie wrote:
On Wed, Jan 23, 2013 at 9:44 AM, Vadim Girlin vadimgir...@gmail.com
wrote:
On 01/22/2013 10:59 PM, Christoph Bumiller wrote:
On 21.01.2013 21:10, Vadim Girlin wrote:
Provide the information about indirectly
On 23.01.2013 02:07, Vadim Girlin wrote:
On 01/23/2013 04:42 AM, Christoph Bumiller wrote:
On 23.01.2013 01:21, Vadim Girlin wrote:
On 01/23/2013 03:59 AM, Vincent Lejeune wrote:
- Mail original -
De : Vadim Girlin vadimgir...@gmail.com
À : Christoph Bumiller e0425
On 23.01.2013 11:31, Christian König wrote:
On 23.01.2013 03:18, Tom Stellard wrote:
On Wed, Jan 23, 2013 at 02:20:21AM +0100, Christoph Bumiller wrote:
On 23.01.2013 02:07, Vadim Girlin wrote:
On 01/23/2013 04:42 AM, Christoph Bumiller wrote:
On 23.01.2013 01:21, Vadim Girlin wrote:
On 01
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
Clarify invalid offset alignment error message.
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
Clarify invalid offset alignment error message.
On 27.01.2013 00:58, Eric Anholt wrote:
Christoph Bumiller e0425...@student.tuwien.ac.at writes:
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 31a559e..e71f6e1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
+/** GL_ARB_texture_buffer_object
On 28.01.2013 19:54, Ian Romanick wrote:
On 01/27/2013 12:19 PM, Eric Anholt wrote:
Christoph Bumiller e0425...@student.tuwien.ac.at writes:
On 27.01.2013 00:58, Eric Anholt wrote:
Christoph Bumiller e0425...@student.tuwien.ac.at writes:
diff --git a/src/mesa/main/teximage.c b/src/mesa/main
From: Christoph Bumiller christoph.bumil...@speed.at
Only the test of the extension enable should be relevant.
---
src/mesa/main/teximage.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 31a559e..5a27797 100644
On 28.01.2013 23:37, Chad Versace wrote:
On 01/28/2013 02:01 PM, Christoph Bumiller wrote:
From: Christoph Bumiller christoph.bumil...@speed.at
Only the test of the extension enable should be relevant.
I don't think this change is correct.
So, maybe I misinterpreted the advice in the mesa
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
Clarify invalid offset alignment error message.
On 31.01.2013 09:30, Michel Dänzer wrote:
On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
- Original Message -
On Mit, 2013-01-30 at 06:12 -0800, Jose Fonseca wrote:
- Original Message -
On Mon, 2013-01-28 at 06:56 -0500, Adam Jackson wrote:
I've been looking at
On 01.02.2013 19:29, Brian Paul wrote:
The glsl-to-tgsi translater will emit SQRT to implement GLSL's sqrt()
and distance() functions if the PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED
query says it's supported by the driver.
Otherwise, sqrt(x) is implemented with x*rsq(x). The problem with
this is
I have 1 piglit test to check drawing with several combinations of
parameters (using transform feedback to write the commands), but
will make some more tests for various things like interaction with
PrimitiveRestart or error conditions.
---
src/mesa/state_tracker/st_draw.c |7 ++-
src/mesa/state_tracker/st_extensions.c |4 +++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 0f3aae7..f9fbd32 100644
---
---
docs/GL3.txt |4 +-
src/gallium/drivers/nvc0/nvc0_3d.xml.h |4 +
src/gallium/drivers/nvc0/nvc0_graph_macros.h | 121 ++
src/gallium/drivers/nvc0/nvc0_screen.c |6 ++
src/gallium/drivers/nvc0/nvc0_vbo.c |
On 02.02.2013 08:32, Adrian M Negreanu wrote:
On Fri, Feb 1, 2013 at 11:50 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
I have 1 piglit test to check drawing with several combinations of
parameters (using transform feedback to write the commands), but
will make some more tests
Intend to merge this into the previous ARB_draw_indirect patches.
Just in case there's any complaints ...
Needed to add this so the DRAW_INDIRECT_BUFFER doesn't get placed
into a non-GPU accessible domain. Besides, this seems reasonable,
and D3D11 has it, too (albeit a specialized version, called
On 04.02.2013 08:27, Michel Dänzer wrote:
On Fre, 2013-02-01 at 22:50 +0100, Christoph Bumiller wrote:
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index d0f0070..7ae9dd6 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium
On 11.02.2013 20:47, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
It looks like using coord.w as explicit lod value is a mistake, most likely
because some dx10 docs had it specified that way. Seems this was changed
though:
On 27.02.2013 10:44, Jose Fonseca wrote:
- Original Message -
What is this good for? Is it for UAVs? (unordered access views)
No, it is just a standard D3D10 feature:
http://msdn.microsoft.com/en-gb/library/windows/desktop/bb204897.aspx
Not sure if there's a particular use case for
On 01.03.2013 11:30, Jose Fonseca wrote:
- Original Message -
On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger srol...@vmware.com
wrote:
Hi,
there is some sloppy usage of bind flags in the opengl state tracker
(that is, resources get used for things which they didn't have the
On 11.03.2013 11:26, Jose Fonseca wrote:
First email was too long, so re-sending just the interesting bits)
Please tell me removing this came to mind because you're going to
release a better D3D9,10/11 state tracker :)
(Nah I guess it would be too much trouble if there's no users for it ...)
On 11.03.2013 13:44, Christian König wrote:
Hi everybody,
this problem has been open for quite some time now, with a bunch of different
opinions and sometimes even patches floating on the list.
Nice, finally someone implements a proper solution.
However, it seems like this isn't used for
On 11.03.2013 15:38, Christian König wrote:
Am 11.03.2013 14:47, schrieb Christoph Bumiller:
On 11.03.2013 13:44, Christian König wrote:
Hi everybody,
this problem has been open for quite some time now, with a bunch of
different
opinions and sometimes even patches floating on the list
On 11.03.2013 19:33, Brian Paul wrote:
On 03/11/2013 06:44 AM, Christian König wrote:
Hi everybody,
this problem has been open for quite some time now, with a bunch of
different
opinions and sometimes even patches floating on the list.
The solutions proposed or implemented so far all more
On 12.03.2013 10:31, Christian König wrote:
Am 12.03.2013 02:48, schrieb Marek Olšák:
On Mon, Mar 11, 2013 at 1:44 PM, Christian König
deathsim...@vodafone.de wrote:
Hi everybody,
this problem has been open for quite some time now, with a bunch of
different
opinions and sometimes even
On 12.03.2013 12:10, Christoph Bumiller wrote:
On 12.03.2013 10:31, Christian König wrote:
Am 12.03.2013 02:48, schrieb Marek Olšák:
On Mon, Mar 11, 2013 at 1:44 PM, Christian König
deathsim...@vodafone.de wrote:
Hi everybody,
this problem has been open for quite some time now, with a bunch
Second attempt, 2 years ago no one replied or cared ...
We really need to know about these on nvc0 because there are only 8
fixed hardware locations that can be overwritten by sprite coordinates,
and one location that represents gl_PointCoord and unconditionally
returns sprite coordinates.
So
---
src/gallium/auxiliary/draw/draw_pipe_wide_point.c | 46 +--
src/gallium/auxiliary/tgsi/tgsi_dump.c|1 +
src/gallium/auxiliary/tgsi/tgsi_strings.c |4 +-
src/gallium/docs/source/cso/rasterizer.rst|5 ++
src/gallium/docs/source/screen.rst
On 15.03.2013 13:08, Christian König wrote:
Am 14.03.2013 15:53, schrieb Christoph Bumiller:
On 14.03.2013 15:20, Christian König wrote:
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/docs/source/tgsi.rst | 16
This makes it possible to identify gl_TexCoord and gl_PointCoord
for drivers where sprite coordinate replacement is restricted.
The new PIPE_CAP_TGSI_TEXCOORD decides whether these varyings
should be hidden behind the GENERIC semantic or not.
With this patch only nvc0 and nv30 will request that
On 17.03.2013 16:30, Christian König wrote:
Am 15.03.2013 18:58, schrieb Christoph Bumiller:
On 15.03.2013 13:08, Christian König wrote:
Am 14.03.2013 15:53, schrieb Christoph Bumiller:
On 14.03.2013 15:20, Christian König wrote:
From: Christian König christian.koe...@amd.com
Signed-off
On 17.03.2013 18:04, Christoph Bumiller wrote:
On 17.03.2013 16:30, Christian König wrote:
Am 15.03.2013 18:58, schrieb Christoph Bumiller:
On 15.03.2013 13:08, Christian König wrote:
Am 14.03.2013 15:53, schrieb Christoph Bumiller:
On 14.03.2013 15:20, Christian König wrote:
From: Christian
On 15.03.2013 22:16, Christoph Bumiller wrote:
This makes it possible to identify gl_TexCoord and gl_PointCoord
for drivers where sprite coordinate replacement is restricted.
The new PIPE_CAP_TGSI_TEXCOORD decides whether these varyings
should be hidden behind the GENERIC semantic
Sorry, this has become longer than I anticipated ...
I've been toying with adding support for TGSI_FILE_INPUT/OUTPUT arrays
because, since I cannot allocate varyings in the same order that the
register index specifies, I need it:
===
EXAMPLE:
OUT[0], CLIPDIST[1], must be allocated at address
On 20.03.2013 17:05, Roland Scheidegger wrote:
Am 20.03.2013 15:41, schrieb Christoph Bumiller:
Sorry, this has become longer than I anticipated ...
I've been toying with adding support for TGSI_FILE_INPUT/OUTPUT arrays
because, since I cannot allocate varyings in the same order
On 20.03.2013 18:30, Roland Scheidegger wrote:
Am 20.03.2013 17:46, schrieb Christoph Bumiller:
On 20.03.2013 17:05, Roland Scheidegger wrote:
Not sure I fully understand this, but I'm thinking whenever in doubt,
use something close to what dx10 does since that's likely going to work
On 26.03.2013 12:18, Vadim Girlin wrote:
On 03/26/2013 02:00 AM, Marek Olšák wrote:
On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com
wrote:
On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote:
Hi everyone, one image is better than a thousand words:
...
Hi,
I tried
On 29.03.2013 10:56, Christian König wrote:
Am 28.03.2013 20:34, schrieb Vadim Girlin:
On 03/28/2013 01:01 PM, � wrote:
Am 27.03.2013 20:37, schrieb Vadim Girlin:
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/r600_shader.c | 19 +++
1 file
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/drivers/freedreno/freedreno_screen.c |1 +
src/gallium/drivers/i915/i915_screen.c |1 +
src/gallium/drivers/llvmpipe/lp_screen.c |2 ++
src/gallium/drivers/nv30/nv30_screen.c |1
Also, renamed pixels-rendered to samples-passed because the
occlusion counter increments even if colour and depth writes are
disabled, or (on some implementations) for killed that passed the
depth test when early_fragment_tests has been set for the PS.
---
src/gallium/auxiliary/hud/hud_context.c
---
src/gallium/docs/source/context.rst |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/docs/source/context.rst
b/src/gallium/docs/source/context.rst
index 9e57930..2cc1848 100644
--- a/src/gallium/docs/source/context.rst
+++
NOTE: Changed the semantic index for the drawtex coordiante to
be the texture unit index instead of always 0.
Not sure if this is correct but since the value seems to depend
on the unit it would make sense to use different varying slots.
---
src/mesa/state_tracker/st_cb_bitmap.c |1 +
On 02.04.2013 16:39, Brian Paul wrote:
On 03/30/2013 08:11 AM, Christoph Bumiller wrote:
NOTE: Changed the semantic index for the drawtex coordiante to
be the texture unit index instead of always 0.
Not sure if this is correct but since the value seems to depend
on the unit it would make
On 04.04.2013 03:45, Zack Rusin wrote:
It's part of SM4 (http://goo.gl/4IpeK). It's also fairly
painful to emulate without branching. Most hardware
supports it natively and even llvm has a 'select' opcode
which can handle it without too much hassle.
diff --git
On 04.04.2013 16:53, Zack Rusin wrote:
On 04.04.2013 03:45, Zack Rusin wrote:
It's part of SM4 (http://goo.gl/4IpeK). It's also fairly
painful to emulate without branching. Most hardware
supports it natively and even llvm has a 'select' opcode
which can handle it without too much hassle.
On 04.04.2013 17:01, Jose Fonseca wrote:
- Original Message -
On 04.04.2013 03:45, Zack Rusin wrote:
It's part of SM4 (http://goo.gl/4IpeK). It's also fairly
painful to emulate without branching. Most hardware
supports it natively and even llvm has a 'select' opcode
which can handle
On 04.04.2013 17:23, Jose Fonseca wrote:
- Original Message -
On 04.04.2013 17:01, Jose Fonseca wrote:
- Original Message -
On 04.04.2013 03:45, Zack Rusin wrote:
It's part of SM4 (http://goo.gl/4IpeK). It's also fairly
painful to emulate without branching. Most hardware
---
src/mapi/glapi/gen/Makefile.am |1 +
src/mapi/glapi/gen/gl_API.xml|4 +-
src/mesa/drivers/dri/i965/brw_draw.c |3 +-
src/mesa/drivers/dri/i965/brw_draw.h |3 +-
src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c |9 +-
---
src/mesa/state_tracker/st_cb_bufferobjects.c |3 +++
src/mesa/state_tracker/st_draw.c | 11 ++-
src/mesa/state_tracker/st_extensions.c |4 +++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c
---
src/gallium/auxiliary/util/u_draw.c | 39 ++
src/gallium/auxiliary/util/u_draw.h |5 +++
src/gallium/auxiliary/util/u_dump_state.c|3 ++
src/gallium/docs/source/screen.rst |3 ++
---
src/mapi/glapi/gen/ARB_draw_indirect.xml | 45 +
src/mapi/glapi/gen/Makefile.am |1 +
src/mapi/glapi/gen/gl_API.xml|4 +-
src/mesa/drivers/dri/i965/brw_draw.c |3 +-
src/mesa/drivers/dri/i965/brw_draw.h |3 +-
On 04.04.2013 21:44, Jose Fonseca wrote:
I think that PIPE_BIND_INDIRECT_BUFFER would be more self-descriptive.
Or do you envision other uses of such buffer?
It's possible that at some point we add a mechanism to let the driver
store arbitrary commands into a buffer created by the st, or have
On 04.04.2013 21:53, Christoph Bumiller wrote:
On 04.04.2013 21:44, Jose Fonseca wrote:
I think that PIPE_BIND_INDIRECT_BUFFER would be more self-descriptive.
Marek suggested PIPE_BIND_DRAW_INDIRECT_BUFFER, but I think that's too
specific because there's also a DISPATCH_INDIRECT buffer
On 04.04.2013 21:17, Brian Paul wrote:
I just did a quick skim and found a few minor things.
First, the subject might be mesa: implement GL_ARB_draw_indirect and
GL_ARB_multi_draw_indirect
This is a big patch and I think it could have been broken down into
smaller pieces, but I know it's a
On 05.04.2013 13:32, Christoph Bumiller wrote:
On 04.04.2013 21:17, Brian Paul wrote:
I just did a quick skim and found a few minor things.
First, the subject might be mesa: implement GL_ARB_draw_indirect and
GL_ARB_multi_draw_indirect
This is a big patch and I think it could have been
Intended for use with GL_ARB_draw_indirect's DRAW_INDIRECT_BUFFER
target or for D3D11_RESOURCE_MISC_DRAWINDIRECT_ARGS.
---
src/gallium/docs/source/screen.rst |3 +++
src/gallium/include/pipe/p_defines.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git
Split from patch implementing ARB_draw_indirect.
v2:
Const-qualify the struct gl_buffer_object *indirect argument.
---
src/mesa/drivers/dri/i965/brw_draw.c |3 ++-
src/mesa/drivers/dri/i965/brw_draw.h |3 ++-
src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c |9 ++---
---
src/mesa/state_tracker/st_cb_bufferobjects.c |3 +++
src/mesa/state_tracker/st_draw.c | 11 ++-
src/mesa/state_tracker/st_extensions.c |3 ++-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c
v2:
Removed some stray extern qualifiers.
Documented use of Draw*IndirectCommand sizes.
Removed separate extension enable flag for ARB_multi_draw_indirect
since this can always be supported by looping.
Kept generation of GL_INVALID_OPERATION in display list compile.
The spec doesn't say
v2:
Added comments to util_draw_indirect, clarified and fixed map size.
Removed unlikely().
---
src/gallium/auxiliary/util/u_draw.c | 43 ++
src/gallium/auxiliary/util/u_draw.h |8
src/gallium/auxiliary/util/u_dump_state.c|3 ++
v2:
Fix for constness of indirect buffer argument.
Remove separate extension enable for multi_draw_indirect.
---
src/mesa/state_tracker/st_cb_bufferobjects.c |3 +++
src/mesa/state_tracker/st_cb_bufferobjects.h |6 ++
src/mesa/state_tracker/st_draw.c | 11 ++-
(Will be merged into the original patches.)
Calculating the actual limits is impossible, and softpipe drops
vertices that lie outside the specified range.
---
src/gallium/auxiliary/util/u_draw.c |4
src/mesa/state_tracker/st_draw.c|3 +++
src/mesa/vbo/vbo_exec_array.c |
On 08.04.2013 12:03, Marek Olšák wrote:
On Mon, Apr 8, 2013 at 11:29 AM, Michel Dänzer mic...@daenzer.net
mailto:mic...@daenzer.net wrote:
On Fre, 2013-04-05 at 17:36 -0400, j.gli...@gmail.com
mailto:j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
On 12.04.2013 21:14, Kenneth Graunke wrote:
This provides an interface for applications (and OpenGL-based tools) to
access GPU performance counters. Since the exact performance counters
available vary between vendors and hardware generations, the extension
provides an API the application can
From: Christoph Bumiller christoph.bumil...@speed.at
This is the only sane solution for nv50 and nvc0 (really, trust me),
but since on other hardware the border colour is tightly coupled with
texture state they'd have to undo the swizzle, so I've added a cap.
The name of the cap could be changed
On 12.04.2013 21:14, Kenneth Graunke wrote:
This provides an interface for applications (and OpenGL-based tools) to
access GPU performance counters. Since the exact performance counters
available vary between vendors and hardware generations, the extension
provides an API the application can
You can merge this with the original UIF patch if you want.
---
.../drivers/nv50/codegen/nv50_ir_from_tgsi.cpp |7 ++-
.../drivers/nv50/codegen/nv50_ir_lowering_nv50.cpp |2 +-
.../drivers/nvc0/codegen/nv50_ir_lowering_nvc0.cpp |2 +-
3 files changed, 4 insertions(+), 7
On 14.04.2013 13:44, Jose Fonseca wrote:
- Original Message -
From: Christoph Bumiller christoph.bumil...@speed.at
This is the only sane solution for nv50 and nvc0 (really, trust me),
but since on other hardware the border colour is tightly coupled with
texture state they'd have
On 14.04.2013 13:50, Jose Fonseca wrote:
- Original Message -
Not to mention the sheer insanity, ugliness and emotional pain incurred
when writing that code when it COULD be so easy and simple in the state
tracker where you know that textures and samplers are tightly coupled,
while
On 14.04.2013 14:33, Christoph Bumiller wrote:
===
In the format description (including swizzle), each color component of
RGBA (as seen by the shader) gets mapped a memory component
{C0,C1,C2,C3} or {ZERO,ONE_INT,ONE_FLOAT}.
When a memory (!) component (Cx) is first encountered when going
From: Christoph Bumiller christoph.bumil...@speed.at
This is the only sane solution for nv50 and nvc0 (really, trust me),
but since on other hardware the border colour is tightly coupled with
texture state they'd have to undo the swizzle, so I've added a cap.
The dependency of update_sampler
On 19.04.2013 09:26, Jose Fonseca wrote:
- Original Message -
From: Roland Scheidegger srol...@vmware.com
docs were missing, especially the opcode-from-hell switch however is anything
but obvious.
---
src/gallium/docs/source/tgsi.rst | 57
++
On 19.04.2013 14:08, Marek Olšák wrote:
That's not true. PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE does not copy
data in radeon drivers. It really does what st/mesa does - it creates
a new buffer and throws away the old one, which doesn't take any GPU
bandwidth. Doing that at a lower level should
On 21.04.2013 09:36, Jose Fonseca wrote:
- Original Message -
Do we really need the lower_left_origin state? I think I can't
implement it for radeon and it's the kind of stuff that should be
taken care of by the state tracker anyway.
My understanding is that hardware had switches for
On 21.04.2013 12:34, Dave Airlie wrote:
On Sun, Apr 21, 2013 at 5:36 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Do we really need the lower_left_origin state? I think I can't
implement it for radeon and it's the kind of stuff that should be
taken care of by the
On 21.04.2013 13:18, Jose Fonseca wrote:
- Original Message -
On 21.04.2013 09:36, Jose Fonseca wrote:
- Original Message -
Do we really need the lower_left_origin state? I think I can't
implement it for radeon and it's the kind of stuff that should be
taken care of by the
On 21.04.2013 14:35, Jose Fonseca wrote:
- Original Message -
On 21.04.2013 13:18, Jose Fonseca wrote:
I think that drivers can just report all 4 CAPs as supported and do the
adjustment in the shader themselves (no need for recompilation, just use
uniforms, the st already does it
On 23.04.2013 18:28, Jose Fonseca wrote:
Ok. I've moved the docs to src/gallium/docs/source/cso/rasterizer.rst , and
renamed `lower_left_origin` to `bottom_edge_rule`.
Well, that doesn't work for NV, but it's at least less invasive for
radeon since you don't have to change the state tracker
On 25.04.2013 19:22, Roland Scheidegger wrote:
Am 24.04.2013 00:58, schrieb Zack Rusin:
There can be more stream output decls than shader outputs because
individual components from them can be split and distributed
among different so buffers.
Signed-off-by: Zack Rusin za...@vmware.com
---
On 03.05.2013 16:32, Jose Fonseca wrote:
- Original Message -
Am 03.05.2013 06:58, schrieb Jose Fonseca:
- Original Message -
Currently, there's no way to get the high bits of a 32x32
signed/unsigned integer multiplication with tgsi. However, all of
d3d10, OpenGL, and
On 07.05.2013 19:25, Bryan Cain wrote:
The Mesa state tracker expects us to emit the fence even if it doesn't call
fence_finish. Notably, this occurs when glClientWaitSync is called with
timeout 0.
Fixes Portal and Left 4 Dead 2, which were both stalling on startup by
repeatedly calling
On 08.05.2013 03:48, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
UCMP while an integer opcode isn't really consistently implemented as
having all integer arguments. softpipe will assume all arguments are
ints, whereas gallivm has the arguments defined as untyped
On 18.05.2013 13:05, Lauri Kasanen wrote:
Hi,
The 'net claims that instancing is a SM3 feature[1] (r500), but also
supported on SM2 ATI cards[2] (r300-r400).
Yet r300g claims no support for it, and it seems that even Nvidia's
r300_get_param:
case PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR:
in the driver ... the only
hardware support for instancing they added is a builtin counter.
Marek
On Sat, May 18, 2013 at 4:59 PM, Lauri Kasanen c...@gmx.com wrote:
On Sat, 18 May 2013 17:46:32 +0300
Lauri Kasanen c...@gmx.com wrote:
On Sat, 18 May 2013 13:50:35 +0200
Christoph Bumiller e0425
On 01.06.2013 01:02, Alex Deucher wrote:
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes
On 06.06.2013 10:34, Richard Sandiford wrote:
Michel Dänzer mic...@daenzer.net writes:
On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
(2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
mesa-like ones with msb first. (I'm happy to change the names to
On 12.06.2013 15:57, Jose Fonseca wrote:
- Original Message -
Am 11.06.2013 05:39, schrieb Zack Rusin:
There are strict limits on those registers. Define the maximums
and use them instead of magic numbers. Also allows us to add
some extra sanity checks.
Suggested by Brian.
On 22.06.2013 16:36, Roland Scheidegger wrote:
We decided to drop predicated transfers already. State tracker can
emulate this by using another resource and doing a (predicated)
resource_copy_region, might be slightly suboptimal but predicated
transfers really sound strange.
As for
From: Christoph Bumiller christoph.bumil...@speed.at
---
src/gallium/drivers/r600/evergreen_state.c | 10 --
src/gallium/drivers/r600/r600_state.c | 10 --
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src
On 11.07.2013 20:15, Marek Olšák wrote:
Hi Roland,
The fast color clear on Radeon doesn't touch the memory of the texture
resource. Instead, it changes some GPU meta data that say the resource
is cleared (the location of the meta data is stored in pipe_resource).
This works fine as long as
On 12.07.2013 01:26, Brian Paul wrote:
KILP is really unconditional fragment kill.
We've had KIL and KILP transposed forever. I'll fix that next.
I think the 'P' meant to indicate that the condition, if there is any,
would be a predicate register, whereas KIL no-P is supposed to represent
the
On 12.07.2013 16:06, Jose Fonseca wrote:
The tradition has been to use C suffix for conditional opcodes, instead of
_IF. That said, I don't feel too strongly either way.
Except the 'C' suffix usually (ok, we only have BREAKC) indicates a
single condition value where non-zero means true,
So, about two months ago I had the insane idea to pick up Joakim
Sindholt's Direct3D 9 state tracker that he'd started about 3 years ago
with the goal to make it run StarCraft 2 so I could finally play at a
reasonable frame rate ...
With help from Joakim and advice from the wine developers, as
On 17.07.2013 00:12, Grigori Goronzy wrote:
On 16.07.2013 19:26, Marek Olšák wrote:
Surprisingly all drivers supporting MSAA can already do this (r300g
and r600g
for sure) and I think Christoph wanted to have this feature for his
Nouveau
drivers anyway.
OK, they can do it, but is it
On 17.07.2013 02:05, Marek Olšák wrote:
No, it's not faster, but it's not slower either.
Now that I think about it, I can't come up with a good shader-based
algorithm for the resolve operation.
I don't think Christoph's approach that an MSAA texture can be viewed
as a larger single-sample
On 29.07.2013 08:03, Paul Berry wrote:
From: Bryan Cain bryanca...@gmail.com
v2 (Paul Berry stereotype...@gmail.com: Split out to separate patch
(previously this was part of glsl: add builtins for geometry
shaders.)
---
src/mesa/state_tracker/st_program.c | 7 +++
1 file changed, 7
On 06.08.2013 03:28, Kenneth Graunke wrote:
Many GLSL shaders contain code of the form:
x = condition ? foo : bar
The compiler emits an ir_if tree for this, since each subexpression
might be a complex tree that could have side-effects and short-circuit
logic operations.
However, the
101 - 200 of 317 matches
Mail list logo
