This looks good. One minor nit: zwritemask should be in
r600_db_misc_state instead of r600_context.
Marek
On Fri, Feb 22, 2013 at 5:20 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
This work around disable hyperz if write to zbuffer is disabled. Somehow
using hyperz
For the series:
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Fri, Feb 22, 2013 at 8:38 PM, alexdeuc...@gmail.com wrote:
From: Alex Deucher alexander.deuc...@amd.com
With the previous flushing changes this seems to work
reliably now.
v2: add R600_CONTEXT_FLUSH_AND_INV
Signed-off
For the series:
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Fri, Feb 22, 2013 at 11:59 PM, alexdeuc...@gmail.com wrote:
From: Alex Deucher alexander.deuc...@amd.com
With the previous flushing changes this seems to work
reliably now.
v2: add R600_CONTEXT_FLUSH_AND_INV
v3: just
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Sat, Feb 23, 2013 at 2:50 PM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
We might want to revisit the normalized_coords semantics, but this is
the current expected behavior.
Fixes fdo bug 61091.
---
src/gallium
I've tested CP DMA and it's better than it was, unfortunately it's on
par with R700, which means that piglit passes and Team Fortress 2 has
a corrupted GUI. At this point I think it would be better to disable
the CP DMA for R600-R700 and use streamout or async DMA instead.
Marek
On Fri, Feb 22,
On Tue, Feb 26, 2013 at 3:16 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Tue, Feb 26, 2013 at 5:24 AM, Marek Olšák mar...@gmail.com wrote:
I've tested CP DMA and it's better than it was, unfortunately it's on
par with R700, which means that piglit passes and Team Fortress 2 has
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Tue, Feb 26, 2013 at 4:20 PM, Brian Paul bri...@vmware.com wrote:
Just use simple assignments.
---
src/mesa/state_tracker/st_atom_rasterizer.c | 23 ---
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git
also don't require dword alignment with CP DMA for buffer transfers, which
is a leftover from the days when we used streamout to copy buffers
NOTE: This is a candidate for the 9.1 branch.
---
src/gallium/drivers/r600/r600_blit.c |3 +--
src/gallium/drivers/r600/r600_buffer.c |7
It does not work with TF2.
NOTE: This is a candidate for the 9.1 branch.
---
src/gallium/drivers/r600/r600_buffer.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/r600/r600_buffer.c
b/src/gallium/drivers/r600/r600_buffer.c
index e0ac047..9f8f739 100644
---
probably a typo
---
src/gallium/drivers/r600/r600_buffer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_buffer.c
b/src/gallium/drivers/r600/r600_buffer.c
index 9f8f739..8b2f505 100644
--- a/src/gallium/drivers/r600/r600_buffer.c
+++
This doesn't fix any issue we know of, but there indeed is a week spot
in draw_vbo where streamout can fail. After streamout is enabled,
the need_cs_space call can flush the context, which causes the streamout
to be disabled right after it was enabled and bad things happen.
One way to fix it is
---
src/gallium/drivers/r600/evergreen_state.c |5 +
src/gallium/drivers/r600/r600.h |1 +
src/gallium/drivers/r600/r600_hw_context.c |8
src/gallium/drivers/r600/r600_hw_context_priv.h |2 +-
src/gallium/drivers/r600/r600_state.c |
What is this good for? Is it for UAVs? (unordered access views)
For UAVs, I think there is ARB_shader_storage_buffer_object and
pipe_context::set_shader_resources.
Marek
On Wed, Feb 27, 2013 at 3:18 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Unfortunately not
The states were split because we thought it caused a hardlock. Now we know
the hardlock was caused by something else and has since been fixed.
---
src/gallium/drivers/r600/evergreen_state.c |3 +--
src/gallium/drivers/r600/r600_hw_context.c |1 -
src/gallium/drivers/r600/r600_pipe.h
These registers are either already emitted elsewhere or moved to start_cs.
---
src/gallium/drivers/r600/evergreen_hw_context.c | 42 ---
src/gallium/drivers/r600/evergreen_state.c | 14
src/gallium/drivers/r600/r600_hw_context.c |3 --
3 files
NOTE: This is a candidate for the 9.1 branch.
---
src/gallium/drivers/r600/r600_pipe.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index e2d86e9..27c98ec 100644
---
000..ae9cc37
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_range.h
@@ -0,0 +1,91 @@
+/*
+ * Copyright 2013 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 (the Software
Any driver can implement this simple and efficient optimization.
Team Fortress 2 hits it always. The DISCARD_RANGE codepath is not even used
with TF2 anymore, so we avoid a ton of useless buffer copies.
---
src/gallium/drivers/r600/evergreen_hw_context.c |3 +++
27, 2013 at 6:11 PM, Marek Olšák mar...@gmail.com wrote:
Any driver can implement this simple and efficient optimization.
Team Fortress 2 hits it always. The DISCARD_RANGE codepath is not even used
with TF2 anymore, so we avoid a ton of useless buffer copies.
With this patch applied are you
On Thu, Feb 28, 2013 at 12:50 AM, Brian Paul bri...@vmware.com wrote:
On 02/27/2013 04:11 PM, Marek Olšák wrote:
---
src/gallium/auxiliary/util/u_range.h | 91
++
1 file changed, 91 insertions(+)
create mode 100644 src/gallium/auxiliary/util/u_range.h
On Thu, Feb 28, 2013 at 4:26 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Feb 28, 2013 at 4:05 AM, Marek Olšák mar...@gmail.com wrote:
TF2 doesn't use CP DMA with this patch at all, so I'm not seeing any
issue obviously. This patch is an optimization, not a workaround. It
also doesn't
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 bind
flag set).
We'd really like to enforce these flags to be honored but
---
src/gallium/drivers/r600/r600_texture.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index acea19d..aefc40f 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++
---
src/gallium/drivers/r600/compute_memory_pool.c|1 +
src/gallium/drivers/r600/evergreen_compute.h |2 +-
src/gallium/drivers/r600/evergreen_compute_internal.c |1 +
src/gallium/drivers/r600/r600_pipe.c |1 +
src/gallium/drivers/r600/r600_pipe.h
Only the disassembler is used to dump shaders. Here's a few examples
how to use R600_DEBUG.
Log compute info:
R600_DEBUG=compute
Dump all shaders:
R600_DEBUG=fs,vs,gs,ps,cs
Dump pixel shaders only:
R600_DEBUG=ps
Disable Hyper-Z:
R600_DEBUG=nohyperz
Disable the LLVM backend:
---
src/gallium/drivers/r600/r600_asm.c | 239 ---
src/gallium/drivers/r600/r600_asm.h |1 -
2 files changed, 240 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index 283682f..805467e 100644
---
---
src/gallium/auxiliary/util/u_dump_state.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_dump_state.c
b/src/gallium/auxiliary/util/u_dump_state.c
index d7df5b4..2f28f3c 100644
--- a/src/gallium/auxiliary/util/u_dump_state.c
+++
---
src/gallium/drivers/r600/r600_asm.c |8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index 805467e..4e0cd01 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@
On Sat, Mar 2, 2013 at 3:02 AM, Roland Scheidegger srol...@vmware.com wrote:
Am 02.03.2013 01:36, schrieb Brian Paul:
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
---
src/gallium/drivers/r600/evergreen_hw_context.c | 27
src/gallium/drivers/r600/evergreen_state.c | 171 +++
src/gallium/drivers/r600/r600_hw_context.c | 17 +--
src/gallium/drivers/r600/r600_pipe.h| 14 +-
---
src/gallium/drivers/r600/evergreen_hw_context.c | 96 ---
src/gallium/drivers/r600/evergreen_state.c | 69
src/gallium/drivers/r600/evergreend.h |1 +
src/gallium/drivers/r600/r600_hw_context.c | 50 +---
It's nice to see so much code that did pretty much nothing go away.
---
src/gallium/drivers/r600/evergreen_compute.c |1 -
.../drivers/r600/evergreen_compute_internal.h |1 -
src/gallium/drivers/r600/evergreen_hw_context.c| 16 -
src/gallium/drivers/r600/r600.h
---
src/gallium/drivers/r600/evergreen_compute.c |1 -
.../drivers/r600/evergreen_compute_internal.c |1 -
src/gallium/drivers/r600/evergreen_hw_context.c|2 +-
src/gallium/drivers/r600/r600_hw_context.c |2 +-
src/gallium/drivers/r600/r600_hw_context_priv.h
---
src/gallium/drivers/r600/compute_memory_pool.c |1 -
src/gallium/drivers/r600/evergreen_compute.c |1 -
src/gallium/drivers/r600/evergreen_compute.h |1 -
.../drivers/r600/evergreen_compute_internal.c |1 -
src/gallium/drivers/r600/r600.h
This avoids the kernel CS checker errors with MSAA textures.
---
src/gallium/drivers/r600/r600_texture.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index 484045e..4825592 100644
---
This WebGL test sets width and height to 0:
https://www.khronos.org/registry/webgl/sdk/tests/conformance/misc/type-conversion-test.html
It causes assertion failures in the state tracker.
---
src/mesa/main/teximage.c |4
1 file changed, 4 insertions(+)
diff --git
We don't have a test for this yet, but obviously the swizzle was wrong.
---
src/gallium/auxiliary/util/u_blitter.c|2 +-
src/gallium/auxiliary/util/u_simple_shaders.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
On Mon, Mar 4, 2013 at 11:53 AM, Roland Scheidegger srol...@vmware.com wrote:
Am 02.03.2013 04:26, schrieb Dave Airlie:
On Sat, Mar 2, 2013 at 12:02 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 02.03.2013 01:36, schrieb Brian Paul:
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |
The conditional should be if (i 1 ..; with that fixed, this is:
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Mon, Mar 4, 2013 at 9:02 AM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
I hit an assert playing with softpipe and texture MSAA today, makes me
The sample positions can be found in r600_emit_msaa_state,
evergreen_emit_msaa_state, and cayman_emit_msaa_state, though
extracting them from the arrays might not be so straightforward.
Marek
On Sun, Mar 3, 2013 at 9:27 PM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie
On Mon, Mar 4, 2013 at 4:54 AM, Dave Airlie airl...@gmail.com wrote:
I've been playing with softpipe msaa on and off, but I hit a problem
with the clears and am just wondering if the state tracker should be
doing something like this.
Or maybe only if any bound buffer has nr_samples 1, or
deal.
For the whole series:
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
---
src/mesa/main/teximage.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 0dcf88a..a7b88d1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -3494,19 +3494,21 @@
On Sat, Mar 9, 2013 at 9:43 PM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
On Sat, Mar 9, 2013 at 12:30 PM, Jose Fonseca jfons...@vmware.com wrote:
Looks a sensible thing to do.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Thanks for the review.
Any insight how the caller can
On Mon, Mar 11, 2013 at 6:49 PM, Ian Romanick i...@freedesktop.org wrote:
Once upon a time Matt Turner was talking about using pixman to accelerate
operations like this in Mesa. It has a lot of highly optimized paths for
just this sort of thing. Since it's used by other projects, it gets a
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 patches floating on the list.
The solutions proposed or implemented so far all more or less
On Tue, Mar 12, 2013 at 10:31 AM, Christian König
deathsim...@vodafone.de 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
Z24X8 actually does save memory, because Radeon HD 5000 and later
cards don't support combined depth stencil formats, therefore Z24S8 is
allocated internally as two separate buffers Z24X8 and S8.
Marek
On Thu, Mar 14, 2013 at 2:55 PM, Brian Paul bri...@vmware.com wrote:
Omit Z24+0S visuals when
This patch series adds a format-independent memcpy-based path for ReadPixels
(i.e. consolidates the existing memcpy paths), and it also
adds a blit-based path for ReadPixels to st/mesa.
The gallium drivers have the option to turn off the blit-based paths through a
CAP. Right now, only softpipe,
---
src/mesa/main/texgetimage.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 7299a4b..74b09ef 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -518,6 +518,7 @@ get_tex_rgba(struct gl_context
I'll need the _mesa_readpixels_needs_slow_path function for the blit-based
version, but it's also useful to have this memcpy-based path in one place
and not scattered across several functions.
---
src/mesa/main/readpix.c | 194 ++-
The blit-based paths for TexImage, GetTexImage, and ReadPixels aren't very
fast with software rasterizer. Now Gallium drivers have the ability to turn
them off.
---
src/gallium/docs/source/screen.rst |4
src/gallium/drivers/llvmpipe/lp_screen.c |2 ++
On Thu, Mar 14, 2013 at 8:26 PM, Brian Paul bri...@vmware.com wrote:
On 03/14/2013 12:45 PM, Marek Olšák wrote:
---
src/mesa/main/texgetimage.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 7299a4b..74b09ef 100644
On Thu, Mar 14, 2013 at 8:29 PM, Brian Paul bri...@vmware.com wrote:
On 03/14/2013 12:45 PM, Marek Olšák wrote:
The blit-based paths for TexImage, GetTexImage, and ReadPixels aren't very
fast with software rasterizer. Now Gallium drivers have the ability to
turn
them off
On Fri, Mar 15, 2013 at 8:12 AM, Michel Dänzer mic...@daenzer.net wrote:
On Don, 2013-03-14 at 23:35 +0100, Martin Andersson wrote:
On Thu, Mar 14, 2013 at 7:45 PM, Marek Olšák mar...@gmail.com wrote:
+ /* See if the texture format already matches the format and type,
+* in which
Slowness is not usually a bug.
I guess it can be optimized even more. It depends on where the
bottleneck is now.
Marek
On Sun, Mar 17, 2013 at 10:14 PM, Rune Kjær Svendsen
runesv...@gmail.com wrote:
Thank you very much! This is much better. It's gone from 0.5-ish FPS when
zooming in to around
On Thu, Mar 14, 2013 at 3:23 PM, Brian Paul bri...@vmware.com wrote:
On 03/14/2013 08:18 AM, Marek Olšák wrote:
Z24X8 actually does save memory, because Radeon HD 5000 and later
cards don't support combined depth stencil formats, therefore Z24S8 is
allocated internally as two separate buffers
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Thu, Mar 21, 2013 at 5:59 PM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
This helps minimize confusion / effort when moving between branches or
helping others.
Signed-off-by: Michel Dänzer
Postprocessing is an internal meta op and should restore the states
it changes.
---
src/gallium/auxiliary/cso_cache/cso_context.c | 59 +
src/gallium/auxiliary/cso_cache/cso_context.h | 13 ++
src/gallium/auxiliary/postprocess/pp_mlaa.c |4 +-
---
src/gallium/drivers/r300/r300_state.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r300/r300_state.c
b/src/gallium/drivers/r300/r300_state.c
index ad93510..2de0fd6 100644
--- a/src/gallium/drivers/r300/r300_state.c
+++
---
src/gallium/drivers/r600/r600_state_common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600/r600_state_common.c
index b0e66ac..34c70ed 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++
---
src/gallium/drivers/radeonsi/si_state.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index a395ec4..fee1b7f 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++
https://bugs.freedesktop.org/show_bug.cgi?id=62573
Tested-by: Andreas Boll andreas.boll@gmail.com
---
src/mesa/state_tracker/st_cb_texture.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
/primgen.c
new file mode 100644
index 000..2873943
--- /dev/null
+++ b/tests/spec/ext_transform_feedback/primgen.c
@@ -0,0 +1,114 @@
+/*
+ * Copyright © 2013 Marek Olšák mar...@gmail.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software
Please disregard this patch.
Marek
On Fri, Mar 22, 2013 at 2:22 PM, Marek Olšák mar...@gmail.com wrote:
---
tests/all.tests|1 +
.../spec/ext_transform_feedback/CMakeLists.gl.txt |2 +-
tests/spec/ext_transform_feedback/primgen.c| 114
Conditional jump or move depends on uninitialised value(s)
---
src/gallium/auxiliary/tgsi/tgsi_text.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c
b/src/gallium/auxiliary/tgsi/tgsi_text.c
index 5abcb45..78534d9 100644
---
Hi everyone, one image is better than a thousand words:
http://people.freedesktop.org/~mareko/gallium-hud.png
So there you have it. This gallium module can draw transparent graphs and text
on top of what apps are rendering. By default, it can show framerate, cpu load
(each CPU or the average
The pipe query interface is reused. The list of available queries can be
obtained using pipe_screen::get_driver_query_info.
---
src/gallium/auxiliary/util/u_inlines.h |2 +-
src/gallium/include/pipe/p_defines.h | 12
src/gallium/include/pipe/p_screen.h| 11 +++
---
src/gallium/state_trackers/dri/common/dri_context.c |5 +
src/gallium/state_trackers/dri/common/dri_context.h |2 ++
src/gallium/state_trackers/dri/common/dri_drawable.c |4
3 files changed, 11 insertions(+)
diff --git
between begin_query and end_query
---
src/gallium/drivers/r600/r600_pipe.c | 19 +++
src/gallium/drivers/r600/r600_pipe.h |6
src/gallium/drivers/r600/r600_query.c| 44 +++---
src/gallium/drivers/r600/r600_state_common.c |1 +
4
---
src/gallium/drivers/r600/r600_pipe.c |3 +++
src/gallium/drivers/r600/r600_pipe.h |2 ++
src/gallium/drivers/r600/r600_query.c | 16
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 14 ++
That's a very good question. There are a couple of reasons for this.
1) Writing any kind of meta operation and custom rendering code on top
of GL is a horrible idea and very prone to errors. If you don't
restore all states after you're done, you may break the application.
If the application sets
On Mon, Mar 25, 2013 at 6:14 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Hi everyone, one image is better than a thousand words:
http://people.freedesktop.org/~mareko/gallium-hud.png
So there you have it. This gallium module can draw transparent graphs and
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 your patches and hit a few problems. As first, they do not apply
cleanly on master
I sent almost the same patch 3 days ago. I should have given it a
better commit message:
http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg36038.html
Marek
On Mon, Mar 25, 2013 at 10:54 PM, Brian Paul bri...@vmware.com wrote:
Fixes uninitialized member bug spotted by Ondrej
Pushed, except for creating a page in mesa/docs. I'll do that some time later.
Marek
On Mon, Mar 25, 2013 at 3:45 PM, Brian Paul bri...@vmware.com wrote:
On 03/22/2013 05:50 PM, Marek Olšák wrote:
Hi everyone, one image is better than a thousand words:
http://people.freedesktop.org/~mareko
Speaking of si_pm4_state, I think it's a horrible mechanism for
anything other than constant state objects (create/bind/delete
functions). For everything else (set/draw functions), you want to emit
directly into the command stream. It's not so different from the bad
state management which r600g
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013 15:34, schrieb Marek Olšák:
Speaking of si_pm4_state, I think it's a horrible mechanism for
anything other than constant state objects (create/bind/delete
functions). For everything else (set/draw
On Tue, Mar 26, 2013 at 6:44 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013 18:02, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013 15
I think this should be fixed in drivers.
Marek
On Tue, Mar 26, 2013 at 7:38 PM, Ondrej Holecek aaa...@gmail.com wrote:
On Tuesday 26 of March 2013 15:18:06 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
I recommend using OpenMP for this kind of pixel processing,
specifically the parallel for. It's pretty easy to use and you could
do wonders with it, i.e. taking advantage of all CPU cores on *any*
system. You could also offload the whole thing to another thread and
continue there.
Marek
On Tue,
---
src/gallium/state_trackers/dri/common/dri_drawable.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c
b/src/gallium/state_trackers/dri/common/dri_drawable.c
index 00ae1da..cd4a36a 100644
---
Does this patch help?
Marek
On Tue, Mar 26, 2013 at 8:32 AM, Dave Airlie airl...@gmail.com wrote:
so I've been playing with MSAA in softpipe and saw this, I don't think
any of my code is causing it, but it does take an MSAA test to trigger
it
with texelFetch fs sampler2DMS 4 I get the below
On Wed, Mar 27, 2013 at 1:43 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Mar 27, 2013 at 7:25 AM, Michel Dänzer mic...@daenzer.net wrote:
On Mit, 2013-03-27 at 12:02 +0100, Christian König wrote:
Am 26.03.2013 18:03, schrieb Michel Dänzer:
On Die, 2013-03-26 at 17:37 +0100,
On Wed, Mar 27, 2013 at 4:38 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Wed, Mar 27, 2013 at 11:27 AM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Build time option, set RADEON_CS_DUMP_ON_LOCKUP to 1 in radeon_drm_cs.h to
enable it.
When enabled after each cs
---
src/mesa/program/prog_statevars.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/program/prog_statevars.c
b/src/mesa/program/prog_statevars.c
index 5a35079..ccc590d 100644
--- a/src/mesa/program/prog_statevars.c
+++ b/src/mesa/program/prog_statevars.c
@@ -871,6 +871,9 @@
This patch series adds the ability to disable ARB_color_buffer_float in core GL
contexts, because let's be honest, the clamping controls don't make much sense
with core GL and must be emulated by most drivers anyway.
There is also some cleanup in _mesa_update_state_locked and how clamping
---
src/mesa/main/blend.c | 28 +++-
src/mesa/main/blend.h |8
src/mesa/main/fbobject.c| 10 ++
src/mesa/main/framebuffer.c |1 +
src/mesa/main/mtypes.h |4 +++-
src/mesa/main/readpix.c |5 +++--
This should reduce shader recompilations with drivers that emulate fragment
color clamping, because we want the clamping to be enabled only if there is
a signed normalized or floating-point colorbuffer.
---
src/mesa/main/blend.c |2 +-
src/mesa/main/fbobject.c
It has 2 dependencies: glClampColor and the framebuffer, we might just as well
do the update where those two are changed.
---
src/mesa/main/blend.c | 28
src/mesa/main/blend.h |6 ++
src/mesa/main/framebuffer.c |4
src/mesa/main/state.c
---
src/mesa/drivers/common/meta.c | 18 --
src/mesa/main/attrib.c |9 +++--
src/mesa/main/blend.c| 19 ---
src/mesa/main/get.c |9 -
src/mesa/main/get_hash_params.py |2 +-
src/mesa/main/light.c
---
src/mesa/state_tracker/st_extensions.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 11db9d3..2d8b9ef 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Fri, Mar 29, 2013 at 1:05 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/drivers/freedreno/freedreno_screen.c |1 +
src/gallium/drivers/i915
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Fri, Mar 29, 2013 at 2:33 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
---
src/gallium/docs/source/context.rst |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/docs/source
On Fri, Mar 29, 2013 at 4:21 PM, Brian Paul bri...@vmware.com wrote:
On 03/28/2013 03:24 PM, Marek Olšák wrote:
---
src/mesa/state_tracker/st_**extensions.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/state_tracker/st_**extensions.c
b/src/mesa
Have you checked the font is rendered correctly? The font should be
transparent and the blend function reads the alpha channel to determine the
transparency, so A8 would be a better option. If that isn't an option
either, the fragment shader should do . swizzling.
Marek
On Tue, Apr 2, 2013
Oops. I always forget about that.
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Tue, Apr 2, 2013 at 12:46 AM, Brian Paul brian.e.p...@gmail.com wrote:
From: Brian Paul bri...@vmware.com
The VMware svga driver is picky about making sure the VBO is unmapped
before drawing.
---
src
, Brian Paul bri...@vmware.com wrote:
On 04/01/2013 06:18 PM, Marek Olšák wrote:
Have you checked the font is rendered correctly?
Yeah, it works fine.
The font should be
transparent and the blend function reads the alpha channel to
determine the transparency, so A8 would be a better
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Thu, Apr 4, 2013 at 1:39 AM, Brian Paul bri...@vmware.com wrote:
To match the FREE() called used later. Fixes things on Windows.
---
src/gallium/auxiliary/hud/hud_context.c |2 +-
1 files changed, 1 insertions(+), 1 deletions
FWIW, I think UCMP is a misleading name. Whatever the name will be, it
should be prefixed with I or U, because it's not a floating-point
opcode. How about UCND? :D
Marek
On Thu, Apr 4, 2013 at 6:23 PM, Jose Fonseca jfons...@vmware.com wrote:
There might be some value in renaming UCMP to be
301 - 400 of 12096 matches
Mail list logo
