On 08/08/2017 08:23 AM, Yuan, Feng wrote:
Hi,
On Mon, Aug 7, 2017 at 9:45 AM, Emil Velikov wrote:
On 7 August 2017 at 12:56, Tapani Pälli wrote:
Hi;
On 08/07/2017 02:15 PM, Yuan, Feng wrote:
Hi,
What’s the status of GLES 3.1 compute shaders support in
Linux and Android.
It i
On 01/08/17 19:37, Timothy Arceri wrote:
On 01/08/17 18:07, Samuel Pitoiset wrote:
Don't you think it's just safer to revert the bad commit for 17.2 and
fix it later on?
I'm not overly worried. If you really want to go that way we can, but I
don't think it's necessary.
So how do we move for
Hi,
> On Mon, Aug 7, 2017 at 9:45 AM, Emil Velikov wrote:
> > On 7 August 2017 at 12:56, Tapani Pälli wrote:
> >> Hi;
> >>
> >> On 08/07/2017 02:15 PM, Yuan, Feng wrote:
> >>>
> >>> Hi,
> >>>
> >>>What’s the status of GLES 3.1 compute shaders support in
> >>> Linux and Android.
> >>
> >>
Patches 2 (few comments), 5,6,7,8:
Reviewed-by: Tapani Pälli
(for the others I need more coffee)
On 08/05/2017 04:30 AM, Emil Velikov wrote:
On 5 August 2017 at 00:25, Emil Velikov wrote:
From: Emil Velikov
The function can handle only window surfaces, so let's rename it
accordingly, kill
On 08/05/2017 02:25 AM, Emil Velikov wrote:
From: Emil Velikov
The code in _eglCreatePixmapSurfaceCommon() already has a NULL check
_eglCreateWindowSurfaceCommon()
which handles the condition. There's no point in checkin again further
down the stack.
v2: Split the WINDOW vs PIXMAP into s
On 08/07/2017 03:05 PM, Philipp Zabel wrote:
On Mon, 2017-07-31 at 18:35 +0100, Daniel Stone wrote:
When using dmabuf import, make sure that the modifier is actually
allowed to add planes to the base format, as implied by the comment.
Signed-off-by: Daniel Stone
---
src/egl/drivers/dri2/eg
Hi Gwan-gyeong,
On Sat, Aug 5, 2017 at 12:16 AM, Gwan-gyeong Mun wrote:
> platform_drm, platform_wayland and platform_android have similiar local buffer
> allocation routines. For deduplicating, it unifies dri2_egl_surface's
> local buffer allocation routines. And it polishes inconsistent indenta
From: Dave Airlie
This looks like an evergreen specific feature, but with atomic
counters AMD have hw specific counters they use instead of operating
on buffers directly. These are separate to the buffer atomics,
so require different limits and code paths.
I've left the CAP for atomic type exten
From: Dave Airlie
This adds support for hw atomics to the state tracker,
it just sets the limits using the new CAPs, and sets
the maximums etc for it.
v2: rework for dropping CAP.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_extensions.c | 52 +++---
1
On Mon, Aug 7, 2017 at 2:19 PM, Marathe, Yogesh
wrote:
> Tomasz,
>
>> -Original Message-
>> From: Tomasz Figa [mailto:tf...@chromium.org]
>> Sent: Saturday, August 5, 2017 8:47 AM
>>
>> Hi Yogesh,
>>
>> On Sat, Aug 5, 2017 at 1:22 AM, Marathe, Yogesh
>> wrote:
>> >> -Original Message-
On Mon, Aug 7, 2017 at 3:44 PM, Marathe, Yogesh
wrote:
>> -Original Message-
>>
>> Tomasz,
>>
>> > -Original Message-
>> > From: Tomasz Figa [mailto:tf...@chromium.org]
>> > Sent: Saturday, August 5, 2017 8:47 AM
>> >
>> > Hi Yogesh,
>> >
>> > On Sat, Aug 5, 2017 at 1:22 AM, Marath
From: Connor Abbott
The .f32 was already getting added by emit_intrin_2f_param(). Noticed
when enabling LLVM module verification.
---
src/amd/common/ac_nir_to_llvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to
From: Connor Abbott
ac_to_float() does a superset of what it does.
---
src/amd/common/ac_llvm_build.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 2fdb3e8..a10ec51 100644
--- a/src/am
From: Connor Abbott
---
src/amd/common/ac_nir_to_llvm.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index b39b873..bafe4d3 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/a
From: Connor Abbott
---
src/amd/common/ac_llvm_build.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index a10ec51..d4b48d1 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -99,6 +99,7 @@ ac_
From: Connor Abbott
---
src/amd/vulkan/radv_device.c | 15 +++
src/amd/vulkan/radv_pipeline.c | 4
2 files changed, 19 insertions(+)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 21f2437..2255ff8 100644
--- a/src/amd/vulkan/radv_device.c
+++
From: Connor Abbott
Using the new WWM and DPP intrinsics introduced in LLVM 6.0. This adds
everything needed to implement SPV_AMD_shader_ballot, including the
Groups capability, to ac_llvm_build.c. That way, it can be shared by a
potential GL_AMD_shader_ballot implementation in the future. Curren
From: Connor Abbott
---
src/amd/vulkan/radv_pipeline.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 3ed0df7..4aecb81 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -295,6 +295,7 @@ r
From: Connor Abbott
We'll need to use ac_to_integer() for other stuff in ac_llvm_build.c.
---
src/amd/common/ac_llvm_build.c | 61 +++
src/amd/common/ac_llvm_build.h | 5 +
src/amd/common/ac_nir_to_llvm.c | 224 +++-
3 files changed, 150 insertion
From: Connor Abbott
Notably this doesn't include the workgroup reduce intrinsics, since
those are tricky and the right implementation strategy might differ
across different HW. However, it implements all the other ancilliary
stuff needed for the SPIR-V Groups capability, so the driver doesn't
hav
From: Connor Abbott
We didn't need this for read_invocation, since the SPIR-V version of
shader_ballot explicitly says that ReadInvocation and
ReadFirstInvocation can only be used with scalars, but this isn't true
for some of the SPV_AMD_shader_ballot intrinsics.
---
src/amd/vulkan/radv_pipeline
From: Connor Abbott
Scalarizing the group/subgroup reduction ops isn't strictly necessary
for SPIR-V since they're supposed to be scalars anyways, but it will be
useful if we want to wire up the GL version of the extension, so we
might as well wire them up too.
---
.../nir/nir_lower_cross_thread
From: Connor Abbott
glslang enables the Group capability in SPIR-V when compiling shaders
with GL_AMD_shader_ballot, and uses OpGroupIAdd etc. for implementing
some functions in GL_AMD_shader_ballot, so it seems that the Group
capability is implicitly added by the Vulkan extension. I've added
sup
From: Connor Abbott
We'll want to scalarize other intrinsics in a similar manner for
AMD_shader_ballot, and possibly other extensions in the future. This
patch reworks the pass to use the intrinsic's info to detect whether we
need to copy the source or scalarize it, similarly to how ALU operation
From: Connor Abbott
There's no Khronos-supplied C header, so I hacked up the C++ one in
glslang to be C-compatible. See
https://github.com/KhronosGroup/SPIRV-Headers/issues/36.
---
src/compiler/spirv/GLSL.ext.AMD.h | 93 +++
1 file changed, 93 insertions(+)
c
From: Connor Abbott
---
src/compiler/nir/nir.h| 7 +++
src/compiler/nir/nir_intrinsics.h | 124 +-
src/compiler/nir/nir_print.c | 1 +
3 files changed, 129 insertions(+), 3 deletions(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/n
From: Connor Abbott
This series implements VK_AMD_shader_ballot for radv. This extension
builds on VK_EXT_shader_subgroup_ballot and VK_EXT_shader_subgroup_vote
by adding a number of reductions across a subgroup (or wavefront in AMD
terminology). Previously, shaders had to use shared memory to co
On Mon, Aug 7, 2017 at 5:51 PM, Chad Versace
wrote:
> On Fri 04 Aug 2017, Jason Ekstrand wrote:
> > Ken and I had a fairly lengthy conversation about this on IRC today:
> >
> > [1]https://people.freedesktop.org/~jekstrand/isl-padding
> >
> > The conclusion was that we both hate the patch but it's
On Fri 04 Aug 2017, Jason Ekstrand wrote:
> Ken and I had a fairly lengthy conversation about this on IRC today:
>
> [1]https://people.freedesktop.org/~jekstrand/isl-padding
>
> The conclusion was that we both hate the patch but it's probably safe and it
> does fix bugs. The thing that really wi
From: Kai Chen
In function get_back_bo, wl_display_dispatch_queue is used to block on
the server to release one buffer. But it seems this function will block
client as well during polling. Because in some scenarios, such as when
surfaces are moved frequently between two displays under weston
comp
Also, should probably update the release notes.
-Thomas
8. aug. 2017 00.31 skrev "Ian Romanick" :
On 08/07/2017 03:20 PM, Ilia Mirkin wrote:
> On Mon, Aug 7, 2017 at 6:14 PM, Ian Romanick wrote:
>> On 06/28/2017 06:50 AM, Plamena Manolova wrote:
>>> ARB_polygon_offset_clamp is just the ARB va
https://bugs.freedesktop.org/show_bug.cgi?id=102077
Eric Engestrom changed:
What|Removed |Added
CC||fdo-b...@engestrom.ch
--- Comment #1 f
From: Connor Abbott
v2: shader_ballot -> shader_group_vote when checking capabilities
Acked-by: Nicolai Hähnle
---
src/compiler/spirv/nir_spirv.h | 2 +
src/compiler/spirv/spirv_to_nir.c | 79 ++
src/compiler/spirv/vtn_variables.c | 28 ++
On 08/08/17 02:52, Thomas Helland wrote:
Patch 7 has my RB. I'll look closer at the rest this evening.
There's also the stringbuffer work that I have lying that should help.
I just have to find out how to run the gtest tests to verify their working.
oh right. Sorry for the overlap :(
We could
Use the common pipe_screen ref counting and fd hashing functions for
vc4. This is necessary to only create a single pipe_screen for a
process and avoid multiple imports of same prime fd.
Cc: Eric Anholt
Signed-off-by: Rob Herring
---
src/gallium/winsys/vc4/drm/vc4_drm_winsys.c | 21
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader serializes the
create_screen() and destroy() calls.
This changes the reference counting from the winsys to the pipe screen.
Previously, it was possible to have 1 winsys with multiple pipe
Use the common pipe_screen ref counting.
radeon uses the common pipe_screen_{un}reference functions, but amdgpu
is unique in its hashing the dev pointer rather than the fd, so the
common fd hashing cannot be used. However, the same reference counting
can be used instead of the private one. The mut
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader serializes the
create_screen() and destroy() calls.
Signed-off-by: Rob Herring
---
src/gallium/auxiliary/target-helpers/drm_helper.h | 2 +-
src/gallium/drivers/svga/svga_public.h
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader serializes the
create_screen() and destroy() calls.
Signed-off-by: Rob Herring
Cc: Dave Airlie
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 88 +++--
1 file
Use the common pipe_screen ref counting and fd hashing functions for
vc4. This is necessary to only create a single pipe_screen for a
process and avoid multiple imports of same prime fd.
Cc: Eric Anholt
Signed-off-by: Rob Herring
---
src/gallium/winsys/vc4/drm/vc4_drm_winsys.c | 21
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader serializes the
create_screen() and destroy() calls.
Signed-off-by: Rob Herring
Cc: Dave Airlie
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 88 +++--
1 file
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader serializes the
create_screen() and destroy() calls.
Signed-off-by: Rob Herring
Cc: Christian Gmeiner
Cc: Wladimir J. van der Laan
Cc: Lucas Stach
---
src/gallium/drivers/etnaviv/etnav
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader serializes the
create_screen() and destroy() calls.
Signed-off-by: Rob Herring
Cc: Alexandre Courbot
---
src/gallium/drivers/nouveau/nouveau_screen.c | 6 --
src/gallium/drivers/
Use the common pipe_screen ref counting.
radeon uses the common pipe_screen_{un}reference functions, but amdgpu
is unique in its hashing the dev pointer rather than the fd, so the
common fd hashing cannot be used. However, the same reference counting
can be used instead of the private one. The mut
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader serializes the
create_screen() and destroy() calls.
Signed-off-by: Rob Herring
Cc: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_screen.c | 1 -
src/gallium/drivers/freedreno
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader serializes the
create_screen() and destroy() calls.
Signed-off-by: Rob Herring
Cc: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_screen.c | 1 -
src/gallium/drivers/freedreno
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader serializes the
create_screen() and destroy() calls.
Signed-off-by: Rob Herring
Cc: Alexandre Courbot
---
src/gallium/drivers/nouveau/nouveau_screen.c | 6 --
src/gallium/drivers/
Use pipe_screen_unreference as it will call pipe_screen->destroy() when
the pipe_screen is no longer referenced.
Signed-off-by: Rob Herring
Cc: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxi
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader serializes the
create_screen() and destroy() calls.
Signed-off-by: Rob Herring
Cc: Christian Gmeiner
Cc: Wladimir J. van der Laan
Cc: Lucas Stach
---
src/gallium/drivers/etnaviv/etnav
Creating a screen needs to be serialized in order to support reusing
existing screen. With this, driver private mutexes in create_screen()
functions can be removed.
pipe_loader_create_screen is made an exported symbol to ensure the same
library function (and mutex) is used when multiple libraries
Use pipe_screen_unreference as it will call pipe_screen->destroy() when
the pipe_screen is no longer referenced.
The pipe_screen referencing is done within create_screen() functions
as drivers (like amdgpu) may have special needs for ref counting.
Signed-off-by: Rob Herring
Cc: Emil Velikov
---
In order to prevent multiple pipe_screens being created in the same
process, lookup of the DRM FD and reference counting of the pipe_screen
are needed. Several implementations of this exist in various gallium
drivers/winsys already. This creates a common version which is opt-in
for winsys implement
I finally got around to updating this series since I have another driver
to add reference counting to (kms_swrast). Reference counting of the pipe
screen is necessary for Android support (and VDPAU AIUI), but each driver
has so far implemented there own private ref counting. This series creates
a
In preparation to add reference counting of pipe_screen in the pipe-loader,
pipe_loader_release needs to destroy the pipe_screen instead of state
trackers.
Signed-off-by: Rob Herring
Cc: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 14 --
src/gallium/auxiliar
Use pipe_screen_unreference as it will call pipe_screen->destroy() when
the pipe_screen is no longer referenced.
Signed-off-by: Rob Herring
---
src/gallium/drivers/ddebug/dd_screen.c | 3 ++-
src/gallium/drivers/noop/noop_pipe.c | 3 ++-
src/gallium/drivers/rbug/rbug_screen.c | 3 ++-
src/gall
Matt Turner writes:
> ---
> src/intel/compiler/brw_reg_type.c | 65
> +--
> 1 file changed, 29 insertions(+), 36 deletions(-)
>
> diff --git a/src/intel/compiler/brw_reg_type.c
> b/src/intel/compiler/brw_reg_type.c
> index 8aac0ca009..b0696570e5 100644
> ---
On 08/07/2017 03:20 PM, Ilia Mirkin wrote:
> On Mon, Aug 7, 2017 at 6:14 PM, Ian Romanick wrote:
>> On 06/28/2017 06:50 AM, Plamena Manolova wrote:
>>> ARB_polygon_offset_clamp is just the ARB variation
>>> of EXT_polygon_offset_clamp and they operate in an
>>> identical manner, so there's no reas
In case you feel like handling it... there is one other GLSL 4.60
feature that is not covered by any extension. It was previously illegal
to have an extra ; at global scope, but this is now allowed. So things
like,
uniform int i
are valid, but they previously should have generated an er
On Mon, Aug 7, 2017 at 6:14 PM, Ian Romanick wrote:
> On 06/28/2017 06:50 AM, Plamena Manolova wrote:
>> ARB_polygon_offset_clamp is just the ARB variation
>> of EXT_polygon_offset_clamp and they operate in an
>> identical manner, so there's no reason for us not
>> to advertise it.
>>
>> Signed-of
On 06/28/2017 06:50 AM, Plamena Manolova wrote:
> ARB_texture_filter_anisotropic is the ARB variation of
> EXT_texture_fitter_anisotropic and it operates in the
> same way, so there's no reason not to advertise it.
>
> Signed-off-by: Plamena Manolova
> ---
> src/mesa/main/extensions_table.h | 1
On 06/28/2017 06:50 AM, Plamena Manolova wrote:
> ARB_polygon_offset_clamp is just the ARB variation
> of EXT_polygon_offset_clamp and they operate in an
> identical manner, so there's no reason for us not
> to advertise it.
>
> Signed-off-by: Plamena Manolova
> ---
> src/mesa/main/extensions_ta
On Mon, Aug 7, 2017 at 11:51 PM, Ilia Mirkin wrote:
> On Mon, Aug 7, 2017 at 5:37 PM, Bas Nieuwenhuizen
> wrote:
>> Also adds an assert because you never know how the winsys changes, and
>> multiprocess format differences are annoying.
>>
>> Fixes: 1e696b962b7 "radv: add separate fmask tile swizz
pushed, thanks.
On Thu, Aug 3, 2017 at 4:32 PM, Alex Smith wrote:
> Need to take the sample count into account in the depth decompress and
> resummarize pipelines and render pass.
>
> Fixes: f4e499ec791 ("radv: add initial non-conformant radv vulkan driver")
> Signed-off-by: Alex Smith
> Cc: "17
On Mon, Aug 7, 2017 at 5:37 PM, Bas Nieuwenhuizen
wrote:
> Also adds an assert because you never know how the winsys changes, and
> multiprocess format differences are annoying.
>
> Fixes: 1e696b962b7 "radv: add separate fmask tile swizzle counter."
> ---
> src/amd/vulkan/radv_image.c | 5 -
>
The GPU reads the shader kernel from the program cache BO. It never
writes it, so using a read-write BO reference makes no sense.
Just make KSP read-only, and drop KSP_ro.
---
src/mesa/drivers/dri/i965/genX_state_upload.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
RELOC_NEEDS_GGTT is only meaningful on Sandybridge - it's skipped on
other generations - so this has no purpose. Just use rw_bo().
---
src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c
b
With the reloc domains gone, most of these are basically the same,
and the names don't make much sense anymore. Simplify them to ro_bo(),
rw_bo(), and ggtt_bo().
---
src/mesa/drivers/dri/i965/genX_state_upload.c | 72 ++-
1 file changed, 25 insertions(+), 47 deletions(-)
Also adds an assert because you never know how the winsys changes, and
multiprocess format differences are annoying.
Fixes: 1e696b962b7 "radv: add separate fmask tile swizzle counter."
---
src/amd/vulkan/radv_image.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/amd/
Fixed in master.
Marek
On Mon, Aug 7, 2017 at 10:05 PM, Samuel Pitoiset
wrote:
>
>
> On 08/07/2017 09:12 PM, Marek Olšák wrote:
>>
>> Module: Mesa
>> Branch: master
>> Commit: 4e629ca7c768c62c530887ff61e96fba2cce6717
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=4e629ca7c768c62c530
For the series:
Acked-by: Samuel Pitoiset
On 08/06/2017 04:42 PM, Ilia Mirkin wrote:
There was a previous error in the gl.xml and generated files that
referenced glMultiDrawElementsBaseVertexOES. This function should not
exist, only the EXT-suffixed version should.
Leaving the other headers a
On 08/07/2017 09:12 PM, Marek Olšák wrote:
Module: Mesa
Branch: master
Commit: 4e629ca7c768c62c530887ff61e96fba2cce6717
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4e629ca7c768c62c530887ff61e96fba2cce6717
Author: Marek Olšák
Date: Tue Aug 1 14:26:21 2017 +0200
radeonsi: alig
I believe you are correct Rob. I grabbed a dumpsys from
SurfaceFlinger and put the output here:
https://pastebin.com/vzmRf8Kp
This was done with a game running in the foreground with the 38 pixel
high navigation bar still present on the bottom of the screen.
It seems to me that we need some way
On Fri, Aug 4, 2017 at 3:21 PM, Scott D Phillips wrote:
> BLEND_STATE packing was modified to be variable-length in:
>
> 9670124e31 genxml: Make BLEND_STATE command support variable length array.
>
> The initial gen10.xml still had the old, fixed-length style
> definition for BLEND_STATE. So gen
On Mon, Aug 7, 2017 at 8:18 AM, Emil Velikov wrote:
> On 5 August 2017 at 21:53, Vinson Lee wrote:
>> Fixes build error on CentOS 6.9.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102052
>> Fixes: 5c007203b73d ("configure.ac: drop manual detection of expat
>> header/library")
>>
On 1 August 2017 at 23:01, Gurchetan Singh wrote:
> Thanks for the reviews! I rebased patch number #4, and added
> platform_wayland support and squashed this patch to form patch #5. Note it
> seems platform_drm already has the correct path for swrast, since
> gbm_dri_screen_extensions already ha
From: Kai Chen
In function get_back_bo, wl_display_dispatch_queue is used to block on
the server to release one buffer. But it seems this function will block
client as well during polling. Because in some scenarios, such as when
surfaces are moved frequently between two displays under weston
comp
Patch 7 has my RB. I'll look closer at the rest this evening.
There's also the stringbuffer work that I have lying that should help.
I just have to find out how to run the gtest tests to verify their working.
On Aug 7, 2017 04:19, "Timothy Arceri" wrote:
I've sent all but the last 2 already but
On Fri, Aug 4, 2017 at 12:07 PM, Jason Ekstrand
wrote:
> Ken and I had a fairly lengthy conversation about this on IRC today:
>
> https://people.freedesktop.org/~jekstrand/isl-padding
>
> The conclusion was that we both hate the patch but it's probably safe and
> it does fix bugs. The thing that
https://bugs.freedesktop.org/show_bug.cgi?id=102077
Bug ID: 102077
Summary: multilib mesa fail to build with
"egl/drivers/dri2/platform_drm.c:542: undefined
reference to `gbm_bo_get_bpp'"
Product: Mesa
Version: gi
From: Emil Velikov
One could easily introduce version 3 of the DRI2fenceExtension,
extending the struct, while not implementing the above function.
Thus we'll end up with NULL pointer, and dereferencing it won't fare
too well.
Fixes: 0201f01dc4e ("egl: add EGL_ANDROID_native_fence_sync")
Cc: Ro
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #43 from Marko ---
(In reply to Dave Airlie from comment #39)
> https://patchwork.freedesktop.org/patch/169012/
>
> I also have this patch in my tree.
Tested on fresh 4.13 RC3, today's Mesa git + this patch, still no joy. Freezes
s
On Fri, Aug 4, 2017 at 1:08 PM, Jordan Justen
wrote:
> On 2017-08-02 13:35:33, Jason Ekstrand wrote:
> > Originally, I had moved it to the caller to make some things easier when
> > adding the CCS modifier. However, this broke DRI2 because
> > intel_process_dri2_buffer calls intel_miptree_create
On 5 August 2017 at 21:53, Vinson Lee wrote:
> Fixes build error on CentOS 6.9.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102052
> Fixes: 5c007203b73d ("configure.ac: drop manual detection of expat
> header/library")
> Signed-off-by: Vinson Lee
> ---
> configure.ac |4 +++-
On Monday, 2017-08-07 14:59:32 +0300, Tapani Pälli wrote:
> They always get initialized to zero by swrastGetDrawableInfo. Valid
> X11 Drawable minimum size is 1x1, so we can detect success/change by
> checking against 0.
>
> Signed-off-by: Tapani Pälli
> Reported-by: Emil Velikov
Reviewed-by: E
On Mon, Aug 7, 2017 at 9:45 AM, Emil Velikov wrote:
> On 7 August 2017 at 12:56, Tapani Pälli wrote:
>> Hi;
>>
>> On 08/07/2017 02:15 PM, Yuan, Feng wrote:
>>>
>>> Hi,
>>>
>>>What’s the status of GLES 3.1 compute shaders support in Linux and
>>> Android.
>>
>>
>> It is supported.
>>
>>>
On 7 August 2017 at 12:56, Tapani Pälli wrote:
> Hi;
>
> On 08/07/2017 02:15 PM, Yuan, Feng wrote:
>>
>> Hi,
>>
>>What’s the status of GLES 3.1 compute shaders support in Linux and
>> Android.
>
>
> It is supported.
>
>>Which branch/version start this support? and which Intel plat
On 7 August 2017 at 12:59, Tapani Pälli wrote:
> They always get initialized to zero by swrastGetDrawableInfo. Valid
> X11 Drawable minimum size is 1x1, so we can detect success/change by
> checking against 0.
>
> Signed-off-by: Tapani Pälli
> Reported-by: Emil Velikov
> ---
> src/egl/drivers/d
Mesa 17.1.6 is now available.
In this release we have:
Various bugfixes for most drivers - i965, ANV, radeonsi, RADV, etnaviv, nv50
and SWR. The DRI3 codepath for GLX and EGL have also been improved.
Andres Gomez (1):
docs: add sha256 checksums for 17.1.5
Bas Nieuwenhuizen (1):
ra
On Mon, Aug 7, 2017 at 5:54 AM, Samuel Pitoiset
wrote:
> Other ones are either unsupported or don't have any helper
> function checks.
>
> v5: - do not expose ARB system values for 460
ARB-suffixed functions
> v4: - drop ARB suffix for shader_group_vote/arb_shader_atomic_counter_ops
> v3: - alwa
On Mon, 2017-07-31 at 18:35 +0100, Daniel Stone wrote:
> When using dmabuf import, make sure that the modifier is actually
> allowed to add planes to the base format, as implied by the comment.
>
> Signed-off-by: Daniel Stone
> ---
> src/egl/drivers/dri2/egl_dri2.c | 4 +++-
> 1 file changed, 3
The third release candidate for Mesa 17.2.0 is now available.
Bas Nieuwenhuizen (1):
radv: Don't underflow non-visible VRAM size.
Bruce Cherniak (1):
st/osmesa: add osmesa framebuffer iface hash table per st manager
Chris Wilson (1):
i965/blit: Remember to include miptree buffe
They always get initialized to zero by swrastGetDrawableInfo. Valid
X11 Drawable minimum size is 1x1, so we can detect success/change by
checking against 0.
Signed-off-by: Tapani Pälli
Reported-by: Emil Velikov
---
src/egl/drivers/dri2/platform_x11.c | 4 ++--
1 file changed, 2 insertions(+), 2
Hi;
On 08/07/2017 02:15 PM, Yuan, Feng wrote:
Hi,
What’s the status of GLES 3.1 compute shaders support in Linux
and Android.
It is supported.
Which branch/version start this support? and which Intel
platforms are enabled. Is there any benchmark data in SKL/APL?
GLES 3.1
On 07/31/2017 08:35 PM, Daniel Stone wrote:
When using dmabuf import, make sure that the modifier is actually
allowed to add planes to the base format, as implied by the comment.
Signed-off-by: Daniel Stone
---
src/egl/drivers/dri2/egl_dri2.c | 4 +++-
1 file changed, 3 insertions(+), 1 de
Hi,
What's the status of GLES 3.1 compute shaders support in Linux and
Android.
Which branch/version start this support? and which Intel platforms are
enabled. Is there any benchmark data in SKL/APL?
Thanks,
Wind
___
mesa-dev mailing lis
https://bugs.freedesktop.org/show_bug.cgi?id=102067
Bug ID: 102067
Summary: Is it possible select a driver/implementation in an
application? (like in OpenCL)
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/radeonsi/si_shader.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 035e36fbab..b2765b5089 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
On 31 July 2017 at 18:35, Daniel Stone wrote:
> When using dmabuf import, make sure that the modifier is actually
> allowed to add planes to the base format, as implied by the comment.
Anyone?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
htt
Other ones are either unsupported or don't have any helper
function checks.
v5: - do not expose ARB system values for 460
v4: - drop ARB suffix for shader_group_vote/arb_shader_atomic_counter_ops
v3: - always add gl_BaseVertex & co when 460 is enabled
v2: - fix ARB_shader_draw_parameters system va
On 08/07/2017 09:25 AM, Nicolai Hähnle wrote:
On 04.08.2017 17:46, Ilia Mirkin wrote:
On Fri, Aug 4, 2017 at 10:49 AM, Samuel Pitoiset
wrote:
On 08/04/2017 04:27 PM, Ilia Mirkin wrote:
On Aug 4, 2017 02:02, "Samuel Pitoiset" mailto:samuel.pitoi...@gmail.com>> wrote:
On 08/03/20
1 - 100 of 123 matches
Mail list logo
