---
src/mesa/main/dlist.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index d901bdd..52548fd 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -69,6 +69,9 @@
#if
---
src/mesa/main/api_exec.c |1 +
src/mesa/main/transformfeedback.c | 10 +-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/api_exec.c b/src/mesa/main/api_exec.c
index 93214dd..1bc39db 100644
--- a/src/mesa/main/api_exec.c
+++
+++ b/src/glsl/ir_set_transform_feedback_outs.cpp
@@ -0,0 +1,299 @@
+/*
+ * Copyright © 2010 Intel Corporation
+ * Copyright © 2011 Marek Olšák mar...@gmail.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files
This series is:
Reviewed-by: Marek Olšák mar...@gmail.com
Thanks.
Marek
On Thu, Oct 27, 2011 at 1:46 AM, Eric Anholt e...@anholt.net wrote:
This is only used in the code for packing to INF, and resulted in an
extra bit set that was set anyway, so it was harmless except for the
confusion
If there are no other concerns, I'll push this on Saturday, including
the nv20 fix from Francisco Jerez.
http://cgit.freedesktop.org/~mareko/mesa/log/?h=nv-fog-distance
Marek
On Tue, Sep 20, 2011 at 7:50 AM, Nicholas Miell nmi...@gmail.com wrote:
On 09/19/2011 10:23 AM, Ian Romanick wrote:
I
From what I can see, the fog distance is computed per-vertex and
stored in the FogCoord vertex shader output. There is no fragment
shader change required. The fixed-function vertex program hasn't been
converted to the GLSL IR yet, only the fragment program, which is
irrelevant here.
Gallium only
Looks good to me. Ideally even texture_barrier should not be needed.
set_framebuffer_state() and flush() should flush caches automatically.
If they don't, there is a bug.
Marek
2011/10/27 Mathias Fröhlich mathias.froehl...@gmx.net:
Hi,
On Saturday, October 22, 2011 13:36:37 Mathias Fröhlich
I've got no idea what the flush was good for, but it's useless from
the looks of it. The rest of the patch is just a cleanup resulting
from some of the variables being no longer used for anything useful.
There are no piglit regressions.
---
src/gallium/drivers/r600/r600.h|6
On Fri, Oct 28, 2011 at 10:52 PM, Vadim Girlin vadimgir...@gmail.com wrote:
On Fri, 2011-10-28 at 19:47 +0200, Marek Olšák wrote:
I've got no idea what the flush was good for, but it's useless from
the looks of it. The rest of the patch is just a cleanup resulting
from some of the variables
On Sat, Oct 29, 2011 at 12:58 AM, Vadim Girlin vadimgir...@gmail.com wrote:
On Sat, 2011-10-29 at 01:29 +0400, Vadim Girlin wrote:
On Fri, 2011-10-28 at 23:16 +0200, Marek Olšák wrote:
On Fri, Oct 28, 2011 at 10:52 PM, Vadim Girlin vadimgir...@gmail.com
wrote:
On Fri, 2011-10-28 at 19:47
Hi everyone,
Here's what I think is complete GLSL linker code for EXT_transform_feedback.
What's missing in core Mesa is the implementation of
glGetTransformFeedbackVaryingEXT, but other than that I think we're all set.
The first patch is the Dan McCabe's patch with one bug fix.
The second
are already assigned
slots. A new function max_varying() is introduced to examine a
previously processed shader to find the largest varying already
assigned a slot. All new varyings will be assigned slots after
this one. If varyings are found, -1 is returned.
[ Marek Olšák: fix segfault
/glsl/ir_set_transform_feedback_outs.cpp
@@ -0,0 +1,268 @@
+/*
+ * Copyright © 2010 Intel Corporation
+ * Copyright © 2011 Marek Olšák mar...@gmail.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files
---
src/glsl/linker.cpp | 192 ++-
1 files changed, 174 insertions(+), 18 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index e6012bf..d5d50b5 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1615,49 +1615,170
The code expects the geometry shader to be NULL.
We don't have geometry shaders now, but it's good to be prepared.
---
src/gallium/auxiliary/util/u_blit.c | 25 +
src/gallium/auxiliary/util/u_gen_mipmap.c | 16
---
src/gallium/auxiliary/cso_cache/cso_context.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c
b/src/gallium/auxiliary/cso_cache/cso_context.c
index fdd40fc..b91fe1a 100644
---
The code expects the geometry shader to be NULL.
We don't have geometry shaders now, but it's good to be prepared.
v2: check for support in the cso context
---
src/gallium/auxiliary/cso_cache/cso_context.c | 17 -
src/gallium/auxiliary/util/u_blit.c |6 ++
FYI, this commit completely breaks RV670. glxgears is completely
black, other apps are either black or rendered incorrectly (mostly
one-colored, the clear color I guess).
Marek
On Fri, Nov 4, 2011 at 6:24 PM, Vadim Girlin vadimgir...@gmail.com wrote:
There is no need to duplicate semantic
Hi Paul,
I won't comment on the patch 1, because I didn't write it, I was just
preserving history.
On Fri, Nov 4, 2011 at 10:00 PM, Paul Berry stereotype...@gmail.com wrote:
[snip]
+bool parse_tfeedback_decl(const void *mem_ctx, const char *input,
+ struct
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 new parameter
struct
---
src/mesa/main/version.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 17c0600..49cdc30 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -124,9 +124,11 @@ compute_version(struct
idea?
Stéphane
On Sun, Oct 23, 2011 at 11:33, Marek Olšák
mar...@kemper.freedesktop.org wrote:
Module: Mesa
Branch: master
Commit: 37b62cc35435a704d33c1814fbdbd0e807699e21
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=37b62cc35435a704d33c1814fbdbd0e807699e21
Author: Marek Olšák
On Tue, Nov 8, 2011 at 1:13 AM, Paul Berry stereotype...@gmail.com wrote:
+/**
+ * Update gl_transform_feedback_info to reflect this tfeedback_decl.
+ *
+ * If an error occurs, the error is reported through linker_error() and false
+ * is returned.
+ */
+bool
+tfeedback_decl::store(struct
On Tue, Nov 8, 2011 at 1:13 AM, Paul Berry stereotype...@gmail.com wrote:
@@ -1806,16 +2187,50 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
break;
}
+ /* From GL_EXT_transform_feedback:
+ * A program will fail to link if:
+ *
+ * * the
, this patch is:
Reviewed-by: Marek Olšák mar...@gmail.com
Tested-by: Marek Olšák mar...@gmail.com
Marek
+ }
+ }
+ return true;
+}
+
+
+/**
+ * Assign a location for a variable that is produced in one pipeline stage
+ * (the producer) and consumed in the next stage (the consumer
Hi vlj,
just one remark unrelated to the patch.
The commit messages should start with a 76-characters-long summary,
followed by an empty line, and then followed by a more thorough
explanation if needed.
Marek
On Sat, Nov 12, 2011 at 10:11 PM, vlj v...@ovi.com 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 GL_NV_gpu_program4 has typeless
registers too). I think
Hi Vadim,
Shouldn't this be in the pipe_shader_cap enum instead?
Marek
On Mon, Nov 14, 2011 at 1:57 PM, Vadim Girlin vadimgir...@gmail.com wrote:
It's intended to indicate whether the driver/hardware supports reading
of the values written into shader outputs.
Also remove assert to allow
On Mon, Nov 14, 2011 at 2:49 PM, Vadim Girlin vadimgir...@gmail.com wrote:
On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote:
- Original Message -
Hi,
I found some problem with glsl_to_tgsi: remove_output_reads function.
It's replacing outputs with temps, producing incorrect
On Tue, Nov 15, 2011 at 9:27 AM, Ian Romanick i...@freedesktop.org wrote:
I guess I don't follow. Different hardware can do different things, and the
code for that hardware will look different. What's the problem?
Well, I guess you're right. We already make the GLSL compiler do
different
---
src/glsl/ast_to_hir.cpp |7 +--
src/glsl/glsl_lexer.ll |1 +
src/glsl/glsl_parser.yy |9 -
src/glsl/ir_clone.cpp |1 +
4 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index ac090c3..51fec19 100644
---
src/glsl/linker.cpp| 45
src/mesa/main/mtypes.h |3 ++
src/mesa/program/ir_to_mesa.cpp| 29 --
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 23 --
4 files changed, 54
This adds a new TGSI property to represent the GLSL layout qualifier in TGSI.
---
src/gallium/auxiliary/tgsi/tgsi_dump.c |1 +
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 16
src/gallium/auxiliary/tgsi/tgsi_ureg.h |5 +
Only i965g does not enable GLSL, but that driver has been unmaintained and
bitrotting for quite a while anyway.
---
src/gallium/auxiliary/util/u_caps.c|1 -
src/gallium/docs/source/screen.rst |1 -
src/gallium/drivers/cell/ppu/cell_screen.c |2 -
---
src/gallium/include/pipe/p_defines.h |3 ++-
src/mesa/state_tracker/st_extensions.c |5 +
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 3e55d22..e51132a 100644
---
The spec says GL3 is required, but technically the extension only needs
the 'out' modifier from GLSL 1.3.
---
src/mesa/state_tracker/st_extensions.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
Please disregard this patch and the last one too. GLSL 1.3 in st/mesa
is not as complete and usable as I thought.
Marek
On Fri, Nov 18, 2011 at 8:27 PM, Marek Olšák mar...@gmail.com wrote:
---
src/gallium/include/pipe/p_defines.h | 3 ++-
src/mesa/state_tracker/st_extensions.c | 5
On Fri, Nov 18, 2011 at 10:14 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On 11/18/2011 11:27 AM, Marek Olšák wrote:
diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index e8ac9fb..c63615c 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@ -51,6 +51,7
On Fri, Nov 18, 2011 at 9:44 PM, Ian Romanick i...@freedesktop.org wrote:
On 11/18/2011 11:27 AM, Marek Olšák wrote:
---
src/glsl/linker.cpp | 45
src/mesa/main/mtypes.h | 3 ++
src/mesa/program/ir_to_mesa.cpp
On Fri, Nov 18, 2011 at 9:44 PM, Ian Romanick i...@freedesktop.org wrote:
On 11/18/2011 11:27 AM, Marek Olšák wrote:
This patch also needs to change the _mesa_glsl_supported_extensions table in
glsl_parser_extras.cpp. AMD_conservative_depth is used for both versions of
the extension
---
src/glsl/glcpp/glcpp-parse.y|2 +-
src/glsl/glsl_parser_extras.cpp |4 ++--
src/mesa/main/extensions.c |4 ++--
src/mesa/main/mtypes.h |2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-parse.y
---
src/glsl/glsl_parser_extras.cpp |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 53ce881..0b4ccac 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -256,7
. I didn't look at what needs to be done to support the new one.
Please review.
Marek Olšák (8):
mesa: implement DrawTransformFeedback from ARB_transform_feedback2
gallium: disable stream output in drivers that support it
gallium: interface changes necessary to implement transform feedback
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/softpipe/sp_screen.c |
Namely:
- EXT_transform_feedback
- ARB_transform_feedback2
- ARB_transform_feedback_instanced
The old interface was not useful for OpenGL and had to be reworked.
This interface was originally designed for OpenGL, but additional
changes have been made in order to make st/d3d1x support easier.
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c|7 ++-
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 ++
---
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
---
---
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
b/src/gallium/auxiliary/util/u_blitter.c
index
---
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
b/src/gallium/auxiliary/util/u_blitter.c
index
/state_tracker/st_cb_xformfb.c
b/src/mesa/state_tracker/st_cb_xformfb.c
index a17b54d..2fc28dc 100644
--- a/src/mesa/state_tracker/st_cb_xformfb.c
+++ b/src/mesa/state_tracker/st_cb_xformfb.c
@@ -30,70 +30,122 @@
* Transform feedback functions.
*
* \author Brian Paul
+ * Marek Olšák
The motivation behind this is to add some self-documentation in the code
about how each CAP can be used.
The idea is:
- enum pipe_cap is only valid in get_param
- enum pipe_cap_float is only valid in get_paramf
Which CAPs are floating-point have been determined based on how everybody
except svga
unpack_float_z_Z24_X8 fails with -O2 in:
- fbo-blit-d24s8
- fbo-depth-sample-compare
- fbo-readpixels-depth-formats
- glean/depthStencil
With -O0, it works fine.
I am removing all the assertions. There's not much point in having them,
is there?
---
src/mesa/main/format_unpack.c |8
This fixes:
- depthstencil-default_fb-copypixels
- fbo-depthstencil-GL_DEPTH24_STENCIL8-copypixels
---
src/mesa/state_tracker/st_cb_drawpixels.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
---
src/glsl/linker.cpp | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 3527088..8089255 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2230,8 +2230,28 @@ link_shaders(struct gl_context
On Mon, Nov 21, 2011 at 1:06 AM, Kenneth Graunke kenn...@whitecape.org wrote:
On 11/20/2011 01:15 PM, Marek Olšák wrote:
---
src/glsl/linker.cpp | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index
On Mon, Nov 21, 2011 at 9:53 AM, Jose Fonseca jfons...@vmware.com wrote:
I think that PIPE_CAP_FLOAT_XXX is too long and that the non-abbreviated
_FLOAT_ word is distracting and misleading, as it sounds like it's related
with floating point features, which is not. Something more subtle, such
Thanks for looking into this, Ian.
Acked-by: Marek Olšák mar...@gmail.com
On Mon, Nov 21, 2011 at 8:51 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
The old count_uniform_size::num_shader_uniforms was actually
calculating the number of components
The linker now adds color varyings to the number of used varyings and checks
against that limit.
---
src/mesa/state_tracker/st_extensions.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
These are different from hardware limits, because some drivers can correctly
handle higher values than they report in most cases, either due
to driver-specific compiler optimizations, or due to just how the hardware
works internally.
The problem with the linker is that it artifically reduces
On Mon, Nov 21, 2011 at 7:54 PM, Ian Romanick i...@freedesktop.org wrote:
NAK with extreme prejudice. Technically speaking, these are app bugs. I
absolutely will not disable all correct behavior to work around broken apps.
You are picturing a perfect world that doesn't exist. The world
doesn't
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca jfons...@vmware.com wrote:
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface changes:
- e.g., provide to GLSL compiler infinite/huge limits, while advertising to
the app the
On Tue, Nov 22, 2011 at 6:04 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca jfons...@vmware.com
wrote:
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium
On Mon, Nov 21, 2011 at 8:01 PM, Ian Romanick i...@freedesktop.org wrote:
On 11/19/2011 07:42 AM, Marek Olšák wrote:
On Fri, Nov 18, 2011 at 9:44 PM, Ian Romanicki...@freedesktop.org wrote:
On 11/18/2011 11:27 AM, Marek Olšák wrote:
This patch also needs to change
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43122
---
src/mesa/main/format_unpack.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 6e2ce7a..52f224a 100644
---
On Tue, Nov 22, 2011 at 9:13 PM, Patrick Baggett
baggett.patr...@gmail.com wrote:
On Tue, Nov 22, 2011 at 2:07 PM, Marek Olšák mar...@gmail.com wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43122
---
src/mesa/main/format_unpack.c | 10 ++
1 files changed, 10
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick i...@freedesktop.org wrote:
All of this discussion is largely moot. The failure that you're so angry
about was caused by a bug in the check, not by the check itself. That bug
has already been fixed (commit 151867b).
The exact same check was
On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke kenn...@whitecape.org wrote:
On 11/22/2011 07:27 PM, Marek Olšák wrote:
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick i...@freedesktop.org wrote:
All of this discussion is largely moot. The failure that you're so angry
about was caused
On Wed, Nov 23, 2011 at 7:25 PM, Ian Romanick i...@freedesktop.org wrote:
Let me paraphrase this a little bit in a way that I think concisely captures
the intention:
We need to work really hard to make things work on older hardware.
I don't think anyone disagrees with that. However, the
On Fri, Nov 25, 2011 at 1:46 AM, Kenneth Graunke kenn...@whitecape.org wrote:
another, no driver should be crippled ever. I know you couldn't care
less about anything except your driver, but there are people who care.
Marek
I'm honestly shocked to read this, Marek. We deliberately want
On Mon, Nov 28, 2011 at 12:08 AM, Ian Romanick i...@freedesktop.org wrote:
In Mesa, we have four drivers that advertise 4096 uniform components on some
combinations of hardware: i915, i915g, nouveau, and r300g. By putting
resource counting in the driver we have the potential for shaders to
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 doesn't change any driver besides Gallium. Please review,
especially the part in
On Sat, Dec 10, 2011 at 8:19 PM, Ian Romanick i...@freedesktop.org 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
On Mon, Nov 21, 2011 at 6:52 PM, Eric Anholt e...@anholt.net wrote:
On Sun, 20 Nov 2011 15:08:55 +0100, Marek Olšák mar...@gmail.com wrote:
unpack_float_z_Z24_X8 fails with -O2 in:
- fbo-blit-d24s8
- fbo-depth-sample-compare
- fbo-readpixels-depth-formats
- glean/depthStencil
With -O0
---
src/mesa/program/prog_print.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c
index e9bf3aa..b4d142f 100644
--- a/src/mesa/program/prog_print.c
+++ b/src/mesa/program/prog_print.c
@@ -112,6 +112,7 @@
This is only temporary until a better solution is available.
v2: print warnings and add gallium CAPs
---
src/gallium/drivers/r300/r300_screen.c |2 +
src/gallium/include/pipe/p_defines.h |4 ++-
src/glsl/linker.cpp| 43 ---
On Mon, Dec 12, 2011 at 1:24 PM, Jose Fonseca jfons...@vmware.com wrote:
I saw this email yesterday, but did not have time to reply.
- Original Message -
On Mon, Nov 21, 2011 at 6:52 PM, Eric Anholt e...@anholt.net wrote:
On Sun, 20 Nov 2011 15:08:55 +0100, Marek Olšák mar
at 6:52 PM, Eric Anholt e...@anholt.net
wrote:
On Sun, 20 Nov 2011 15:08:55 +0100, Marek Olšák
mar...@gmail.com
wrote:
unpack_float_z_Z24_X8 fails with -O2 in:
- fbo-blit-d24s8
- fbo-depth-sample-compare
- fbo-readpixels-depth-formats
- glean/depthStencil
With -O0
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 this and see how output mask is being
---
src/gallium/drivers/r300/r300_screen.c |3 ++-
src/gallium/include/pipe/p_defines.h |3 ++-
src/glsl/linker.cpp|6 ++
src/mesa/main/mtypes.h |9 +
src/mesa/state_tracker/st_extensions.c |3 +++
5 files changed, 22
---
src/glsl/linker.cpp |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index e9298bb..1086ef7 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1811,6 +1811,13 @@ assign_varying_locations(struct gl_context
The strides are useful, although they can be computed by summing up
all the NumComponents fields for each buffer. Note that I also take
into account ARB_transform_feedback3, which allows having interleaved
attribs in more than one buffer. For the EXT_transform_feedback case
and separate attribs,
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Wed, Dec 14, 2011 at 6:00 PM, Paul Berry stereotype...@gmail.com wrote:
This patch adds two new fields to the gl_transform_feedback_info
struct:
- BufferStride records the total number of components (per vertex)
that transform feedback
I think RASTERIZER_DISCARD has nothing to do with transform feedback.
I think it's part of the same spec because it's not useful without it.
As I understand it, _NEW_TRANSFORM_FEEDBACK is dirty when transform
feedback buffer bindings are changed or just enabled/disabled. On the
other hand,
On Wed, Dec 14, 2011 at 6:30 PM, Ian Romanick i...@freedesktop.org wrote:
On 12/13/2011 04:32 PM, Marek Olšák wrote:
---
src/gallium/drivers/r300/r300_screen.c | 3 ++-
src/gallium/include/pipe/p_defines.h | 3 ++-
src/glsl/linker.cpp | 6 ++
src/mesa/main
On Wed, Dec 7, 2011 at 8:09 PM, Paul Berry stereotype...@gmail.com wrote:
This patch adds a new bit to the ctx-NewState bitfield,
_NEW_TRANSFORM_FEEDBACK, to track state changes that affect
ctx-TransformFeedback. This bit can be used by driver back-ends to
avoid expensive recomputations when
On Wed, Dec 14, 2011 at 11:25 PM, Paul Berry stereotype...@gmail.com wrote:
On 14 December 2011 13:42, Marek Olšák mar...@gmail.com wrote:
I think RASTERIZER_DISCARD has nothing to do with transform feedback.
I think it's part of the same spec because it's not useful without it.
As I
On Thu, Dec 15, 2011 at 12:18 AM, Paul Berry stereotype...@gmail.com wrote:
On 14 December 2011 15:00, Marek Olšák mar...@gmail.com wrote:
On Wed, Dec 14, 2011 at 11:25 PM, Paul Berry stereotype...@gmail.com
wrote:
On 14 December 2011 13:42, Marek Olšák mar...@gmail.com wrote:
I think
Reviewed-by: Marek Olšák mar...@gmail.com
Thanks!
Marek
On Fri, Dec 16, 2011 at 11:06 PM, Paul Berry stereotype...@gmail.com wrote:
It isn't necessary to call FLUSH_VERTICES from bind_buffer_range,
because transform feedback buffers are not allowed to be changed when
transform feedback
From ARB_transform_feedback2:
... the vertex count used for the rendering operation is
set by the previous EndTransformFeedback command.
---
src/mesa/state_tracker/st_cb_xformfb.c | 53 +--
1 files changed, 42 insertions(+), 11 deletions(-)
diff --git
---
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 --
2 files changed, 13
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/archives/mesa-dev/2010-August/001810.html
src
It's the same as PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS.
---
src/gallium/drivers/nvc0/nvc0_screen.c |2 --
src/gallium/drivers/r300/r300_screen.c |1 -
src/gallium/drivers/r600/r600_pipe.c |1 -
src/gallium/include/pipe/p_defines.h |1 -
src/mesa/state_tracker/st_extensions.c |
2011/12/19 Mathias Fröhlich mathias.froehl...@gmx.net:
Brian,
On Monday, December 19, 2011 17:01:07 you wrote:
I still don't get what the purpose of the special mapping of the last
four/five elements is all about. Can you explain that?
As far as I can see the last ones should not map to
On Thu, Dec 15, 2011 at 7:21 PM, Paul Berry stereotype...@gmail.com wrote:
On 15 December 2011 08:02, Eric Anholt e...@anholt.net wrote:
On Thu, 15 Dec 2011 00:00:49 +0100, Marek Olšák mar...@gmail.com wrote:
On Wed, Dec 14, 2011 at 11:25 PM, Paul Berry stereotype...@gmail.com
wrote:
(c
Hi Brian,
Is there a reason to set _NEW_ARRAY when transitioning between
DrawArrays and DrawElements?
Marek
On Wed, Dec 21, 2011 at 1:58 AM, Brian Paul bri...@vmware.com wrote:
This fixes a regression seen with the isosurf demo when switching between
glBegin/End and glDrawArrays (do it
For the series:
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Wed, Dec 21, 2011 at 1:41 AM, Paul Berry stereotype...@gmail.com wrote:
This makes it easier to keep track of which dirty bits correspond to
which pieces of context, since it makes _NEW_RASTERIZER_DISCARD
correspond with ctx
On Fri, Dec 23, 2011 at 4:22 AM, Paul Berry stereotype...@gmail.com wrote:
FYI, this assertion should hold true until we implement
ARB_transfrom_feedback3 (which allows holes in the transform feedback
structure). I think Marek has some plans to implement that for Gallium (not
sure of his
2011/12/20 Mathias Fröhlich mathias.froehl...@gmx.net:
Ok, back to topic, so have I understood right? You have fixed torcs not to use
the slow path anymore? Which old version is the one still having this issue?
I did not fix Torcs. I think optimizing apps is useless if the same
optimization can
Hi everyone,
There is a new branch gallium-clip-state in the main Mesa repository.
It implements the changes we agreed upon, i.e. moving state enables
from clip_state into rasterizer_state. A nice cleanup comes with it:
cso_save_clip and cso_restore_clip are no longer needed anywhere.
There is
Reviewed-by: Marek Olšák mar...@gmail.com
On Thu, Dec 29, 2011 at 6:16 PM, Paul Berry stereotype...@gmail.com wrote:
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src
1 - 100 of 12096 matches
Mail list logo
