From: Christian König
That better matches the actual userspace use case, the
kernel will force it to VRAM if the hardware requires it.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/driv
From: Christian König
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
---
src/gallium/drivers/radeon/radeon_uvd.c| 40 ++-
src/gallium/drivers/radeon/radeon_vce.c| 17
From: Christian König
Less CPU overhead and avoids contention over CPU accessible memory on startup.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c | 6 +++---
src/gallium/drivers/radeon/radeon_video.c | 10 --
src/gallium/drivers/radeon/radeon_video.h |
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 the
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
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
--
Earthling Michel Dänzer| http
On 11.09.2014 00:28, Grigori Goronzy wrote:
On 10.09.2014 10:54, Michel Dänzer wrote:
From: Michel Dänzer
+ 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 parameters?
I don't
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 ---
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 combination with --enabl
https://bugs.freedesktop.org/show_bug.cgi?id=83669
--- Comment #11 from Marc Dietrich ---
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
+++ b/src/mesa/Makefi
https://bugs.freedesktop.org/show_bug.cgi?id=70599
Tapani Pälli changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick 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 @@ validate_uniform_parameters(s
On Thu, Sep 11, 2014 at 1:27 PM, Erik Faye-Lund wrote:
> On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick 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/unifo
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
> On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick 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.c
On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli wrote:
> On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
>> On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick wrote:
>>> diff --git a/src/mesa/main/uniform_query.cpp
>>> b/src/mesa/main/uniform_query.cpp
>>> index 609d94b..7b089fa 100644
>>> --- a/src/mesa/
On Thu, Aug 28, 2014 at 9: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
> ---
> src/mesa/main/uniform
On 09/11/2014 03:12 PM, Erik Faye-Lund wrote:
On Thu, Aug 28, 2014 at 9: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: Tapa
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
__attri
https://bugs.freedesktop.org/show_bug.cgi?id=83570
--- Comment #13 from Roland Scheidegger ---
(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 return 0xfff
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 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 specification.
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: Unclas
https://bugs.freedesktop.org/show_bug.cgi?id=83631
--- Comment #3 from Brian Paul ---
#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 like this:
#incl
On Wednesday, September 10, 2014 06:01:19 PM Ian Romanick wrote:
> From: Ian Romanick
>
> 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 GRF before accessi
On 09/11/2014 05:09 AM, Erik Faye-Lund wrote:
> On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli wrote:
>> On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
>>> On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/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
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
> ---
> src/mesa/main/uniform_query.cp
On Thu, Sep 11, 2014 at 8:35 PM, Ian Romanick wrote:
> On 09/11/2014 05:09 AM, Erik Faye-Lund wrote:
>> On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli wrote:
>>> On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick wrote:
> diff --git a/src/mesa/main
On Thu, Sep 11, 2014 at 8: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-o
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 tes
also fixes nv50_blit_eng2d_get_mask for PIPE_FORMAT_X8Z24_UNORM
Tested-by: Tiziano Bacocco (on NVC0)
Signed-off-by: David Heidelberger
---
src/gallium/drivers/nouveau/nv50/nv50_blit.h| 26
-
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 1 +
src/gallium/drive
On Thu, Sep 11, 2014 at 5:45 PM, David Heidelberger
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: Tiziano Bacocco (on NVC0)
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 m
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"
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
> con
It would be good to also have a piglit test which demonstrates this
bad behavior.
Patch is:
Reviewed-by: Chris Forbes
On Fri, Sep 12, 2014 at 9:42 AM, Vincent Lejeune wrote:
> Fix #83596
> https://bugs.freedesktop.org/show_bug.cgi?id=83596
> ---
> src/mesa/main/fbobject.c | 1 +
> 1 file chan
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 wrote:
> Am 15.08.2014 04:50, schrieb Jason Ekstrand:
>
> On Aug 14, 2014 7:13 PM, "Dieter Nützel"
>> 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
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.
>
> Signed-off-by: Kalyan Kondapally
On Thu, Sep 11, 2014 at 3:31 PM, Jason Ekstrand
wrote:
>
>
> On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel
> wrote:
>
>> Am 15.08.2014 04:50, schrieb Jason Ekstrand:
>>
>> On Aug 14, 2014 7:13 PM, "Dieter Nützel"
>>> wrote:
>>> >
>>> > Am 15.08.2014 02:36, schrieb Dave Airlie:
>>> >
>>> >
Am 12.09.2014 00:31, schrieb Jason Ekstrand:
On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel
wrote:
Am 15.08.2014 04:50, schrieb Jason Ekstrand:
On Aug 14, 2014 7:13 PM, "Dieter Nützel"
wrote:
Am 15.08.2014 02:36, schrieb Dave Airlie:
On 08/02/2014 02:11 PM, Jason Ekstrand wrote:
Most
On Thu, Sep 11, 2014 at 3:53 PM, Dieter Nützel wrote:
> Am 12.09.2014 00:31, schrieb Jason Ekstrand:
>
> On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel
>> wrote:
>>
>> Am 15.08.2014 04:50, schrieb Jason Ekstrand:
>>>
>>> On Aug 14, 2014 7:13 PM, "Dieter Nützel"
wrote:
>
> A
https://bugs.freedesktop.org/show_bug.cgi?id=83777
--- Comment #1 from sarnex ---
Exact same issue here.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.fr
https://bugs.freedesktop.org/show_bug.cgi?id=83777
sarnex changed:
What|Removed |Added
Severity|normal |major
Priority|medium
https://bugs.freedesktop.org/show_bug.cgi?id=83777
sarnex changed:
What|Removed |Added
Severity|major |critical
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=83777
Chia-I Wu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
Classifi
https://bugs.freedesktop.org/show_bug.cgi?id=83785
Roland Scheidegger changed:
What|Removed |Added
Severity|major |enhancement
Component|Mesa
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: Tap
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 kind
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 ES3-CTS.shaders.struct.un
https://bugs.freedesktop.org/show_bug.cgi?id=70599
lu hua changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #3 from lu hua ---
(In re
https://bugs.freedesktop.org/show_bug.cgi?id=83777
Fabio Pedretti changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--
You are receiving this mai
This patch fixes a NULL pointer dereference in a test case which
allocates piles of buffers without ever freeing them, and repeatedly
tries to upload/fetch data to/from those buffers, without doing any
other work (such as rendering).
The same problem exists in a variety of other places, some of wh
Reviewed-by: Tapani Pälli
On 09/12/2014 09:43 AM, Kenneth Graunke wrote:
> This patch fixes a NULL pointer dereference in a test case which
> allocates piles of buffers without ever freeing them, and repeatedly
> tries to upload/fetch data to/from those buffers, without doing any
> other work (su
55 matches
Mail list logo
