Fixes broken rendering if these MRFs contained anything other than zero.
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
Sorry, saw the bogus comment style just after I sent this out.
-- Chris
On Tue, Aug 27, 2013 at 9:45 PM, Chris Forbes chr...@ijw.co.nz wrote:
Fixes broken rendering if these MRFs contained anything other than zero.
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes
- Original Message -
On 08/26/2013 02:38 AM, Dave Airlie wrote:
Hi TGSI guys mostly :-)
So I'm wondering how circular and perfect tgsi-text-tgsi roundabouts
should be,
Ideally, they should be consistent.
currently the TGSI dump code uses .4f in one place, which makes
https://bugs.freedesktop.org/show_bug.cgi?id=68262
--- Comment #2 from Fabio Pedretti fabio@libero.it ---
Confirming the same error with 1.1.0.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
On 08/26/2013 07:17 PM, Timothy Arceri wrote:
V2: fixed spelling typo in comment
Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
---
src/mesa/main/errors.c | 275 -
src/mesa/main/errors.h | 5 +
src/mesa/main/mtypes.h | 5 +-
3 files
On 08/26/2013 07:10 PM, Timothy Arceri wrote:
On 27/08/13 00:51, Brian Paul wrote:
On 08/26/2013 04:43 AM, Timothy Arceri wrote:
Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
---
src/mesa/main/hash.c | 26 ++
src/mesa/main/hash.h |3 +++
2 files
https://bugs.freedesktop.org/show_bug.cgi?id=68262
Fabio Pedretti fabio@libero.it changed:
What|Removed |Added
Summary|[build error with wayland |[build error with
From: Tom Stellard thomas.stell...@amd.com
When adding a new buffer to the beginning of the memory pool, we were
accidentally deleting the buffer that was first in the buffer list.
This was caused by a bug in the memory pool's linked list
implementation.
---
On 08/21/2013 05:57 PM, Dominik Behr wrote:
Fixes a bug where if an uniform array is passed to a function the accesses
to the array are not propagated so later all but the first vector of the
uniform array are removed in parcel_out_uniform_storage resulting in
broken shaders and out of bounds
On 08/27/2013 02:47 AM, Chris Forbes wrote:
Sorry, saw the bogus comment style just after I sent this out.
-- Chris
On Tue, Aug 27, 2013 at 9:45 PM, Chris Forbes chr...@ijw.co.nz wrote:
Fixes broken rendering if these MRFs contained anything other than zero.
NOTE: This is a candidate for
On 08/12/2013 04:48 AM, Fabio Pedretti wrote:
Since 8d29b52 wayland 1.2.0 is required.
Thanks. Committed to master.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=68262
Fabio Pedretti fabio@libero.it changed:
What|Removed |Added
Status|NEW |RESOLVED
GLSL 1.30 doesn't allow precision qualifiers on sampler types,
but in GLSL ES, sampler types are also allowed. This seems like
an oversight (since the intention of including these in GLSL 1.30
is to allow compatibility with ES shaders).
Currently, Mesa allows default precision qualifiers to be
We need to export at least one color if the shader writes it,
even when nr_cbufs==0.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
Tested on evergreen with multiple combinations of backends - no regressions,
fixes some tests:
default- fixes fb-alphatest-nocolor and
On 08/27/2013 10:45 AM, Anuj Phogat wrote:
GLSL 1.30 doesn't allow precision qualifiers on sampler types,
but in GLSL ES, sampler types are also allowed. This seems like
an oversight (since the intention of including these in GLSL 1.30
is to allow compatibility with ES shaders).
Currently, Mesa
Not that I'm qualified to review r600 code, but couldn't you create
different shader variants depending on whether you need alpha test? At
least I would assume shader exports aren't free.
Roland
Am 27.08.2013 19:56, schrieb Vadim Girlin:
We need to export at least one color if the shader writes
On Mon, Aug 26, 2013 at 8:59 PM, Marko Ristola
marko.rist...@kolumbus.fi wrote:
Hi
15.08.2013 13:54, Marek Olšák wrote:
On Thu, Aug 15, 2013 at 10:27 AM, Christian König
deathsim...@vodafone.de wrote:
Am 15.08.2013 05:25, schrieb Marek Olšák:
(This should be applied before MSAA, which
On Tue, Aug 27, 2013 at 11:53 AM, Ian Romanick i...@freedesktop.org wrote:
On 08/27/2013 10:45 AM, Anuj Phogat wrote:
GLSL 1.30 doesn't allow precision qualifiers on sampler types,
but in GLSL ES, sampler types are also allowed. This seems like
an oversight (since the intention of including
Shader variants are BAD, BAD, BAD. Have you ever played an AAA game
with a Mesa driver that likes to compile shader variants on first use?
It's HORRIBLE.
What the patch does is probably the right solution. At least
alpha-test state changes don't cause shader recompilation and
re-binding, which
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Tue, Aug 27, 2013 at 3:05 AM, Tom Stellard t...@stellard.net wrote:
From: Tom Stellard thomas.stell...@amd.com
This is the state tracker's responsibility.
---
src/gallium/drivers/r600/evergreen_compute.c | 11 +--
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=50482
Henry henry_rosario_gonza...@hotmail.com changed:
What|Removed |Added
Resolution|FIXED |WORKSFORME
--
Hi,
There was a lot of code everywhere that used iterators so it is not obvious
for a new person that the iterators are evil. And they do abstract the
implementation of the storage.
Also, I'd rather use ir_instruction and as_*() calls instead of exec_node
and explicit cast.
I am not sure about
On 26 August 2013 17:49, Ian Romanick i...@freedesktop.org wrote:
On 08/23/2013 02:02 PM, Paul Berry wrote:
On 23 August 2013 13:19, Matt Turner matts...@gmail.com
mailto:matts...@gmail.com wrote:
On Fri, Aug 23, 2013 at 8:55 AM, Paul Berry stereotype...@gmail.com
On 26 August 2013 22:00, Matt Turner matts...@gmail.com wrote:
Thanks Paul.
I've placed this patch as 2.5/15 in the series.
i965/fs: Assert that ir_expressions are usable by 3-src instructions
MAD will be generated directly from ir_triop_fma, so this assertion
checks that all
On 08/27/2013 11:00 PM, Roland Scheidegger wrote:
Not that I'm qualified to review r600 code, but couldn't you create
different shader variants depending on whether you need alpha test? At
least I would assume shader exports aren't free.
I thought about performance, but my main concern now is
On 08/28/2013 12:43 AM, Marek Olšák wrote:
Shader variants are BAD, BAD, BAD. Have you ever played an AAA game
with a Mesa driver that likes to compile shader variants on first use?
It's HORRIBLE.
I don't think that shader variants are bad, but it's definitely bad when
we are compiling
On Mon, Aug 26, 2013 at 5:49 PM, Ian Romanick i...@freedesktop.org wrote:
On 08/23/2013 02:02 PM, Paul Berry wrote:
On 23 August 2013 13:19, Matt Turner matts...@gmail.com
mailto:matts...@gmail.com wrote:
On Fri, Aug 23, 2013 at 8:55 AM, Paul Berry stereotype...@gmail.com
Francisco Jerez curroje...@riseup.net writes:
Ian Romanick i...@freedesktop.org writes:
On 08/26/2013 01:10 PM, Francisco Jerez wrote:
[...]
The thing is that defining bitwise operators separately for each enum
type, as this patch and the macro solution do, doesn't stop the compiler
From
Use `(void) success;` to silence this warning:
i965/brw_vs.c:481:12:
warning: unused variable 'success' [-Wunused-variable]
bool success = do_vs_prog(brw, ctx-Shader.CurrentVertexProgram,
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
On Tue, Aug 27, 2013 at 2:03 PM, Dominik Behr db...@chromium.org wrote:
I am not sure about MAX2, is it guaranteed to be converted to branchless
conditional assignment?
I don't think there's a guarantee, no. Using MAX2 just makes the code
easier to immediately understand.
On 18 July 2013 10:30, Matt Turner matts...@gmail.com wrote:
On Sat, May 25, 2013 at 4:33 AM, Fabian Bieler fabianbie...@fastmail.fm
wrote:
When validating draw parameters move check for 0 draw count last
(drawing with count 0 is not an error), so that other parameters (e.g.:
the
This was already happening because blorp happens to flush at the end of
every call, but we have been talking about removing that at some point,
and this would surely get overlooked.
v2 (Kenneth Graunke): Rebase on latest master. Note that we did remove
the other flush, and this change
v2 (Kenneth Graunke): Rebase on latest master.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_context.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_context.c
intel_flush() now did nothing except call through (and
intel_batchbuffer_flush() does the no-op check, too!)
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 4 +---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 2 +-
src/mesa/drivers/dri/i965/intel_context.c| 17
This gives us more information about why we're flushing that we can
use for handling our throttling.
v2 (Kenneth Graunke): Rebase on latest master, add missing
FLUSH_VERTICES and FLUSH_CURRENT, which fixes a regression in Glean's
polygonOffset test.
v3 (anholt): Drop FLUSH_CURRENT --
These are things that happen to be occurring because of the batch flush at
the start of the blorp op (which exists to prevent batch space or aperture
space overflow), but the intention was for this sequence of state resets at
the end of blorp to be everything necessary for the next draw call.
The code that got replaced with map_raw didn't do the flush, but now
map_raw() is responsible for it and we don't have to worry about it.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
This brings over the batch-wrap-prevention and aperture space checking
code from the normal brw_draw.c path, so that we don't need to flush the
batch every time.
There's a risk here if the intel_emit_post_sync_nonzero_flush() call isn't
high enough up in the state emit sequences -- before, we
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index f8cf96f..5f8041f 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
On Tuesday 27 August 2013, Timothy Arceri wrote:
V2: fixed indentation of comment
Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
---
src/mesa/main/objectlabel.c | 277
src/mesa/main/objectlabel.h | 61 ++
2 files changed, 338
Am 27.08.2013 23:52, schrieb Vadim Girlin:
On 08/28/2013 12:43 AM, Marek Olšák wrote:
Shader variants are BAD, BAD, BAD. Have you ever played an AAA game
with a Mesa driver that likes to compile shader variants on first use?
It's HORRIBLE.
I don't think that shader variants are bad, but
https://bugs.freedesktop.org/show_bug.cgi?id=60737
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Status|NEW |RESOLVED
First, you won't really see any significant continual difference in
frame rate no matter how many shader variants you have unless you are
very CPU-bound. The problem is shader compilation on the first use,
that's where you get a big hiccup. Try Skyrim for example: You have to
first look around and
TC can be used for writing and therefore should be flushed.
---
src/gallium/drivers/radeonsi/r600_hw_context.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/r600_hw_context.c
b/src/gallium/drivers/radeonsi/r600_hw_context.c
index
Please disregard this patch. I didn't mean to send this one.
Marek
On Wed, Aug 28, 2013 at 1:00 AM, Marek Olšák mar...@gmail.com wrote:
TC can be used for writing and therefore should be flushed.
---
src/gallium/drivers/radeonsi/r600_hw_context.c | 8 +---
1 file changed, 5
There are drivers not using these optional stages.
Broken by a3ae5dc7dd5c2f8893f86a920247e690e550ebd4.
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/auxiliary/draw/draw_context.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On 08/28/2013 02:28 AM, Roland Scheidegger wrote:
Am 27.08.2013 23:52, schrieb Vadim Girlin:
On 08/28/2013 12:43 AM, Marek Olšák wrote:
Shader variants are BAD, BAD, BAD. Have you ever played an AAA game
with a Mesa driver that likes to compile shader variants on first use?
It's HORRIBLE.
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mesa 9.2 has been released! Mesa 9.2 is a feature release that includes
many updates and enhancements. The full list is available in the release
notes file in docs/relnotes/9.2.html.
The tag in the GIT repository for Mesa 9.2 is 'mesa-9.2'.
Mesa 9.2
On Wed, Jul 24, 2013 at 10:02:22AM -0700, Kenneth Graunke wrote:
On 07/24/2013 09:33 AM, Paul Berry wrote:
Two callers of brw_search_cache() weren't initializing that function's
inout_offset parameter: brw_blorp_const_color_params::get_wm_prog()
and brw_blorp_const_color_params::get_wm_prog().
On 08/27/2013 03:21 PM, Eric Anholt wrote:
intel_flush() now did nothing except call through (and
intel_batchbuffer_flush() does the no-op check, too!)
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 4 +---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 2 +-
On 08/28/2013 02:59 AM, Marek Olšák wrote:
First, you won't really see any significant continual difference in
frame rate no matter how many shader variants you have unless you are
very CPU-bound. The problem is shader compilation on the first use,
that's where you get a big hiccup. Try Skyrim
On 08/27/2013 03:11 PM, Chad Versace wrote:
Use `(void) success;` to silence this warning:
i965/brw_vs.c:481:12:
warning: unused variable 'success' [-Wunused-variable]
bool success = do_vs_prog(brw, ctx-Shader.CurrentVertexProgram,
Signed-off-by: Chad Versace
On 27 August 2013 16:51, Damien Lespiau damien.lesp...@intel.com wrote:
On Wed, Jul 24, 2013 at 10:02:22AM -0700, Kenneth Graunke wrote:
On 07/24/2013 09:33 AM, Paul Berry wrote:
Two callers of brw_search_cache() weren't initializing that function's
inout_offset parameter:
https://bugs.freedesktop.org/show_bug.cgi?id=50482
Jos van Wolput wol...@onsneteindhoven.nl changed:
What|Removed |Added
OS|Solaris |Linux (All)
On 28/08/13 08:25, Fredrik Höglund wrote:
On Tuesday 27 August 2013, Timothy Arceri wrote:
V2: fixed indentation of comment
Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
---
src/mesa/main/objectlabel.c | 277
src/mesa/main/objectlabel.h |
V2: const qualify table parameter
Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
---
src/mesa/main/hash.c | 28
src/mesa/main/hash.h |3 +++
2 files changed, 31 insertions(+)
diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
index 6591af9..b31fd48
On 08/27/2013 06:21 PM, Paul Berry wrote:
On 27 August 2013 16:51, Damien Lespiau damien.lesp...@intel.com wrote:
On Wed, Jul 24, 2013 at 10:02:22AM -0700, Kenneth Graunke wrote:
On 07/24/2013 09:33 AM, Paul Berry wrote:
Two callers of brw_search_cache() weren't initializing
LIBGL_SHOW_FPS=1 makes GLX print FPS every second while other values do
nothing. Extend it so that LIBGL_SHOW_FPS=N will print the FPS every N
seconds.
---
src/glx/dri2_glx.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
Hi,
I am looking at the code in lower_clip_distance.cpp
ir_visitor_status
lower_clip_distance_visitor::visit_leave(ir_call *ir)
{
void *ctx = ralloc_parent(ir);
const exec_node *formal_param_node = ir-callee-parameters.head;
const exec_node *actual_param_node =
V3: make sure to add null terminator when setting label,
generate error when the client specifies an explicit
length that exceeds MAX_LABEL_LENGTH, set label pointer
to NULL when freed, and output correct length in
MAX_LABEL_LENGTH error message.
V2: fixed indentation of comment
Signed-off-by:
+ }
+
+ if (label) {
+ /* set new label string */
+
+ if (length = 0) {
+ /* explicit length */
+ *labelPtr = (char *) malloc(length);
+ if (*labelPtr) {
+memcpy(*labelPtr, label, length);
+ }
The length given by the client is not
IMM[0] FLT32 { 0x, 0x, 0x, 0x } # 1.0, 3.0, 2.0, 4.0
If you use %.9g instead of %.4f then floating point numbers will be
preserved without loss of precision.
I see a -nan in my tests that doesn't get reparsed so I expect hex is
still better.
oops to list as well this
On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie airl...@gmail.com wrote:
IMM[0] FLT32 { 0x, 0x, 0x, 0x } # 1.0, 3.0, 2.0, 4.0
If you use %.9g instead of %.4f then floating point numbers will be
preserved without loss of precision.
I see a -nan in my tests that doesn't get
63 matches
Mail list logo
