Hi,
this is a resend of the earlier series to get weston / wayland_egl
working on etnaviv, now using SCR_INIT to wrap resource_changed only
if it is implemented by the wrapped pipe_screen.
regards
Philipp
Changes since v4:
- Added Christian's Reviewed-by tags
- Use SCR_INIT to initialize the
From: Nicolai Hähnle
---
src/gallium/drivers/r600/r600_shader.c | 59 ++
1 file changed, 59 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 5c4bc91..eaabb04 100644
---
From: Nicolai Hähnle
Reviewed-by: Marek Olšák
Reviewed-by: Iago Toral Quiroga
---
src/compiler/glsl/ir_optimization.h | 4 +++-
src/compiler/glsl/lower_instructions.cpp | 19 +++
2 files changed, 14
From: Nicolai Hähnle
Fixes GL45-CTS.gpu_shader_fp64.built_in_functions.
v2: use DDIV unconditionally
Reviewed-by: Roland Scheidegger (v1)
Reviewed-by: Marek Olšák (v1)
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 9
From: Nicolai Hähnle
It seems clear that trying to multiply two pairs of doubles would result
in the temporary register getting overwritten by the second pair. So
make the code more explicit.
---
src/gallium/drivers/r600/r600_shader.c | 36
From: Nicolai Hähnle
We will use it for DDIV.
---
src/gallium/drivers/r600/r600_shader.c | 62 +++---
1 file changed, 42 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
Hi all,
here's a v2 without the pipe cap. Reminder: this requires DDIV support in
nvc0, r600, and radeonsi.
Ilia took care of nvc0, and I already did radeonsi. The thing is, it turns
out I don't have an R600 that does double-precision. So testing would be
very much appreciated, e.g. using
Reviewed-by: Iago Toral Quiroga
On Thu, 2017-01-19 at 11:36 -0200, Alejandro Piñeiro wrote:
> When the attachment type is NONE (att->Type),
> FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE should be NONE always.
>
> Note that technically, the current behaviour follows the spec. From
>
On 01/19/2017 02:11 PM, Marek Olšák wrote:
On Thu, Jan 19, 2017 at 12:03 PM, Samuel Pitoiset
wrote:
On 01/19/2017 11:41 AM, Samuel Pitoiset wrote:
On 01/19/2017 11:29 AM, Samuel Pitoiset wrote:
On 01/19/2017 10:51 AM, Samuel Pitoiset wrote:
On
When the attachment type is NONE (att->Type),
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE should be NONE always.
Note that technically, the current behaviour follows the spec. From
OpenGL 4.5 spec, Section 9.2.3 "Framebuffer Object Queries":
"If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE,
CC: Francisco Jerez
CC: Kenneth Graunke
CC: Jason Ekstrand
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/genX_blorp_exec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=97967
Emil Velikov changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=98471
Bug 98471 depends on bug 97967, which changed state.
Bug 97967 Summary: glsl/tests/cache-test regression
https://bugs.freedesktop.org/show_bug.cgi?id=97967
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=99446
--- Comment #2 from Emil Velikov ---
Issue sounds like a old libvulkan. We might be able to workaround that in the
drivers, but the version used and a back trace (as mentioned by Bas) is needed.
--
You are receiving
On Thu, Jan 19, 2017 at 12:03 PM, Samuel Pitoiset
wrote:
>
>
> On 01/19/2017 11:41 AM, Samuel Pitoiset wrote:
>>
>>
>>
>> On 01/19/2017 11:29 AM, Samuel Pitoiset wrote:
>>>
>>>
>>>
>>> On 01/19/2017 10:51 AM, Samuel Pitoiset wrote:
On 01/18/2017
Hi Andy,
Am 19.01.2017 um 11:46 schrieb Andy Furniss:
I think you are right about the slices, the failing vids are blu-ray/tv.
https://drive.google.com/file/d/0BxP5-S1t9VEEZlozcjVUZ1lDbWM/view?usp=sharing
Thanks for the link, if you have time please give the attached patch a try.
It
On Wed, 2017-01-18 at 12:44 -0800, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez writes:
>
> > On Tue, 2017-01-17 at 13:26 -0800, Francisco Jerez wrote:
> > > Samuel Iglesias Gonsálvez writes:
> > >
> > > > From: "Juan A. Suarez Romero"
Acked-by: Edward O'Callaghan
On 01/18/2017 07:32 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> At least on VI, texture gather doesn't work with a 24_8 data format, so
> use 8_8_8_8 and a modified swizzle instead.
>
> A bit of
Reviewed-by: Edward O'Callaghan
On 01/19/2017 08:35 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> This should fix a coverity defect.
> ---
> src/gallium/drivers/radeonsi/si_state.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
Reviewed-by: Marek Olšák
Marek
On Wed, Jan 18, 2017 at 9:32 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> At least on VI, texture gather doesn't work with a 24_8 data format, so
> use 8_8_8_8 and a modified swizzle
The python code stores the integer match values to the 64-bit unsigned
field, so 32-bit values like 0xff00 don't get sign extended. However,
~0 gets printed as -0x1, so it does get stored as ~0ull.
To be able to match both ways that the python code generates integers,
cast the 64-bit int
This cuts 1 or 2 instructions in 3 different glmark2 tests.
---
src/compiler/nir/nir_opt_algebraic.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
index d7ad1f2fbf3f..1136bfe826b0 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=97879
himl...@gmx.de changed:
What|Removed |Added
CC||himl...@gmx.de
--
You are receiving
On 01/19/2017 11:41 AM, Samuel Pitoiset wrote:
On 01/19/2017 11:29 AM, Samuel Pitoiset wrote:
On 01/19/2017 10:51 AM, Samuel Pitoiset wrote:
On 01/18/2017 10:21 PM, Marek Olšák wrote:
From: Marek Olšák
This fixes VM faults. Discovered by Samuel Pitoiset.
Cc:
On 19/01/17 05:33, Iago Toral wrote:
> On Wed, 2017-01-18 at 16:48 -0200, Alejandro Piñeiro wrote:
>> When the attachment type is NONE (att->Type),
>> FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE should be NONE too.
>>
>> Note that technically, the current behaviour follows the spec. From
>> OpenGL 4.5
Christian König wrote:
Am 19.01.2017 um 00:20 schrieb Andy Furniss:
Nayan Deshmukh wrote:
On Tue, Jan 17, 2017 at 9:12 PM, Emil Velikov
wrote:
On 17 January 2017 at 14:55, Nayan Deshmukh
wrote:
On Tue, Jan 17, 2017 at 6:25 PM, Christian
On 01/19/2017 11:29 AM, Samuel Pitoiset wrote:
On 01/19/2017 10:51 AM, Samuel Pitoiset wrote:
On 01/18/2017 10:21 PM, Marek Olšák wrote:
From: Marek Olšák
This fixes VM faults. Discovered by Samuel Pitoiset.
Cc: 17.0 13.0
On 01/19/2017 10:51 AM, Samuel Pitoiset wrote:
On 01/18/2017 10:21 PM, Marek Olšák wrote:
From: Marek Olšák
This fixes VM faults. Discovered by Samuel Pitoiset.
Cc: 17.0 13.0
Bugzilla:
On 01/18/2017 10:21 PM, Marek Olšák wrote:
From: Marek Olšák
This fixes VM faults. Discovered by Samuel Pitoiset.
Cc: 17.0 13.0
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98975
---
Am 19.01.2017 um 10:07 schrieb Nayan Deshmukh:
PresentPixmap only works if the pixmap depth matches with the
window depth, otherwise it returns a BadMatch protocol error.
Even if the depths match, the result won't look correctly
if the VDPAU RGB component order doesn't match the X11 one so
we
On 01/19/2017 09:10 AM, Tapani Pälli wrote:
fixes to issues spotted by Emil Velikov:
- set ANV_TIMESTAMP corretly
- fix typo with VULKAN_GEM_FILES
v2: update to use Makefile.sources under vulkan
instead of having own
v3: update to changes to generate from vk.xml
(commit
PresentPixmap only works if the pixmap depth matches with the
window depth, otherwise it returns a BadMatch protocol error.
Even if the depths match, the result won't look correctly
if the VDPAU RGB component order doesn't match the X11 one so
we only allow the X11 format.
For other buffers we
2017-01-18 18:23 GMT+08:00 Józef Kucia :
> On Wed, Jan 18, 2017 at 2:25 AM, Boyan Ding wrote:
>> I don't think I find that. The only place in state tracker where
>> _mesa_add_renderbuffer is called is st_framebuffer_create and only one
>> of the
Am 19.01.2017 um 07:45 schrieb Michel Dänzer:
On 19/01/17 02:10 PM, Nayan Deshmukh wrote:
PresentPixmap only works if the pixmap depth and format matches
with the window, otherwise it returns a BadMatch protocol error.
Nitpick: PresentPixmap only returns BadMatch if the depths don't match.
It
PresentPixmap only works if the pixmap depth matches with the
window depth, otherwise it returns a BadMatch protocol error.
Even if the depths match, the result won't look correctly
if the VDPAU RGB component order doesn't match the X11 one so
we only allow the X11 format.
For other buffers we
On Thu, Jan 19, 2017 at 2:07 PM, Christian König
wrote:
> Am 19.01.2017 um 00:20 schrieb Andy Furniss:
>>
>> Nayan Deshmukh wrote:
>>>
>>> On Tue, Jan 17, 2017 at 9:12 PM, Emil Velikov
>>> wrote:
On 17 January 2017 at 14:55, Nayan
Am 19.01.2017 um 00:20 schrieb Andy Furniss:
Nayan Deshmukh wrote:
On Tue, Jan 17, 2017 at 9:12 PM, Emil Velikov
wrote:
On 17 January 2017 at 14:55, Nayan Deshmukh
wrote:
On Tue, Jan 17, 2017 at 6:25 PM, Christian König
Ah nice catch,
Reviewed-by: Edward O'Callaghan
On 01/19/2017 08:21 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> This fixes VM faults. Discovered by Samuel Pitoiset.
>
> Cc: 17.0 13.0
> ---
>
Reviewed-by: Nicolai Hähnle
On 18.01.2017 22:35, Marek Olšák wrote:
From: Marek Olšák
This should fix a coverity defect.
---
src/gallium/drivers/radeonsi/si_state.c | 5 +
1 file changed, 5 insertions(+)
diff --git
This is good news!
Reviewed-by: Nicolai Hähnle
On 18.01.2017 22:21, Marek Olšák wrote:
From: Marek Olšák
This fixes VM faults. Discovered by Samuel Pitoiset.
Cc: 17.0 13.0
---
101 - 140 of 140 matches
Mail list logo