On 07.05.2014 23:00, Marek Olšák wrote:
> From: Marek Olšák
>
> Only for Cayman, SI, CIK.
[...]
> diff --git a/src/gallium/drivers/radeon/r600d_common.h
> b/src/gallium/drivers/radeon/r600d_common.h
> index 1172af0..fa6131f 100644
> --- a/src/gallium/drivers/radeon/r600d_common.h
> +++ b/src/g
V2: The main change in v2 is adding a convenience function to avoid
code like this:
while (check_type->is_array())
check_type = check_type->element_type();
and
if (type->is_record()
|| (type->is_array() && type->fields.array->is_record())
they can now support arrays of arr
Also add TODO comment about adding proper support
Signed-off-by: Timothy Arceri
---
src/glsl/ir_set_program_inouts.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/glsl/ir_set_program_inouts.cpp
b/src/glsl/ir_set_program_inouts.cpp
index 5163eb2..779cf2a 100644
--- a/src/glsl/i
Signed-off-by: Timothy Arceri
---
src/glsl/lower_packed_varyings.cpp | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/src/glsl/lower_packed_varyings.cpp
b/src/glsl/lower_packed_varyings.cpp
index e865474..b641d6d 100644
--- a/src/glsl/lower_packed_varyings.cpp
+++ b/sr
Signed-off-by: Timothy Arceri
---
src/glsl/ast_to_hir.cpp | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 7516c33..3529314 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3390,9 +3390,7 @@ ast_de
Signed-off-by: Timothy Arceri
---
src/glsl/link_uniforms.cpp | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index 29dc0b1..c7147e0 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -308,8 +308
This will avoid a bunch of code when implementing arrays of arrays
support.
Signed-off-by: Timothy Arceri
---
src/glsl/glsl_types.h | 16
1 file changed, 16 insertions(+)
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index dca5492..51147e9 100644
--- a/src/glsl/gls
Signed-off-by: Timothy Arceri
---
src/glsl/link_varyings.cpp | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 45f1b10..5a18e40 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
https://bugs.freedesktop.org/show_bug.cgi?id=78581
--- Comment #1 from Tom Stellard ---
I though this was working. Can you provide and example of the output when a
shader fails to compile.
--
You are receiving this mail because:
You are the assignee for the bug.
___
Am 11.05.2014 02:34, schrieb Ilia Mirkin:
> Previously the implication was that queries should be disabled during
> blits. However glBlitFramebuffer() is supposed to obey the current
> query, and this new bit will indicate that to the driver.
>
> Signed-off-by: Ilia Mirkin
> Cc: "10.2"
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=78604
Priority: medium
Bug ID: 78604
Assignee: mesa-dev@lists.freedesktop.org
Summary: swrast/radeonsi: Supertuxkart 0.8.1 xserver segfault
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #1 from Ilia Mirkin ---
I'm guessing you meant
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1db993f2fe1c2b43a9658efba6eac93665bb859c
Can you double-check the results of your bisect? This commit adds support for
some new opcodes
On Mon, May 12, 2014 at 9:53 AM, Roland Scheidegger wrote:
> Am 11.05.2014 02:34, schrieb Ilia Mirkin:
>> Previously the implication was that queries should be disabled during
>> blits. However glBlitFramebuffer() is supposed to obey the current
>> query, and this new bit will indicate that to the
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #2 from smoki ---
Created attachment 98926
--> https://bugs.freedesktop.org/attachment.cgi?id=98926&action=edit
log
Yes i doublechecked it, 1db993f2fe1c2b43a9658efba6eac93665bb859c introduce
this bug, but ab4927f3e04918fd8a53c2d9
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #3 from Ilia Mirkin ---
(In reply to comment #2)
> Created attachment 98926 [details]
> log
>
>
> Yes i doublechecked it, 1db993f2fe1c2b43a9658efba6eac93665bb859c introduce
> this bug, but ab4927f3e04918fd8a53c2d91be4dfc65fe9782d w
https://bugs.freedesktop.org/show_bug.cgi?id=57013
--- Comment #3 from Drew Moseley ---
(In reply to comment #2)
> Created attachment 98768 [details] [review]
> Updated patch.
>
> I think embedding "/lib" in the GLUT_LIBS definition makes this not work on
> 64-bit systems that use /lib64.
OK,
In addition to first version there is now also path for miptree
updownsampling. While the relevant piglit tests don't crash on BDW
anymore, they do not pass either - it seems that there are still SRGB
blits needed that on previous hardware are covered by blorp. Using
the stencil texturing support o
v2: Use intel_mipmap_tree::total_width in order to get correct alignment
automatically. Also use "mt->total_height / mt->physical_depth0" as
surface height allowing hardware to offset to correct slice.
Cc: "10.2"
Signed-off-by: Topi Pohjolainen
Reviewed-by: Kenneth Graunke (v1)
---
src
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_context.h | 4 +++
src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c | 34 +++
2 files changed, 38 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_
v2: Configure stencil directly for final dimensions instead of
adjusting bit by bit for tiling, mip level and msaa.
Cc: "10.2"
Signed-off-by: Topi Pohjolainen
Reviewed-by: Kenneth Graunke (v1)
---
src/mesa/drivers/dri/i965/brw_context.h | 4 +++
src/mesa/drivers/dri/i965/brw_met
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/common/meta.h | 15 ++
src/mesa/drivers/common/meta_blit.c | 59 +++--
2 files changed, 52 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
v2: Allow hardware to offset accesses to individual layers. Also leave
the mip-level overriding for the creator of the intel renderbuffer
to handle. Merged with "i965/gen8: Allow stencil buffers to be
configured as single sampled"
Ken: I left the "_mesa_problem()" still in place. I thi
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #4 from smoki ---
Builded it with --enable-debug, but get the same message in Xorg.0.log.
Sounds odd but who knows it just reporducable here, Athlon 5350 and Debian Sid
32bit, maybe someone can reproduce it too, this is the game:
v2: Create the intel renderbuffer with level hardcoded to zero instead
of overriding it in the surface state configuration. Also moved the
dimension adjustments for tiling, mip level, msaa into the render
buffer creation. Finally prepares for another blit path needed for
miptree upd
This is effective only on gen8 for now as previous generations still
go through blorp.
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/intel_fbo.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_f
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9 -
1 file changed, 8 insertions(+), 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 b23fddf..88bd8f0 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tr
Kenneth Graunke writes:
> The point of copytexsubimage_using_blit_framebuffer is to use a hardware
> accelerated BlitFramebuffer path. If that fails, we shouldn't do a
> swrast blit---we should try our CTSI fallback code.
>
> This is especially important for i965 and GLES, where we don't even
>
On Mon, May 12, 2014 at 9:54 AM, Michel Dänzer wrote:
> On 07.05.2014 23:00, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> Only for Cayman, SI, CIK.
>
> [...]
>
>> diff --git a/src/gallium/drivers/radeon/r600d_common.h
>> b/src/gallium/drivers/radeon/r600d_common.h
>> index 1172af0..fa6131f 1006
Carl (the stable branch maintainer) doesn't have plans to do another
10.0.x release. That said, if the fix is found (by bisecting), it might
still get picked to the branch. If Fedora is shipping 9.2 or 10.0, they
might get the update. Dunno.
On 05/06/2014 11:01 AM, Benjamin Bellec wrote:
> Hell
On 05/11/2014 11:03 PM, Kenneth Graunke wrote:
> As far as I can tell, Mesa hasn't had a convenient way to dump ARB_vp/fp
> source until now. Using MESA_GLSL=dump is convenient, since it means
> you can use a single environment variable to dump a program's shaders,
> no matter which language they'
On 05/09/2014 02:55 AM, jfons...@vmware.com wrote:
> From: José Fonseca
>
> That information misleads source code auditing tools to think that
> ralloc itself is released under LGPL v3.
>
> Instead, simply state talloc is not licensed under a permissive license.
> ---
> src/glsl/ralloc.h | 7 ++
Reviewed-by: Ian Romanick
On 05/09/2014 01:28 AM, Topi Pohjolainen wrote:
> Signed-off-by: Topi Pohjolainen
> ---
> src/mesa/drivers/common/meta.h | 7
> src/mesa/drivers/common/meta_blit.c | 70
> +
> 2 files changed, 47 insertions(+), 30 deletio
Reviewed-by: Ian Romanick
On 05/09/2014 01:28 AM, Topi Pohjolainen wrote:
> Signed-off-by: Topi Pohjolainen
> ---
> src/mesa/drivers/common/meta.h | 5 +
> src/mesa/drivers/common/meta_blit.c | 38
> -
> 2 files changed, 30 insertions(+), 13 deleti
Reviewed-by: Ian Romanick
On 05/12/2014 08:42 AM, Topi Pohjolainen wrote:
> Signed-off-by: Topi Pohjolainen
> ---
> src/mesa/drivers/common/meta.h | 15 ++
> src/mesa/drivers/common/meta_blit.c | 59
> +++--
> 2 files changed, 52 insertions(+), 22 d
Reviewed-by: Ian Romanick
On 05/11/2014 05:25 AM, Timothy Arceri wrote:
> Signed-off-by: Timothy Arceri
> ---
> src/glsl/link_uniforms.cpp | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
> index 29dc0b1..cd231cb
This patch is
Reviewed-by: Ian Romanick
For 10.3, I think we should look to migrate meta to using separate
shader objects and explicit attrib locations... or at least make some
short-cut functions to reduce the number of calls made in meta.
On 05/09/2014 01:28 AM, Topi Pohjolainen wrote:
> Sign
Reviewed-by: Ian Romanick
On 05/08/2014 04:28 PM, Chris Forbes wrote:
> Both the ast->IR and linker have functions with this name, but different
> behavior.
>
> Rename the linker's version to var_counts_against_varying_limit to be
> closer to what it is actually used for.
>
> Suggested by Ian a
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #5 from smoki ---
Just tried 64bit variant and that works, so cannot reproduce it on 64bit
Debian, using 64bit supertuxkart binary... seems like some kind of 32bit only
issue :).
--
You are receiving this mail because:
You are the
On 05/12/2014 01:02 AM, Yang, Rong R wrote:
> Hi, Ken,
>
> Thanks for your patch. But how do you release your driver on the HSW
> products? If can't LRI/LRM from userspace batches, almost all of
> OpenCL application can't run. So if I want to announce that the
> OpenCL driver support HSW, it must
https://bugs.freedesktop.org/show_bug.cgi?id=78581
--- Comment #2 from Luke-Jr ---
(In reply to comment #1)
> I though this was working. Can you provide and example of the output when a
> shader fails to compile.
With my current setup, what happens seems to be LLVM tries to format FROM
unalloca
https://bugs.freedesktop.org/show_bug.cgi?id=78604
smoki changed:
What|Removed |Added
Summary|swrast/radeonsi:|swrast/radeonsi:
|Supertuxkart
Reviewed-by: Chris Forbes
On Tue, May 13, 2014 at 4:36 AM, Eric Anholt wrote:
> Kenneth Graunke writes:
>
>> The point of copytexsubimage_using_blit_framebuffer is to use a hardware
>> accelerated BlitFramebuffer path. If that fails, we shouldn't do a
>> swrast blit---we should try our CTSI fa
https://bugs.freedesktop.org/show_bug.cgi?id=78604
Benjamin Bellec changed:
What|Removed |Added
CC||b.bel...@gmail.com
--- Comment #6 from
https://bugs.freedesktop.org/show_bug.cgi?id=78581
--- Comment #3 from Tom Stellard ---
Did you upgrade llvm and clang at the same time? Did you do a clean rebuild of
Mesa after upgrading? Mesa statically links with clang, so you need to make
sure the clover is completely rebuilt after you upgr
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #7 from Benjamin Bellec ---
Hum... in fact Steam games doesn't work anymore too, eg. Left 4 Dead 2 or Team
Fortress 2.
The problem is the same from the log (unable to load the driver).
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=78581
CC: "10.1 10.2"
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
inde
Eric Anholt writes:
> Matt Turner writes:
>
>> From: Kenneth Graunke
>>
>> The pass breaks live ranges of virtual registers by allocating new
>> registers when it sees an assignment to a virtual GRF it's already seen
>> written.
>>
>> total instructions in shared programs: 1656292 -> 1651898 (-
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #8 from Ilia Mirkin ---
(In reply to comment #6)
> I can reproduce this issue on Evergreen.
> The information provided by "smoki" seems correct.
>
> The 64-bit game provided by Fedora 19 works fine with current master.
> But the 32-b
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #9 from Tobias Droste ---
Yes it's the same issue. Delete 'libgcc_s.so.1' from the bin folder in
supertuxkart to make it use the system one.
For me it also reliable crashes X if I use the 'libgcc_s.so.1' supertuxkart
provides.
Btw. I
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #10 from smoki ---
Ilia indeed it is odd, but it does cause xserver to crash :). I investigated
this further and both 64bit and 32bit version shiped in Debian does not have
this bug ;).
It happens with that 32bit 0.8.1 game downloa
On 05/12/2014 10:12 AM, Ian Romanick wrote:
> This patch is
>
> Reviewed-by: Ian Romanick
>
> For 10.3, I think we should look to migrate meta to using separate
> shader objects and explicit attrib locations... or at least make some
> short-cut functions to reduce the number of calls made in met
Please ignore this patch I already sent it out by itself and its been
reviewed and pushed. Its not really related to this series its more of a
clean up before the uniform work.
On Mon, 2014-05-12 at 21:16 +1000, Timothy Arceri wrote:
> Signed-off-by: Timothy Arceri
> ---
> src/glsl/link_uniforms
With this and the previous patch, we no longer have multiple
definitions in the final egl_gallium.so.
Cc: Chia-I Wu
Signed-off-by: Emil Velikov
---
src/gallium/targets/egl-static/Makefile.am | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/gallium/targets/egl
It makes more sense to link the core and common parts of the driver as the
target is build. Additionally this will help us drop duplicating symbols
for targets that static link mulitple pipe-drivers. Only egl-static needs
that currently with more to come.
To simplify things a bit add HAVE_GALLIUM_
Just fold libllvmradeon in libradeon.
Signed-off-by: Emil Velikov
---
src/gallium/drivers/r600/Makefile.am | 2 --
src/gallium/drivers/radeon/Makefile.am | 12
src/gallium/drivers/radeonsi/Makefile.am | 3 +--
3 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/s
Tom Stellard writes:
> https://bugs.freedesktop.org/show_bug.cgi?id=78581
>
> CC: "10.1 10.2"
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_t
A drawable size of 0x0 means that we don't have buffers for a drawable yet,
not that we have a zero-sized buffer. Core mesa shouldn't be optimizing out
drawing based on buffer size, since the draw call could be what triggers
the driver to go and get buffers. As discussed in the referenced bug rep
On Thu, Apr 3, 2014 at 15:46:01 +1100, Jonathan Gray wrote:
> OpenBSD does not have DT_NEEDED entries for libc by design,
> over concerns how the symbols would be referenced after
> changing the major version of the library.
>
> So avoid -no-undefined checks on OpenBSD as they will fail.
>
> v2
Commit 11623be934f85 was meant to have this hunk, which
I accidently dropped during git rebase.
Cc: 10.2
Signed-off-by: Emil Velikov
---
Thanks for catching this Julien.
Emil
configure.ac | 13 +
1 file changed, 13 insertions(+)
diff --git a/configure.ac b/configure.ac
index 99a
On Tue, May 13, 2014 at 01:23:03AM +0200, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > https://bugs.freedesktop.org/show_bug.cgi?id=78581
> >
> > CC: "10.1 10.2"
> > ---
> > src/gallium/state_trackers/clover/llvm/invocation.cpp | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff -
Hi, Ken,
Thanks for your patch.
But how do you release your driver on the HSW products? If can't LRI/LRM
from userspace batches, almost all of OpenCL application can't run.
So if I want to announce that the OpenCL driver support HSW, it must have a
way to load L3CTRLREG2 and L3CTRL
On Sat, May 10, 2014 at 10:41 AM, Emil Velikov wrote:
> The profiles are present depending on the defines at build time.
> Drop the extra functions and feed the defines directly into the
> state-tracker at build time.
Do you have other changes planned that require this one? The current
code deals
On Tue, May 13, 2014 at 7:15 AM, Emil Velikov wrote:
> With this and the previous patch, we no longer have multiple
> definitions in the final egl_gallium.so.
Looks good to me.
>
> Cc: Chia-I Wu
> Signed-off-by: Emil Velikov
> ---
> src/gallium/targets/egl-static/Makefile.am | 12 +---
>
From: Roland Scheidegger
gallivm_verify_function is the only caller of gallivm_optimize_function
and it already does this (except it's enabled there).
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 8
1 file changed, 8 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_i
From: Roland Scheidegger
All shaders had the same name.
We could probably use some identifier per shader too, but for now only use
the variant number.
---
src/gallium/auxiliary/draw/draw_llvm.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/gallium/au
From: Roland Scheidegger
Enabled with GALLIVM_DEBUG=perf (which up to now was only used to print
warnings for unoptimized code).
The output will look like this:
optimizing fs88_variant0_partial took 13541 msec
optimizing draw_llvm_shader took 21 msec
optimizing draw_llvm_shader_elts took 21 msec
From: Roland Scheidegger
The setup shaders were composed of both a fs shader number and a variant
number. But since they aren't tied to a particular fragment shader, the
former was a fixed zero while the latter was also always zero because
it was never assigned. So, similar to what the fs code do
From: Roland Scheidegger
Unused except it was increased for both fs and setup shader variants created.
Probably some leftover from ages ago.
---
src/gallium/drivers/llvmpipe/lp_context.c | 4
src/gallium/drivers/llvmpipe/lp_context.h | 10 +-
src/gallium/drivers/llvmpipe/lp
Hi Carl,
On Fri, May 2, 2014 at 1:44 AM, Carl Worth wrote:
> I've recently pushed an update to the 10.1 branch. I anticipate making a
> release from this branch tomorrow. The state of this branch is
> summarized here:
>
>
> http://cworth.org/~cworth/mesa-stable-queue/
>
> As always, pleas
From: Rob Clark
It wasn't completely clear from the docs, so I had to figure out by
looking at piglit results. Hopefully this saves the next driver writer
implementing queries some time.
Signed-off-by: Rob Clark
---
src/gallium/docs/source/context.rst | 4
1 file changed, 4 insertions(+)
On 13/05/14 02:57, Chia-I Wu wrote:
> On Sat, May 10, 2014 at 10:41 AM, Emil Velikov
> wrote:
>> The profiles are present depending on the defines at build time.
>> Drop the extra functions and feed the defines directly into the
>> state-tracker at build time.
> Do you have other changes planned
On 13.05.2014 01:40, Marek Olšák wrote:
> On Mon, May 12, 2014 at 9:54 AM, Michel Dänzer wrote:
>> On 07.05.2014 23:00, Marek Olšák wrote:
>>> From: Marek Olšák
>>>
>>> Only for Cayman, SI, CIK.
>>
>> [...]
>>
>>> diff --git a/src/gallium/drivers/radeon/r600d_common.h
>>> b/src/gallium/drivers/r
On Mon, May 12, 2014 at 10:02 AM, Yang, Rong R wrote:
> Hi, Ken,
>
> Thanks for your patch.
> But how do you release your driver on the HSW products? If can't LRI/LRM
> from userspace batches, almost all of OpenCL application can't run.
> So if I want to announce that the OpenCL drive
73 matches
Mail list logo
