Ian,
I will shortly send a changeset incorporating the changes, thanks for
summarizing.
On Tuesday, September 09, 2014 16:11:45 Ian Romanick wrote:
I also second Marek's comment about testing. My recollection from
Khronos meetings is that at least AMD GL 3.x-class hardware can only
handle
https://bugs.freedesktop.org/show_bug.cgi?id=79662
lu hua huax...@intel.com changed:
What|Removed |Added
Summary|[DRI3 all Bisected] Many|[DRI3 all Bisected] Many
From: Christian König christian.koe...@amd.com
In preparation to using buffers clears with the hw engine(s).
v2: split out flipping to using hw buffer clears.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_uvd.c| 40 ++-
From: Christian König christian.koe...@amd.com
Less CPU overhead and avoids contention over CPU accessible memory on startup.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_uvd.c | 6 +++---
src/gallium/drivers/radeon/radeon_video.c | 10
Hi,
I have been looking into this bug:
Compiling of shader gets stuck in infinite loop
https://bugs.freedesktop.org/show_bug.cgi?id=78468
Although this occurs at link time when the Intel driver has run some of
its specific lowering passes, it looks like the problem could hit other
drivers if
On 10.09.2014 22:59, Tom Stellard wrote:
+ /* Always use the default config when all backends are enabled.
*/
+ if (rb_mask util_bitcount(rb_mask) max_backends) {
+ /* XXX: I can't figure out what the *_XSEL and *_YSEL
+
On 11.09.2014 16:55, Christian König wrote:
From: Christian König christian.koe...@amd.com
In preparation to using buffers clears with the hw engine(s).
v2: split out flipping to using hw buffer clears.
Thanks! The series is
Reviewed-by: Michel Dänzer michel.daen...@amd.com
--
Earthling
On 11.09.2014 00:28, Grigori Goronzy wrote:
On 10.09.2014 10:54, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
+ array_mode = si_array_mode(rtiled-surface.level[tiled_lvl].mode);
Wouldn't it be more consistent to pull the array_mode from the tile mode
array like other
On 11.09.2014 07:05, Marek Olšák wrote:
Sorry, the function is too confusing for me to understand it, but it
looks good.
Thanks, but unfortunately, it breaks the fbo-generatemipmap-formats test
with compressed formats for some reason. Investigating that now.
I think it would be cleaner to
https://bugs.freedesktop.org/show_bug.cgi?id=83669
--- Comment #10 from Marc Dietrich marvi...@gmx.de ---
I check with -g -O0 and debug symbols are generated, but I can't tell about
their usefulness. Compiling with --enable-debug fails though because -DDEBUG
seems to do strange things in
https://bugs.freedesktop.org/show_bug.cgi?id=83669
--- Comment #11 from Marc Dietrich marvi...@gmx.de ---
sorry for spamming this bug, here is a better patch to fix the problem
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index e71bccb..bbdb36f 100644
--- a/src/mesa/Makefile.am
+++
https://bugs.freedesktop.org/show_bug.cgi?id=70599
Tapani Pälli lem...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -266,30 +265,32 @@
On Thu, Sep 11, 2014 at 1:27 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
---
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
--- a/src/mesa/main/uniform_query.cpp
+++
On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli tapani.pa...@intel.com wrote:
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index
On Thu, Aug 28, 2014 at 9:58 AM, Tapani Pälli tapani.pa...@intel.com wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
Signed-off-by: Tapani Pälli
On 09/11/2014 03:12 PM, Erik Faye-Lund wrote:
On Thu, Aug 28, 2014 at 9:58 AM, Tapani Pälli tapani.pa...@intel.com wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains
File specific optimization as used for src/mesa/main/streaming-load-memcpy.c
currently will cause problems with LTO in the future
(see: https://bugs.freedesktop.org/show_bug.cgi?id=83669). Replace it with
in-file target specification.
This only works for gcc for now. The intel compiler has
https://bugs.freedesktop.org/show_bug.cgi?id=83570
--- Comment #13 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #12)
Roland,
Perhaps you can help me here. I'm looking at udiv_emit_cpu and I'm just
not getting it. The comment says:
/* udiv by zero is guaranteed to
https://bugs.freedesktop.org/show_bug.cgi?id=83570
--- Comment #14 from rcond...@hotmail.com ---
(In reply to comment #13)
(comparison masks are either all ones or all zeros).
AHH!!! That was the piece I was missing. My hair follicles thank you.
--
You are receiving this mail because:
You are
On Thu, Sep 11, 2014 at 6:58 AM, Marc Dietrich marvi...@gmx.de wrote:
File specific optimization as used for src/mesa/main/streaming-load-memcpy.c
currently will cause problems with LTO in the future
(see: https://bugs.freedesktop.org/show_bug.cgi?id=83669). Replace it with
in-file target
https://bugs.freedesktop.org/show_bug.cgi?id=83777
Priority: medium
Bug ID: 83777
CC: olva...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [regression] ilo fails to build
Severity: normal
Classification:
https://bugs.freedesktop.org/show_bug.cgi?id=83631
--- Comment #3 from Brian Paul bri...@vmware.com ---
#include GL/glx.h should pull in GL/gl.h (line 32) which should include
GL/glext.h So by time we hit the use of GLintptr, it should have been defined.
When I compile a trivial test program
On Wednesday, September 10, 2014 06:01:19 PM Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
If the source is not a GRF, it could have a register = virtual_grf_count.
Accessing virtual_grf_end with such a register would lead to
out-of-bounds access. Make sure the source is a
On 09/11/2014 05:09 AM, Erik Faye-Lund wrote:
On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli tapani.pa...@intel.com wrote:
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
On Thu, Sep 11, 2014 at 05:24:03PM +0900, Michel Dänzer wrote:
On 10.09.2014 22:59, Tom Stellard wrote:
+/* Always use the default config when all backends are enabled.
*/
+if (rb_mask util_bitcount(rb_mask) max_backends) {
+/* XXX: I can't
On 08/28/2014 12:58 AM, Tapani Pälli wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
On Thu, Sep 11, 2014 at 8:35 PM, Ian Romanick i...@freedesktop.org wrote:
On 09/11/2014 05:09 AM, Erik Faye-Lund wrote:
On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli tapani.pa...@intel.com wrote:
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick
On Thu, Sep 11, 2014 at 8:39 PM, Ian Romanick i...@freedesktop.org wrote:
On 08/28/2014 12:58 AM, Tapani Pälli wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
I have looked at this problem quite a bit but never got to the bottom of it.
This problem really started to show with commit 857f3a6 - glsl: Ignore
loop-too-large heuristic if there's bad variable indexing.
That commit makes many more loops unroll.
Here is another example piglit shader_runner test
also fixes nv50_blit_eng2d_get_mask for PIPE_FORMAT_X8Z24_UNORM
Tested-by: Tiziano Bacocco tizb...@gmail.com (on NVC0)
Signed-off-by: David Heidelberger david.heidelber...@ixit.cz
---
src/gallium/drivers/nouveau/nv50/nv50_blit.h| 26
-
On Thu, Sep 11, 2014 at 5:45 PM, David Heidelberger
david.heidelber...@ixit.cz wrote:
also fixes nv50_blit_eng2d_get_mask for PIPE_FORMAT_X8Z24_UNORM
Can you explain the problem a little bit and what the end-effect of
this fix is? If not, that's OK, I can probably work it out...
Tested-by:
I started using PIPE_FORMAT_X8Z24_UNORM and
PIPE_FORMAT_S8_UINT_Z24_UNORM in Nine state tracker.
As it shows up, it caused problems on NVC0 (PGRAPH errors), which are
solved by adding PIPE_FORMAT_X8Z24_UNORM in nvc0_miptree.c.
By quick grep I also noticed, there is lot places in nv50, where
Fix #83596
https://bugs.freedesktop.org/show_bug.cgi?id=83596
---
src/mesa/main/fbobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index ae3a418..5eaf1a3 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2299,6
Am 15.08.2014 04:50, schrieb Jason Ekstrand:
On Aug 14, 2014 7:13 PM, Dieter Nützel die...@nuetzel-hh.de
wrote:
Am 15.08.2014 02:36, schrieb Dave Airlie:
On 08/02/2014 02:11 PM, Jason Ekstrand wrote:
Most format conversion operations required by GL can be
performed by
converting
It would be good to also have a piglit test which demonstrates this
bad behavior.
Patch is:
Reviewed-by: Chris Forbes chr...@ijw.co.nz
On Fri, Sep 12, 2014 at 9:42 AM, Vincent Lejeune v...@ovi.com wrote:
Fix #83596
https://bugs.freedesktop.org/show_bug.cgi?id=83596
---
On 09/10/2014 05:45 AM, Emil Velikov wrote:
Hello all,
The original plan from Ian was to have four release candidates prior to the
final release. From what I can see there has been no serious amount of patches
nominated for 10.3-rc4, so I'm planning to keep with the plan and release 10.3
On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel die...@nuetzel-hh.de wrote:
Am 15.08.2014 04:50, schrieb Jason Ekstrand:
On Aug 14, 2014 7:13 PM, Dieter Nützel die...@nuetzel-hh.de
wrote:
Am 15.08.2014 02:36, schrieb Dave Airlie:
On 08/02/2014 02:11 PM, Jason Ekstrand wrote:
On Wed, Sep 10, 2014 at 8:20 PM, Kalyan Kondapally
kondapallykalyancontrib...@gmail.com wrote:
With GLES we don't give any kind of warning in case we don't
write to gl_position. This patch makes changes so that we
generate a warning in case of GLES (VER 300) and an error
in case of GL.
On Thu, Sep 11, 2014 at 3:31 PM, Jason Ekstrand ja...@jlekstrand.net
wrote:
On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel die...@nuetzel-hh.de
wrote:
Am 15.08.2014 04:50, schrieb Jason Ekstrand:
On Aug 14, 2014 7:13 PM, Dieter Nützel die...@nuetzel-hh.de
wrote:
Am 15.08.2014
Am 12.09.2014 00:31, schrieb Jason Ekstrand:
On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel die...@nuetzel-hh.de
wrote:
Am 15.08.2014 04:50, schrieb Jason Ekstrand:
On Aug 14, 2014 7:13 PM, Dieter Nützel die...@nuetzel-hh.de
wrote:
Am 15.08.2014 02:36, schrieb Dave Airlie:
On 08/02/2014
On Thu, Sep 11, 2014 at 3:53 PM, Dieter Nützel die...@nuetzel-hh.de wrote:
Am 12.09.2014 00:31, schrieb Jason Ekstrand:
On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel die...@nuetzel-hh.de
wrote:
Am 15.08.2014 04:50, schrieb Jason Ekstrand:
On Aug 14, 2014 7:13 PM, Dieter Nützel
https://bugs.freedesktop.org/show_bug.cgi?id=83777
--- Comment #1 from sarnex commendsar...@gmail.com ---
Exact same issue here.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=83777
sarnex commendsar...@gmail.com changed:
What|Removed |Added
Severity|normal |major
https://bugs.freedesktop.org/show_bug.cgi?id=83777
sarnex commendsar...@gmail.com changed:
What|Removed |Added
Severity|major |critical
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=83777
Chia-I Wu olva...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=83785
Priority: medium
Bug ID: 83785
Assignee: mesa-dev@lists.freedesktop.org
Summary: Shader branches excluded by uniform values are not
optimized out
Severity: major
https://bugs.freedesktop.org/show_bug.cgi?id=83785
Roland Scheidegger srol...@vmware.com changed:
What|Removed |Added
Severity|major |enhancement
On 09/11/2014 09:39 PM, Ian Romanick wrote:
On 08/28/2014 12:58 AM, Tapani Pälli wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
Signed-off-by: Tapani Pälli
Samplers take up zero slots and therefore don't exist in the params
array, nor are they included in stage_prog_data-nr_params. There's no
need to store their size in param_size, as it's only used for dealing
with arrays of real uniforms (ones uploaded as shader constants).
We run into all kinds
The FS backend has always used 0, and the VS backend has always used 1.
I think 1 is just working around other problems, and is incorrect.
Samplers are baked in; nothing uses the UNIFORM register we would
create, and we shouldn't upload any constant values for them.
Fixes
https://bugs.freedesktop.org/show_bug.cgi?id=70599
lu hua huax...@intel.com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #3 from
53 matches
Mail list logo
