Looks good. For the series:
Reviewed-by: Timothy Arceri
On 03/03/18 01:01, Samuel Pitoiset wrote:
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c| 23 +++
src/amd/common/ac_llvm_build.h| 3 +++
src/amd/common/ac_ni
2599b92eb97 changed Mesa's behavior to allow Compatiblity profile with
3.1, and fail when the driver doesn't implement it, if the Core
profile is not requested by applications.
Formerly, when requesting a 3.1 Compatibility profile Mesa would
always fall back into a Core profile. We go back to that
Quoting Emil Velikov (2018-03-02 17:45:29)
> [Moving the thread from wayland-devel to mesa-dev]
>
> On 2 March 2018 at 15:03, Chris Wilson wrote:
> > Quoting Emil Velikov (2018-03-02 14:52:28)
> >> Hi Chris,
> >>
> >> On 1 March 2018 at 08:28, Chris Wilson wrote:
> >> > EGL_IMG_context_priority
Like the r600 paths to use other custom states, we pass in a couple of
parameters to customize the innards of the blitter. It's up to the caller
to wrap other state necessary for its shaders (for example, constant
buffers for the uniforms the shader uses).
---
src/gallium/auxiliary/util/u_blitter
Drawing a 1080p YV12 video stream generated by MMAL goes from 10.5 FPS to
36.
---
src/gallium/drivers/vc4/vc4_blit.c| 200 ++
src/gallium/drivers/vc4/vc4_context.c | 7 ++
src/gallium/drivers/vc4/vc4_context.h | 4 +
3 files changed, 211 insertions(+)
diff
Hi Alex,
How many do you need of either type?
- Bas
On Fri, Mar 2, 2018 at 4:28 PM, Alex Smith wrote:
> These were set to MAX_DYNAMIC_BUFFERS / 2, which is too restrictive
> since an app may have it's total usage of both uniform and storage
> within MAX_DYNAMIC_BUFFERS, but exceed the limit for
Emil Velikov writes:
> On 22 February 2018 at 19:23, Emil Velikov wrote:
>> Hi Anuj,
>>
>> On 7 February 2018 at 01:09, Anuj Phogat wrote:
>>> Commit bit in the message descriptor (Bit 13) must be always set
>>> to true in CNL+ for memory fence messages. It also fixes a piglit
>>> GPU hang on c
https://bugs.freedesktop.org/show_bug.cgi?id=105328
Sebastian Dröge (slomo) changed:
What|Removed |Added
CC||sl...@coaxion.net
--
You are
Quoting Emil Velikov (2018-03-02 10:44:04)
> On 2 March 2018 at 18:30, Dylan Baker wrote:
> > Fixes: d1992255bb29054fa51763376d125183a9f602f3
> >("meson: Add build Intel "anv" vulkan driver")
> > Signed-off-by: Dylan Baker
> > ---
> > include/meson.build | 4
> > 1 file changed, 4 i
On 2 March 2018 at 18:30, Dylan Baker wrote:
> Fixes: d1992255bb29054fa51763376d125183a9f602f3
>("meson: Add build Intel "anv" vulkan driver")
> Signed-off-by: Dylan Baker
> ---
> include/meson.build | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/meson.build b/inclu
Hi Alex,
On 28 February 2018 at 15:25, Alex Smith wrote:
> Hi,
>
> Could this (commit 5d61fa4e68b7eb6d481a37efdbb35fdce675a6ad on master) be
> backported to the 17.3 branch to allow it to build with LLVM 6?
>
Normally we don't aim to support LLVM versions released after the .0
Mesa release is out
Emil Velikov writes:
> Hi Aaron,
>
> On 1 March 2018 at 19:44, Aaron Watry wrote:
>> Useful for testing API, builtin library, and device completeness of
>> not-yet-supported versions.
>>
> Small fly-by comment:
>
> As-is it seems like getenv(foo) will be called multiple times.
> Perhaps it isn't
Fixes: d1992255bb29054fa51763376d125183a9f602f3
("meson: Add build Intel "anv" vulkan driver")
Signed-off-by: Dylan Baker
---
include/meson.build | 4
1 file changed, 4 insertions(+)
diff --git a/include/meson.build b/include/meson.build
index 28ffb332151..2c2467edb81 100644
--- a/in
On 2 March 2018 at 16:52, Dylan Baker wrote:
> Quoting Emil Velikov (2018-03-02 06:26:43)
>> On 1 March 2018 at 19:34, Dylan Baker wrote:
>> > Meson is pretty well tested and works in most configurations now, so we
>> > can remove the warning about it being unsuited for actual use.
>> >
>> > It's
https://bugs.freedesktop.org/show_bug.cgi?id=105291
--- Comment #5 from Roland Scheidegger ---
(In reply to Gert Wollny from comment #4)
> The shader doesn't use many registers, even un-optimized the number is below
> 100, so spilling doesn't occur and beyond that I don't see any option to
> opti
Otherwise SWR cannot be built with meson from an autotools generated
tarball, such as the 18.0.0-rc4 tarball.
CC: George Kyriazis
CC: Emil Velikov
Fixes: 16bf81383080 ("meson/swr: re-shuffle generated files")
Signed-off-by: Dylan Baker
---
src/gallium/drivers/swr/Makefile.am | 2 ++
1 file cha
[Moving the thread from wayland-devel to mesa-dev]
On 2 March 2018 at 15:03, Chris Wilson wrote:
> Quoting Emil Velikov (2018-03-02 14:52:28)
>> Hi Chris,
>>
>> On 1 March 2018 at 08:28, Chris Wilson wrote:
>> > EGL_IMG_context_priority allows the client to request that their
>> > rendering be c
https://bugs.freedesktop.org/show_bug.cgi?id=105328
--- Comment #4 from Brian Paul ---
(In reply to Brian Paul from comment #2)
> Evidently, the problem with the 32-bit build is that ptrdiff_t is not
> equivalent to signed long int.
>
> This hack works for me:
>
> #include
> #include
> #defin
On Friday, 2018-03-02 13:03:02 +, Stefan Dirsch wrote:
> On Fri, Mar 02, 2018 at 01:39:40PM +0100, Gustaw Smolarczyk wrote:
> > 2018-03-02 12:59 GMT+01:00 Stefan Dirsch :
> >
> > On Fri, Mar 02, 2018 at 11:47:57AM +, Eric Engestrom wrote:
> > > On Friday, 2018-03-02 12:25:11 +0100,
Yes.
Marek
On Wed, Feb 28, 2018 at 10:25 AM, Alex Smith
wrote:
> Hi,
>
> Could this (commit 5d61fa4e68b7eb6d481a37efdbb35fdce675a6ad on master) be
> backported to the 17.3 branch to allow it to build with LLVM 6?
>
> Thanks,
> Alex
>
> On 6 November 2017 at 21:16, Marek Olšák wrote:
>>
>> Revie
On Thursday, 2018-03-01 11:34:18 -0800, Dylan Baker wrote:
> Meson is pretty well tested and works in most configurations now, so we
> can remove the warning about it being unsuited for actual use.
>
> It's also worth documenting that meson 0.42.0 or greater is required.
>
> Signed-off-by: Dylan
https://bugs.freedesktop.org/show_bug.cgi?id=105328
--- Comment #3 from Eric Engestrom ---
As Ilia mentioned, these headers come directly from Khronos; I've just raised a
ticket with your issue there
(https://github.com/KhronosGroup/OpenGL-Registry/issues/162), but to answer
your question: yes, s
https://bugs.freedesktop.org/show_bug.cgi?id=105328
--- Comment #2 from Brian Paul ---
Evidently, the problem with the 32-bit build is that ptrdiff_t is not
equivalent to signed long int.
This hack works for me:
#include
#include
#define GL_VERSION_1_5
#include
int main (int argc, char **ar
Reviewed-by: Charmaine Lee
From: Brian Paul
Sent: Wednesday, February 28, 2018 7:29 AM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH] svga: fix blending regression
The earlier Mesa commit 3d06c8afb5 ("st/mesa: don't tr
Quoting Emil Velikov (2018-03-02 06:26:43)
> On 1 March 2018 at 19:34, Dylan Baker wrote:
> > Meson is pretty well tested and works in most configurations now, so we
> > can remove the warning about it being unsuited for actual use.
> >
> > It's also worth documenting that meson 0.42.0 or greater
From: Boyuan Zhang
Previous patch missed a "return" when trying to modify the create encoder
function, which made the whole logic fail. Therefore, add the return back.
Fixes: b38b208ff8886e799d6a2 "radeonsi:create uvd hevc enc entry"
Signed-off-by: Boyuan Zhang
Reviewed-by: Alex Deucher
Revie
Quoting Matt Turner (2018-03-01 21:36:14)
> On Thu, Mar 1, 2018 at 11:34 AM, Dylan Baker wrote:
> > Meson is pretty well tested and works in most configurations now, so we
> > can remove the warning about it being unsuited for actual use.
> >
> > It's also worth documenting that meson 0.42.0 or gr
Quoting Stefan Dirsch (2018-03-02 02:49:37)
> On Thu, Mar 01, 2018 at 09:00:38AM -0800, Dylan Baker wrote:
> > Quoting sndir...@suse.de (2018-03-01 08:11:54)
> > > From: Stefan Dirsch
> > >
> > > Patch by "Tomas Chvatal" with modifications
> > > by "Michal Srb" to not break python 2.
> > >
> >
Quoting Stefan Dirsch (2018-03-02 05:02:10)
> On Fri, Mar 02, 2018 at 01:39:40PM +0100, Gustaw Smolarczyk wrote:
> > 2018-03-02 12:59 GMT+01:00 Stefan Dirsch :
> >
> > On Fri, Mar 02, 2018 at 11:47:57AM +, Eric Engestrom wrote:
> > > On Friday, 2018-03-02 12:25:11 +0100, Stefan Dirsch
On 2018-02-28 08:44 AM, Leo Liu wrote:
Boyuan, please also make sure whether this patch along with other one
are needed to Cc stable or not.
Regards,
Leo
Thanks. I double checked the 18.0 and 17.3 branch, the previous hevc
encode related patch sets are not in there yet. So seems we don't n
Am 02.03.2018 um 17:28 schrieb boyuan.zh...@amd.com:
From: Boyuan Zhang
Profile and entry point were missing in the picture structure.
Therefore, add them back.
Signed-off-by: Boyuan Zhang
Reviewed-by: Leo Liu
Reviewed-by: Christian König
---
src/gallium/state_trackers/omx_bellagio/vi
From: Boyuan Zhang
Profile and entry point were missing in the picture structure.
Therefore, add them back.
Signed-off-by: Boyuan Zhang
Reviewed-by: Leo Liu
---
src/gallium/state_trackers/omx_bellagio/vid_enc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/state_trackers/o
https://bugs.freedesktop.org/show_bug.cgi?id=105328
Tim Müller changed:
What|Removed |Added
CC||t...@centricular.net
--
You are receiving
Am 02.03.2018 um 08:41 schrieb Jose Fonseca:
> On 02/03/18 02:23, Brian Paul wrote:
>> On 03/01/2018 07:01 PM, srol...@vmware.com wrote:
>>> From: Roland Scheidegger
>>>
>>> The comment said it will only represent the lowest 32 regs. This was
>>> not entirely true in practice, since at least on x8
https://bugs.freedesktop.org/show_bug.cgi?id=105328
--- Comment #1 from Ilia Mirkin ---
GL headers come from Khronos and are (should be) standard across all GL
implementations.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=105328
Bug ID: 105328
Summary: Can't include gl and gles headers simultaneously on
non-64 bit architectures
Product: Mesa
Version: git
Hardware: Other
OS: All
These were set to MAX_DYNAMIC_BUFFERS / 2, which is too restrictive
since an app may have it's total usage of both uniform and storage
within MAX_DYNAMIC_BUFFERS, but exceed the limit for one of the types.
Recently the validation layers have started raising errors for when
these limits are exceede
On 02/28/2018 10:50 PM, mathias.froehl...@gmx.net wrote:
From: Mathias Fröhlich
Hi Brian,
that's what I mentioned yesterday.
You may want to test this change against your use cases of your recent
draw primitive optimization.
With one openscenegraph dlist based workload this change improves the
On 1 March 2018 at 19:34, Dylan Baker wrote:
> Meson is pretty well tested and works in most configurations now, so we
> can remove the warning about it being unsuited for actual use.
>
> It's also worth documenting that meson 0.42.0 or greater is required.
>
> Signed-off-by: Dylan Baker
> ---
>
Hi Aaron,
On 1 March 2018 at 19:44, Aaron Watry wrote:
> Useful for testing API, builtin library, and device completeness of
> not-yet-supported versions.
>
Small fly-by comment:
As-is it seems like getenv(foo) will be called multiple times.
Perhaps it isn't that 'slow' since it's not a hot path
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c| 23 +++
src/amd/common/ac_llvm_build.h| 3 +++
src/amd/common/ac_nir_to_llvm.c | 27 ++-
src/gallium/drivers/radeonsi/si_shader_tgsi_al
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c| 22 ++
src/amd/common/ac_llvm_build.h| 3 ++
src/amd/common/ac_nir_to_llvm.c | 35 ++-
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c |
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c| 23
src/amd/common/ac_llvm_build.h| 3 +++
src/amd/common/ac_nir_to_llvm.c | 26 ++-
src/gallium/drivers/radeonsi/si_shader_tgsi_a
On 2 March 2018 at 13:25, Andres Gomez wrote:
> This way we won't fail when validating just because we may have a non
> overriden core version that is lower than the requested one, even when
> the compat version is high enough.
>
> For example, running glcts from VK-GL-CTS with i965, this will
> s
On 2 March 2018 at 11:51, Eric Engestrom wrote:
> On Friday, 2018-03-02 13:28:28 +0200, Andres Gomez wrote:
>> Found by inspection.
>>
>> Cc: Ian Romanick
>> Cc: Emil Velikov
>> Cc: Eric Engestrom
>> Signed-off-by: Andres Gomez
>> ---
>> src/egl/main/eglcontext.c | 1 -
>> 1 file changed, 1 d
On Fri, Mar 02, 2018 at 01:31:22PM +, Emil Velikov wrote:
> On 2 March 2018 at 11:29, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
> > support for this bus in order to allow use of the DRI_PRIME environment
> >
On 2 March 2018 at 13:02, Andres Gomez wrote:
> Fixes: 03fd6704db9 ("mesa: Add support for a new override string
> MESA_GLES_VERSION_OVERRIDE")
>
> Cc: Jordan Justen
> Cc: Ian Romanick
> Signed-off-by: Andres Gomez
> ---
> src/mesa/main/version.c | 10 --
> 1 file changed, 8 insertions
On 2 March 2018 at 11:29, Thierry Reding wrote:
> From: Thierry Reding
>
> ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
> support for this bus in order to allow use of the DRI_PRIME environment
> variable with those devices.
>
> While at it, also support the host1x bus,
Hey Marek,
you can have my
Tested-by: Kai Wasserbäch
for this patch.
Test case: updating libLLVM.so without rebuilding Mesa or building a new kernel
caused a white screen (plus correctly show mouse cursor) on the next launch of
SDDM. Deleting the mesa_shader_cache and qtshadercache directories
On 03/01/2018 02:30 PM, Boyuan Zhang wrote:
Agree, I added the missing profile and entry_point to st/omx.
Please see the attached patch below.
On radeon driver side, do you think we should still check the profile
in encoder instead since profile shouldn't been changed during encoding.
Or we ca
This way we won't fail when validating just because we may have a non
overriden core version that is lower than the requested one, even when
the compat version is high enough.
For example, running glcts from VK-GL-CTS with i965, this will
succeed:
$ MESA_GL_VERSION_OVERRIDE=4.6 ./glcts --deqp-cas
On Thu, Mar 01, 2018 at 09:10:39AM -0800, Dylan Baker wrote:
> Quoting Thierry Reding (2018-03-01 05:54:53)
> > --- /dev/null
> > +++ b/src/gallium/winsys/tegra/drm/meson.build
> > @@ -0,0 +1,33 @@
> > +# Copyright © 2018 NVIDIA CORPORATION
> > +
> > +# Permission is hereby granted, free of charge,
a0c8b49284e enabled the OpenGL 3.1 compat profile. Hence, when setting
MESA_GL_VERSION_OVERRIDE=3.1 we want to keep the compat profile, as it
already happens with <= 3.0.
Additionally, update and add some extra comments on the overriding
function.
Fixes: a0c8b49284e ("mesa: enable OpenGL 3.1 with
Fixes: 2599b92eb97 ("mesa: allow forcing >=3.1 compatibility contexts
with MESA_GL_VERSION_OVERRIDE")
Cc: Marek Olšák
Cc: Jordan Justen
Cc: Ian Romanick
Cc: Eric Engestrom
Cc: Emil Velikov
Signed-off-by: Andres Gomez
---
docs/envvars.html | 6 --
src/mesa/main/version.c | 1 +
2 f
Fixes: 03fd6704db9 ("mesa: Add support for a new override string
MESA_GLES_VERSION_OVERRIDE")
Cc: Jordan Justen
Cc: Ian Romanick
Signed-off-by: Andres Gomez
---
src/mesa/main/version.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/version.c b/src/
A small series mostly adding up to date documentation for
MESA_GL_VERSION_OVERRIDE.
Additionally, patch 1/3 keeps OpenGL 3.1 compat profile when setting
MESA_GL_VERSION_OVERRIDE=3.1, after the behavior change done at
a0c8b49284e.
Andres Gomez (3):
mesa: override to GL core API only when >= 3.2
On Fri, Mar 02, 2018 at 01:39:40PM +0100, Gustaw Smolarczyk wrote:
> 2018-03-02 12:59 GMT+01:00 Stefan Dirsch :
>
> On Fri, Mar 02, 2018 at 11:47:57AM +, Eric Engestrom wrote:
> > On Friday, 2018-03-02 12:25:11 +0100, Stefan Dirsch wrote:
> > > On Fri, Mar 02, 2018 at 11:03:53AM +0
On Fri, Mar 02, 2018 at 12:28:02PM +, Daniel Stone wrote:
> Hi,
>
> On 2 March 2018 at 12:06, Thierry Reding wrote:
> > On Thu, Mar 01, 2018 at 09:37:28AM -0500, Ilia Mirkin wrote:
> >> > +static void
> >> > +nvc0_query_dmabuf_modifiers(struct pipe_screen *screen,
> >> > +
On Thu, Mar 01, 2018 at 09:41:37AM -0500, Ilia Mirkin wrote:
> Is this substantially different than the renderonly helper? i.e. could
> you reuse it somehow? (If not, that's fine too, just asking.)
Yeah, this is fairly different from renderonly in that it completely
wraps another driver. renderonl
2018-03-02 12:59 GMT+01:00 Stefan Dirsch :
> On Fri, Mar 02, 2018 at 11:47:57AM +, Eric Engestrom wrote:
> > On Friday, 2018-03-02 12:25:11 +0100, Stefan Dirsch wrote:
> > > On Fri, Mar 02, 2018 at 11:03:53AM +, Eric Engestrom wrote:
> > > > On Friday, 2018-03-02 11:41:00 +0100, Stefan Dir
Hi,
On 2 March 2018 at 12:06, Thierry Reding wrote:
> On Thu, Mar 01, 2018 at 09:37:28AM -0500, Ilia Mirkin wrote:
>> > +static void
>> > +nvc0_query_dmabuf_modifiers(struct pipe_screen *screen,
>> > +enum pipe_format format, int max,
>>
>> Maybe change this to "unsign
On Thu, Mar 01, 2018 at 09:04:58AM -0800, Dylan Baker wrote:
> Quoting Thierry Reding (2018-03-01 05:54:52)
> > From: Thierry Reding
> >
> > This adds support for framebuffer modifiers to Nouveau. This will be
> > used by the Tegra driver to share metadata about the format of buffers
> > (such as
On Thu, Mar 01, 2018 at 09:37:28AM -0500, Ilia Mirkin wrote:
> On Thu, Mar 1, 2018 at 8:54 AM, Thierry Reding
> wrote:
> > From: Thierry Reding
> >
> > This adds support for framebuffer modifiers to Nouveau. This will be
> > used by the Tegra driver to share metadata about the format of buffers
On Fri, Mar 02, 2018 at 11:47:57AM +, Eric Engestrom wrote:
> On Friday, 2018-03-02 12:25:11 +0100, Stefan Dirsch wrote:
> > On Fri, Mar 02, 2018 at 11:03:53AM +, Eric Engestrom wrote:
> > > On Friday, 2018-03-02 11:41:00 +0100, Stefan Dirsch wrote:
> > > > Patch by "Tomas Chvatal" with mo
On Friday, 2018-03-02 13:28:28 +0200, Andres Gomez wrote:
> Found by inspection.
>
> Cc: Ian Romanick
> Cc: Emil Velikov
> Cc: Eric Engestrom
> Signed-off-by: Andres Gomez
> ---
> src/egl/main/eglcontext.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/egl/main/eglcontext.c b/sr
On Friday, 2018-03-02 12:25:11 +0100, Stefan Dirsch wrote:
> On Fri, Mar 02, 2018 at 11:03:53AM +, Eric Engestrom wrote:
> > On Friday, 2018-03-02 11:41:00 +0100, Stefan Dirsch wrote:
> > > Patch by "Tomas Chvatal" with modifications
> > > by "Michal Srb" to not break python 2.
> > >
> > > h
Reviewed-by: Tapani Pälli
On 03/02/2018 01:28 PM, Andres Gomez wrote:
Found by inspection.
Cc: Ian Romanick
Cc: Emil Velikov
Cc: Eric Engestrom
Signed-off-by: Andres Gomez
---
src/egl/main/eglcontext.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/egl/main/eglcontext.c b/src/eg
From: Thierry Reding
ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
support for this bus in order to allow use of the DRI_PRIME environment
variable with those devices.
While at it, also support the host1x bus, which is effectively the same
but uses an additional layer i
Found by inspection.
Cc: Ian Romanick
Cc: Emil Velikov
Cc: Eric Engestrom
Signed-off-by: Andres Gomez
---
src/egl/main/eglcontext.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c
index 18c1bc59acc..3e5d8ad97bf 100644
--- a/src/egl/main
On Fri, Mar 02, 2018 at 11:03:53AM +, Eric Engestrom wrote:
> On Friday, 2018-03-02 11:41:00 +0100, Stefan Dirsch wrote:
> > Patch by "Tomas Chvatal" with modifications
> > by "Michal Srb" to not break python 2.
> >
> > https://bugzilla.suse.com/show_bug.cgi?id=1082303
> >
> > v2:
> > - no
On Friday, 2018-03-02 11:41:00 +0100, Stefan Dirsch wrote:
> Patch by "Tomas Chvatal" with modifications
> by "Michal Srb" to not break python 2.
>
> https://bugzilla.suse.com/show_bug.cgi?id=1082303
>
> v2:
> - no longer try to encode a unicode
> - make use of 'from __future__ import print_fun
On Thu, Mar 01, 2018 at 09:00:38AM -0800, Dylan Baker wrote:
> Quoting sndir...@suse.de (2018-03-01 08:11:54)
> > From: Stefan Dirsch
> >
> > Patch by "Tomas Chvatal" with modifications
> > by "Michal Srb" to not break python 2.
> >
> > https://bugzilla.suse.com/show_bug.cgi?id=1082303
> >
>
Patch by "Tomas Chvatal" with modifications
by "Michal Srb" to not break python 2.
https://bugzilla.suse.com/show_bug.cgi?id=1082303
v2:
- no longer try to encode a unicode
- make use of 'from __future__ import print_function', so semantics
of print statements in python2 are closer to print f
On Thu, Mar 01, 2018 at 08:53:59AM -0800, Dylan Baker wrote:
> Quoting Thierry Reding (2018-03-01 05:28:07)
> > From: Thierry Reding
> >
> > The disk cache implementation uses 64-bit atomic operations. For some
> > architectures, such as 32-bit ARM, GCC will not be able to translate
> > these ope
On Thu, Mar 01, 2018 at 02:14:41PM +, Eric Engestrom wrote:
>
>
> On March 1, 2018 1:31:53 PM UTC, Thierry Reding
> wrote:
> > From: Thierry Reding
> >
> > ARM SoCs usually have their DRM/KMS devices on the platform bus, so
> > add
> > support for this bus in order to allow use of the DRI
Hi,
On 27.02.2018 23:38, Francisco Jerez wrote:
The main motivation is to enable HDC surface opcodes on ICL which no
longer allows the sample mask to be provided in a message header, but
this is enabled all the way back to IVB when possible because it
decreases the instruction count of some shad
Quoting Kenneth Graunke (2018-03-01 23:39:55)
> This should have no practical impact. For the default uploader, we
> don't really care, but for others, we may want to append more data
> as the GPU is reading existing data, which means we need async and
> persistent flags.
Ok.
Reviewed-by: Chris
Quoting Kenneth Graunke (2018-03-02 08:44:56)
> On Thursday, March 1, 2018 4:16:13 PM PST Chris Wilson wrote:
> > Quoting Kenneth Graunke (2018-03-01 23:39:54)
> > > I'd like to reuse the upload logic for a new program cache, but the
> > > buffers will need to have a different lifetime than the def
Reviewed-by: Iago Toral Quiroga
On Wed, 2018-02-28 at 15:11 -0800, Kenneth Graunke wrote:
> These days, we're just passing a pointer to a prog_data field, which
> we already have access to. We can just use it directly.
>
> (In the past, it was a pointer to a separate value.)
> ---
> src/intel/
On Thursday, March 1, 2018 4:16:13 PM PST Chris Wilson wrote:
> Quoting Kenneth Graunke (2018-03-01 23:39:54)
> > I'd like to reuse the upload logic for a new program cache, but the
> > buffers will need to have a different lifetime than the default
> > uploader, and also some address space restric
https://bugs.freedesktop.org/show_bug.cgi?id=105291
Gert Wollny changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=105291
--- Comment #3 from Gert Wollny ---
Created attachment 137749
--> https://bugs.freedesktop.org/attachment.cgi?id=137749&action=edit
Screenshot on CEDAR with gallium HUS
It is actually not necessary to recompile the module, all is needed is
On Fri, Mar 2, 2018 at 7:02 AM, Jason Ekstrand wrote:
> On Wed, Feb 28, 2018 at 1:25 PM, Rob Clark wrote:
>>
>> On Wed, Feb 28, 2018 at 4:16 PM, Eric Anholt wrote:
>> > Rob Clark writes:
>> >
>> >> From: Karol Herbst
>> >>
>> >> OpenCL kernels have parameters (see pipe_grid_info::input), and s
83 matches
Mail list logo
