Fixes regression on SSO tests that have both non-compute and
compute programs in a program pipeline.
Signed-off-by: Tapani Pälli
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93532
---
src/mesa/main/shader_query.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/mai
Patch changes linker to allocate gl_shader_variable instead of using
ir_variable. This makes it possible to get rid of ir_variables and ir
in memory after linking.
v2: check that we do not create duplicate entries with
packed varyings
v3: document 'patch' bit (Ilia Mirkin)
Signed-off-by: Tap
https://bugs.freedesktop.org/show_bug.cgi?id=93570
--- Comment #8 from Icenowy Zheng ---
It seems that the answer to the question above is "No". I changed to the
original fbdev DDX, and the problem is still here?
Is there any way to dump the binary code generate by llvm?
--
You are receiving t
https://bugs.freedesktop.org/show_bug.cgi?id=93570
--- Comment #7 from Icenowy Zheng ---
In addition, my DDX driver is https://github.com/ssvb/xf86-video-fbturbo, which
uses neon to accelerate operations such as bitblit .
--
You are receiving this mail because:
You are the QA Contact for the bu
On 12/30/2015 09:53 PM, Marek Olšák wrote:
On Mon, Nov 2, 2015 at 10:12 AM, Tapani Pälli wrote:
On 11/02/2015 09:16 AM, Ilia Mirkin wrote:
On Mon, Nov 2, 2015 at 1:58 AM, Tapani Pälli
wrote:
Patch changes linker to allocate gl_shader_variable instead of using
ir_variable. This makes it
On 01/03/2016 08:48 AM, Francisco Jerez wrote:
> The RS and hardware binding tables are only supported on the 3D
> pipeline and can lead to corruption if left enabled during a GPGPU
> workload. Disable it when switching to the GPGPU (or media) pipeline
> and re-enable it when switching back to t
https://bugs.freedesktop.org/show_bug.cgi?id=93570
--- Comment #6 from Icenowy Zheng ---
My CPU (Cortex-A7) *do* has neon. All A7 cores have neon.
I used llvm-3.7, and I'm now building llvm-svn (used
https://github.com/llvm-mirror/llvm)
Note: you can run a glmark2 and compare the image to the o
Am 04.01.2016 um 02:05 schrieb Ilia Mirkin:
> On Sun, Jan 3, 2016 at 7:51 PM, Roland Scheidegger wrote:
>> Am 03.01.2016 um 21:32 schrieb Ilia Mirkin:
>>> On Sun, Jan 3, 2016 at 2:15 PM, Ilia Mirkin wrote:
On Sun, Jan 3, 2016 at 2:08 PM, Roland Scheidegger
wrote:
>>> For the serie
On Sun, Jan 3, 2016 at 8:37 PM, Roland Scheidegger wrote:
> Am 03.01.2016 um 22:29 schrieb Ilia Mirkin:
>> This hits assertion failures on LLVM 3.5
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> It definitely worked at one point or another, but it might have been with
>> a later LLVM version and/o
Am 03.01.2016 um 22:29 schrieb Ilia Mirkin:
> This hits assertion failures on LLVM 3.5
>
> Signed-off-by: Ilia Mirkin
> ---
>
> It definitely worked at one point or another, but it might have been with
> a later LLVM version and/or on a different CPU. On my i7-920 with LLVM 3.5
> I definitely ge
Am 03.01.2016 um 22:29 schrieb Ilia Mirkin:
> It seems like there's something horribly wrong with the
> util_float_to_half function. In a standalone compilation it works fine
> for -6.10203e-05, generating 0x8400, but inside mesa it ends up with
> 0x8000. The result of the magic.f multiplication is
On Sun, Jan 3, 2016 at 7:51 PM, Roland Scheidegger wrote:
> Am 03.01.2016 um 21:32 schrieb Ilia Mirkin:
>> On Sun, Jan 3, 2016 at 2:15 PM, Ilia Mirkin wrote:
>>> On Sun, Jan 3, 2016 at 2:08 PM, Roland Scheidegger
>>> wrote:
>> For the series (with the first point addressed either way,though
Am 03.01.2016 um 21:32 schrieb Ilia Mirkin:
> On Sun, Jan 3, 2016 at 2:15 PM, Ilia Mirkin wrote:
>> On Sun, Jan 3, 2016 at 2:08 PM, Roland Scheidegger
>> wrote:
> For the series (with the first point addressed either way,though a tgsi
> exec implementation which should be trivial wouldn'
Kenneth Graunke writes:
> On Saturday, January 2, 2016 10:48:02 PM PST Francisco Jerez wrote:
>> Switching the current pipeline while it's not completely idle or the
>> read and write caches aren't flushed can lead to corruption. Fixes
>> misrendering of at least the following Khronos CTS test:
Based off of Ilia's original patch, but with output values replicated so
that it matches the TGSI semantics.
Signed-off-by: Glenn Kennard
---
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 107 +++--
2 files changed, 104 inse
On Saturday, January 2, 2016 10:48:03 PM PST Francisco Jerez wrote:
> AFAIK brw_emit_select_pipeline() is only called once during context
> init on Gen4-5, at which point the pipeline is likely to be already
> idle so it may just happen to work by luck regardless of the MI_FLUSH.
> ---
> src/mesa/
On Saturday, January 2, 2016 10:48:02 PM PST Francisco Jerez wrote:
> Switching the current pipeline while it's not completely idle or the
> read and write caches aren't flushed can lead to corruption. Fixes
> misrendering of at least the following Khronos CTS test:
>
> ES31-CTS.shader_image_loa
On Saturday, January 2, 2016 10:48:01 PM PST Francisco Jerez wrote:
> This hardware bug can cause a hang on context restore while the
> current pipeline is set to GPGPU (BDWGFX HSD 1909593). In addition to
> clearing the valid bit, mark the CC state as dirty to make sure that
> the CC indirect sta
This hits assertion failures on LLVM 3.5
Signed-off-by: Ilia Mirkin
---
It definitely worked at one point or another, but it might have been with
a later LLVM version and/or on a different CPU. On my i7-920 with LLVM 3.5
I definitely get assertion errors from inside LLVM. Any interested party
ca
It seems like there's something horribly wrong with the
util_float_to_half function. In a standalone compilation it works fine
for -6.10203e-05, generating 0x8400, but inside mesa it ends up with
0x8000. The result of the magic.f multiplication is 0. No idea why.
Signed-off-by: Ilia Mirkin
---
S
Glenn (or anyone else interested in r600): feel free to take this
patch over. I've pushed the core (and nvc0) support, but due to
Roland's feedback I changed the return values to be replicated(ish),
not 100% sure how to do that and it seems best to leave it to you.
On Sat, Jan 2, 2016 at 7:38 PM,
On Sun, Jan 3, 2016 at 2:15 PM, Ilia Mirkin wrote:
> On Sun, Jan 3, 2016 at 2:08 PM, Roland Scheidegger wrote:
For the series (with the first point addressed either way,though a tgsi
exec implementation which should be trivial wouldn't hurt neither)
Reviewed-by: Roland Scheidegger
https://bugs.freedesktop.org/show_bug.cgi?id=93570
--- Comment #5 from Roland Scheidegger ---
This looks rather interesting, like a shuffle gone wrong (always affects the
same 3 pixel in 4x4 pixel stamp). This chip does have NEON instructions right?
I think llvm used to have quite some problems i
Am 03.01.2016 um 19:20 schrieb Oded Gabbay:
> On Sun, Jan 3, 2016 at 8:14 PM, Roland Scheidegger wrote:
>> Am 03.01.2016 um 13:50 schrieb Oded Gabbay:
>>> On Thu, Dec 31, 2015 at 8:48 PM, Roland Scheidegger
>>> wrote:
Am 31.12.2015 um 10:30 schrieb Oded Gabbay:
> On Wed, Dec 30, 2015 at
On Sun, Jan 3, 2016 at 2:08 PM, Roland Scheidegger wrote:
>>> For the series (with the first point addressed either way,though a tgsi
>>> exec implementation which should be trivial wouldn't hurt neither)
>>> Reviewed-by: Roland Scheidegger
>>
>> Thanks! I'll do a patch for that shortly (tgsi_exe
Am 03.01.2016 um 19:02 schrieb Ilia Mirkin:
> On Sun, Jan 3, 2016 at 12:33 PM, Roland Scheidegger
> wrote:
>> Am 03.01.2016 um 01:37 schrieb Ilia Mirkin:
>>> Signed-off-by: Ilia Mirkin
>>> ---
>>> src/gallium/docs/source/tgsi.rst | 10 --
>>> 1 file changed, 8 insertions(+), 2 deletions
https://bugs.freedesktop.org/show_bug.cgi?id=93570
--- Comment #4 from Icenowy Zheng ---
Of course I am not benchmarking.
But the image *do* misrenders.
It will take me days of time to build a llvm and mesa combination, and may fail
(as my device has only 512MB RAM)
--
You are receiving this m
On Sun, Jan 3, 2016 at 8:14 PM, Roland Scheidegger wrote:
> Am 03.01.2016 um 13:50 schrieb Oded Gabbay:
>> On Thu, Dec 31, 2015 at 8:48 PM, Roland Scheidegger
>> wrote:
>>> Am 31.12.2015 um 10:30 schrieb Oded Gabbay:
On Wed, Dec 30, 2015 at 5:41 PM, Roland Scheidegger
wrote:
> Am
Am 03.01.2016 um 13:50 schrieb Oded Gabbay:
> On Thu, Dec 31, 2015 at 8:48 PM, Roland Scheidegger
> wrote:
>> Am 31.12.2015 um 10:30 schrieb Oded Gabbay:
>>> On Wed, Dec 30, 2015 at 5:41 PM, Roland Scheidegger
>>> wrote:
Am 30.12.2015 um 10:46 schrieb Oded Gabbay:
> On Wed, Dec 30, 201
https://bugs.freedesktop.org/show_bug.cgi?id=93570
--- Comment #3 from Ilia Mirkin ---
A fairer comparison would be
LIBGL_ALWAYS_SOFTWARE=1 LP_NATIVE_VECTOR_WIDTH=128
Since I assume it will otherwise use 256-bit wide vectors on your intel CPU.
But it appears that the rendering is actually incor
https://bugs.freedesktop.org/show_bug.cgi?id=93570
Ilia Mirkin changed:
What|Removed |Added
Attachment #120782|text/plain |image/jpeg
mime type|
Matt Turner writes:
> On Sun, Jan 3, 2016 at 1:48 AM, Francisco Jerez wrote:
>> This hardware bug can cause a hang on context restore while the
>> current pipeline is set to GPGPU (BDWGFX HSD 1909593). In addition to
>> clearing the valid bit, mark the CC state as dirty to make sure that
>> the
On 01/03/2016 07:03 PM, Ilia Mirkin wrote:
Reviewed-by: Ilia Mirkin
Can you guess where I copy-pasted these from? :)
Two lines above? :-)
On Sun, Jan 3, 2016 at 12:47 PM, Samuel Pitoiset
wrote:
Cc: Ilia Mirkin
Signed-off-by: Samuel Pitoiset
---
src/mesa/state_tracker/st_program.h |
Reviewed-by: Ilia Mirkin
Can you guess where I copy-pasted these from? :)
On Sun, Jan 3, 2016 at 12:47 PM, Samuel Pitoiset
wrote:
> Cc: Ilia Mirkin
> Signed-off-by: Samuel Pitoiset
> ---
> src/mesa/state_tracker/st_program.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>
On Sun, Jan 3, 2016 at 12:33 PM, Roland Scheidegger wrote:
> Am 03.01.2016 um 01:37 schrieb Ilia Mirkin:
>> Signed-off-by: Ilia Mirkin
>> ---
>> src/gallium/docs/source/tgsi.rst | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/docs/source/tgsi.rs
Cc: Ilia Mirkin
Signed-off-by: Samuel Pitoiset
---
src/mesa/state_tracker/st_program.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_program.h
b/src/mesa/state_tracker/st_program.h
index a8571f0..a745315 100644
--- a/src/mesa/state_tracker
https://bugs.freedesktop.org/show_bug.cgi?id=93570
--- Comment #2 from Icenowy Zheng ---
icenowy [ ~ ] ! glmark2 -b build
libGL error: unable to load driver: mali_drm_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: mali_drm
** GLX does not support GLX_EXT_swap_contr
Am 03.01.2016 um 01:37 schrieb Ilia Mirkin:
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/docs/source/tgsi.rst | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/docs/source/tgsi.rst
> b/src/gallium/docs/source/tgsi.rst
> index 955ece8..f69998f 10
https://bugs.freedesktop.org/show_bug.cgi?id=93570
--- Comment #1 from Icenowy Zheng ---
The attachment is a jpg, shoot by my mobile phone
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=93570
Bug ID: 93570
Summary: the image of llvmpipe has a low quality on arm (with
too many points on it)
Product: Mesa
Version: 11.0
Hardware: ARM
OS: Linux (All)
On Sun, Jan 3, 2016 at 1:47 AM, Francisco Jerez wrote:
> The PIPELINE_SELECT command has a number of awkward restrictions we
> don't currently take into account while switching between the GPGPU
> and 3D pipeline, what in some cases can lead to corruption or hangs.
> This series should implement a
On Sun, Jan 3, 2016 at 1:48 AM, Francisco Jerez wrote:
> This hardware bug can cause a hang on context restore while the
> current pipeline is set to GPGPU (BDWGFX HSD 1909593). In addition to
> clearing the valid bit, mark the CC state as dirty to make sure that
> the CC indirect state pointer i
This patch converts the SSE-optimized lp_rast_triangle_32_3_16()
to VMX/VSX.
I measured the results on POWER8 machine with 32 cores at 3.4GHz and
16GB of RAM.
FPS/Score
NameBefore AfterDelta
openarena
To determine if we could use special POWER8 assembly directives, we first
need to detect whether we are running on POWER8 architecture. This patch
adds this detection to configure.ac and adds the necessary compilation
flags accordingly.
v2:
- Add option to disable POWER8 instructions generation
-
This patch converts the SSE-optimized build_mask_32() and
build_mask_linear_32() to VMX/VSX.
I measured the results on POWER8 machine with 32 cores at 3.4GHz and
16GB of RAM.
FPS/Score
NameBefore AfterDelta
--
Hi,
Here is the 2nd version of the patch series. The main change is that the new
code is limited to POWER8 Little-Endian machines, due to a special compiler
flag (power8-vector) that must bu turned on but creates code that can't run
on POWER7 machines.
As only POWER8 has an LE mode (ppc64le),
This file provides a portability layer that will make it easier to convert
SSE-based functions to VMX/VSX-based functions.
All the functions implemented in this file are prefixed using "vec_".
Therefore, when converting from SSE-based function, one needs to simply
replace the "_mm_" prefix of the
This patch converts the SSE optimization done in do_triangle_ccw to
VMX/VSX.
I measured the results on POWER8 machine with 32 cores at 3.4GHz and
16GB of RAM.
FPS/Score
NameBefore AfterDelta
glmark2 (scor
On Thu, Dec 31, 2015 at 8:48 PM, Roland Scheidegger wrote:
> Am 31.12.2015 um 10:30 schrieb Oded Gabbay:
>> On Wed, Dec 30, 2015 at 5:41 PM, Roland Scheidegger
>> wrote:
>>> Am 30.12.2015 um 10:46 schrieb Oded Gabbay:
On Wed, Dec 30, 2015 at 1:11 AM, Roland Scheidegger
wrote:
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=75165
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Sat, Jan 2, 2016 at 11:01 PM, Nicolai Hähnle wrote:
> What's the reason for always having +DumpCode? Generating the assembly is
> some overhead that's usually unnecessary. Even if it's a small part of the
> profiles I've seen, it still seems like a natural thing to just skip. From
> what I can
Reviewed-by: Samuel Pitoiset
On 01/03/2016 01:38 AM, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 1 +
.../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 5 -
.../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 23 +
52 matches
Mail list logo
