On Wednesday, May 31, 2017 9:49:03 PM PDT Matt Turner wrote:
> On Wed, May 24, 2017 at 1:04 PM, Matt Turner wrote:
> > The series aims to improve performance on non-LLC platforms like Braswell
> > and
> > Broxton.
> >
> > Unsynchronized mappings were not actually unsynchronized on non-LLC
> > pl
On Wed, May 31, 2017 at 10:42 PM, Jason Ekstrand wrote:
> On May 31, 2017 9:32:23 PM Ian Romanick wrote:
>
>> Having the unsupported format value not be zero isn't very safe. The
>> C99 rules say that any field missing an initializer is implicitly
>> initialized to zero. If a MESA_FORMAT_ value
Hi Harish;
One thing left for the basic plumbing, sorry I did not mention this
earlier. Please add a "_eglReturnFalse" fallback for
eglSetDamageRegionKHR (see _eglInitDriverFallbacks).
Also see one small but significant change below in 'ClampRects' ..
On 06/01/2017 07:42 AM, Harish Krupo wro
On May 31, 2017 9:32:23 PM Ian Romanick wrote:
Having the unsupported format value not be zero isn't very safe. The
C99 rules say that any field missing an initializer is implicitly
initialized to zero. If a MESA_FORMAT_ value is added but is not added
to the array initializer, we'll have thi
From: Dave Airlie
In prep for GFX9 refactor some of the eop event writing code
out.
This changes behaviour, but aligns with what radeonsi does,
it does double emits on CIK/VI, whereas previously it only
did this on CIK.
v2: bump the size checks.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/
On 1 June 2017 at 14:43, Dave Airlie wrote:
> From: Dave Airlie
>
> In prep for GFX9 refactor some of the eop event writing code
> out.
This triggers an assert, I have to bump some of the command stream size checks.
This does change behaviour by emitting 2 EOPs where we used to emit
one on CIK/
On Wed, May 24, 2017 at 1:04 PM, Matt Turner wrote:
> The series aims to improve performance on non-LLC platforms like Braswell and
> Broxton.
>
> Unsynchronized mappings were not actually unsynchronized on non-LLC platforms,
> hurting Unigine Valley performance quite a lot. That's fixed. We also
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 4ab72cd..15610db 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/d
This way we can let brw_bo_map() choose the best mapping type.
Part of the patch inlines map_gtt() into brw_bo_map_gtt() (and removes
map_gtt()). brw_bo_map_gtt() just wrapped map_gtt() with locking and a
call to set_domain(). map_gtt() is called by brw_bo_map_unsynchronized()
to avoid the call to
Call brw_bo_map() directly.
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 20 --
src/mesa/drivers/dri/i965/brw_bufmgr.h | 1 -
src/mesa/drivers/dri/i965/brw_program_cache.c| 4 ++--
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 27 +++--
No functional change (no callers currently pass MAP_ASYNC)
---
These four patches split 11/16 like Ken suggested
src/mesa/drivers/dri/i965/brw_bufmgr.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i
From: Dave Airlie
For GFX9 these will be needed to be 64-bit, so bump them early,
to avoid it causing any wierdness later.
---
src/amd/vulkan/radv_private.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_
From: Dave Airlie
In prep for GFX9 refactor some of the eop event writing code
out.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 22 -
src/amd/vulkan/radv_private.h| 9 +++
src/amd/vulkan/radv_query.c | 53 -
From: Dave Airlie
This reworks this code to be like radeonsi, which will make it
easier to add GFX9 support to it in the future.
---
src/amd/vulkan/si_cmd_buffer.c | 156 ++---
1 file changed, 70 insertions(+), 86 deletions(-)
diff --git a/src/amd/vulkan/si_c
This just refactors and moves some code about in advance
of GFX9 support, should cut down on the regression risks getting
these in first.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-d
From: Dave Airlie
This code was in a few places, consolidate into one.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 9 +
src/amd/vulkan/radv_private.h| 3 +++
src/amd/vulkan/radv_query.c | 16 ++--
src/amd/vulkan/si_cmd_buffer.c | 14 ++
On Fri, May 26, 2017 at 1:50 AM, Kenneth Graunke wrote:
> On Wednesday, May 24, 2017 1:04:50 PM PDT Matt Turner wrote:
>> brw_bo_map_cpu() took a write_enable arg, but it wasn't always clear
>> whether we were also planning to read from the buffer. I kept everything
>> semantically identical by pa
This patch adds support for the EGL_KHR_partial_update extension for
android platform. It passes 36/37 tests in dEQP for EGL_KHR_partial_update.
1 test not supported.
Signed-off-by: Harish Krupo
---
src/egl/drivers/dri2/egl_dri2.c | 12 +
src/egl/drivers/dri2/egl_dri2.h | 4
Having the unsupported format value not be zero isn't very safe. The
C99 rules say that any field missing an initializer is implicitly
initialized to zero. If a MESA_FORMAT_ value is added but is not added
to the array initializer, we'll have this same problem... but in a way
that is much harder
This patch is
Reviewed-by: Ian Romanick
On 05/31/2017 04:43 PM, Chad Versace wrote:
> Combine variable declarations and assignments.
> Trivial cleanup.
> ---
> src/mesa/drivers/dri/i965/intel_fbo.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers
On 05/31/2017 04:43 PM, Chad Versace wrote:
> This function never occurs in the callchain of a GL function. It occurs
> only in the callchain of eglCreate*Surface and the analogous paths for
> GLX. Therefore, even if a thread does have a bound GL context,
> emitting a GL error here is wrong. A mi
From: Dave Airlie
This just aligns with how anv does it.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_formats.c | 76 ++-
1 file changed, 46 insertions(+), 30 deletions(-)
diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
On 31 May 2017 at 21:14, Jan Vesely wrote:
> On Wed, 2017-05-31 at 18:32 +0100, Emil Velikov wrote:
>> On 31 May 2017 at 18:18, Jan Vesely wrote:
>> > On Wed, 2017-05-31 at 17:48 +0100, Emil Velikov wrote:
>> > > On 31 May 2017 at 16:32, Marek Olšák wrote:
>> > > > On Wed, May 31, 2017 at 4:17 P
Replace -1 with MESA_SHADER_NONE enum value to fix sign related warning:
external/mesa3d/src/compiler/glsl/link_varyings.cpp:1415:25: warning:
comparison of constant -1 with expression of type 'gl_shader_stage' is always
true [-Wtautological-constant-out-of-range-compare]
(consumer_stage
On Wed, May 31, 2017 at 5:49 PM, Ian Romanick wrote:
> On 05/31/2017 06:09 AM, Emil Velikov wrote:
>> On 31 May 2017 at 01:55, Ian Romanick wrote:
>>> I don't understand these warnings, and I have even less understanding of
>>> how "using" fixes them. For example...
>>>
>>> On 05/30/2017 01:47 P
2-4 are also
Reviewed-by: Jason Ekstrand
On May 31, 2017 4:44:11 PM Chad Versace wrote:
When given an *unsupported* mesa_format,
brw_isl_format_for_mesa_format() returned 0, a *valid* isl_format,
ISL_FORMAT_R32G32B32A32_FLOAT. The problem is that
brw_isl_format_for_mesa_format's inner tabl
Hooray!
On May 31, 2017 4:44:13 PM Chad Versace wrote:
It returns an isl_format, not uint32_t BRW_FORMAT.
I updated every brw_isl_format_for_mesa_format() found by git-grep.
No change in behavior.
---
src/mesa/drivers/dri/i965/brw_context.c | 5 +++--
src/mesa/drivers/dri/i965/brw
On 01/06/17 02:45, Marek Olšák wrote:
On Tue, May 23, 2017 at 12:07 AM, Timothy Arceri wrote:
3. The GLSL IR opts are both slow and not always optimal (possibly
transforming the code to something that's harder to opt later), but due to
uniform/varying optimisation requirements some optimisation
clang gives a warning in blob_overwrite_bytes because offset type is
size_t which is unsigned:
src/compiler/glsl/blob.c:110:15: warning: comparison of unsigned expression < 0
is always false [-Wtautological-compare]
if (offset < 0 || blob->size - offset < to_write)
~~ ^ ~
Remove th
On 01/06/17 07:30, Juan A. Suarez Romero wrote:
On Tue, 2017-05-16 at 20:40 +0200, Nicolai Hähnle wrote:
From: Nicolai Hähnle
This reverts commit 0e9991f957e296f46cfff40a94ffba0adf2a58e1.
At least when we fallback because of TGSI, the gl_program objects are
re-allocated, and we don't in fact
This reverts commit 7adb9b094894a512c019b3378eb9e3c69d830edc.
The "No functional change" claim is wrong, after that commit, the
_eglGetNativePlatformFromEnv() function is now called every time instead
of just once it was called before. What's worse, when
_eglGetNativePlatform() is called from mult
If the EGLImage's format is not a supported texture format according to
brw_surface_formats.c, then refuse to create the miptree. This follows
the precedent in glEGLImageRenderbufferStorage (implemented by
intel_image_target_renderbuffer_storage), which rejects the EGLImage's
format if is not rende
I found these little fixes and cleanups while hacking the i965 DRI layer
to support R8G8B8X8 EGLConfigs on Skylake (those patches aren't ready
yet, though).
Patches 1, 2, 4, 5 should change behavior. They're pure cleanups.
Patches 3, 6 are actual fixes.
I tested this series on Broadwell with:
This function never occurs in the callchain of a GL function. It occurs
only in the callchain of eglCreate*Surface and the analogous paths for
GLX. Therefore, even if a thread does have a bound GL context,
emitting a GL error here is wrong. A misplaced GL error, when no GL
call is made, can confu
It returns an isl_format, not GLuint BRW_FORMAT. I updated every
translate_tex_format() found by git-grep.
No change in behavior.
---
src/mesa/drivers/dri/i965/brw_state.h| 6 +++---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 +-
src/mesa/drivers/dri/i965/brw_wm_surface_sta
When given an *unsupported* mesa_format,
brw_isl_format_for_mesa_format() returned 0, a *valid* isl_format,
ISL_FORMAT_R32G32B32A32_FLOAT. The problem is that
brw_isl_format_for_mesa_format's inner table used 0 instead of
ISL_FORMAT_UNSUPPORTED to indicate unsupported mesa formats.
Some callers o
translate_tex_format() asserted that isl_format != 0. But 0 is a valid
format, ISL_FORMAT_R32G32B32A32_FLOAT.
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surf
Combine variable declarations and assignments.
Trivial cleanup.
---
src/mesa/drivers/dri/i965/intel_fbo.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index d3905a5..d69b921 100644
--- a/sr
It returns an isl_format, not uint32_t BRW_FORMAT.
I updated every brw_isl_format_for_mesa_format() found by git-grep.
No change in behavior.
---
src/mesa/drivers/dri/i965/brw_context.c | 5 +++--
src/mesa/drivers/dri/i965/brw_state.h| 3 +--
src/mesa/drivers/dri/i965/brw_s
On 05/31/2017 02:04 AM, Samuel Pitoiset wrote:
>
>
> On 05/31/2017 02:46 AM, Ian Romanick wrote:
>> On 05/25/2017 11:07 AM, Samuel Pitoiset wrote:
>>> Memory/format layout qualifiers shouldn't be lost when arrays
>>> of images are splitted by this pass.
>>>
>>> Signed-off-by: Samuel Pitoiset
>>>
On 05/31/2017 06:09 AM, Emil Velikov wrote:
> On 31 May 2017 at 01:55, Ian Romanick wrote:
>> I don't understand these warnings, and I have even less understanding of
>> how "using" fixes them. For example...
>>
>> On 05/30/2017 01:47 PM, Rob Herring wrote:
>>> clang gives warnings about overload
Signed-off-by: Rhys Kidd
---
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index f2ae4f3ae3..c636926994 100644
--- a/src/gallium/drivers/nouveau/
On 05/31/2017 03:34 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> Otherwise we'd get progress continually set if we had non 64-bit
> versions of these ops.
Right. This never caused problems before because the return value from
lower_64bit_integer_instructions was always ignored.
Reviewed-by:
From: Dave Airlie
Otherwise we'd get progress continually set if we had non 64-bit
versions of these ops.
Signed-off-by: Dave Airlie
---
src/compiler/glsl/lower_int64.cpp | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/compiler/glsl/lower_int64.cpp
b/src/compiler/g
On Wed, May 31, 2017 at 9:37 AM, Luke A. Guest wrote:
> Hi,
>
> I've just reinstalled Gentoo on my machine and I no longer have
> AMDGPU-Pro on it due to it using ancient libs. My machine is an FX-8350
> one, so it's PCIe-2.0. Clover is currently lacking in CL compliance at
> this time.
>
> So, I
On Wed, May 31, 2017 at 1:35 AM, Lionel Landwerlin
wrote:
> On 31/05/17 02:04, Ian Romanick wrote:
>
> I've seen this warning a million times, and I always talk myself out of
> fixing it. If the type of counterIndex ever changes to int (or another
> signed type), this will break. It may not be o
On Wed, May 31, 2017 at 1:35 AM, Lionel Landwerlin
wrote:
> On 31/05/17 02:04, Ian Romanick wrote:
>
> I've seen this warning a million times, and I always talk myself out of
> fixing it. If the type of counterIndex ever changes to int (or another
> signed type), this will break. It may not be o
On Friday, May 26, 2017 4:30:09 PM PDT Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 70
> ---
> 1 file changed, 30 insertions(+), 40 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965
On Tue, 2017-05-16 at 20:40 +0200, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This reverts commit 0e9991f957e296f46cfff40a94ffba0adf2a58e1.
>
> At least when we fallback because of TGSI, the gl_program objects are
> re-allocated, and we don't in fact already have a reference to the
> gl_sh
On Fri, May 26, 2017 at 1:55 AM, Kenneth Graunke wrote:
> On Wednesday, May 24, 2017 1:04:52 PM PDT Matt Turner wrote:
>> We can encapsulate the logic for choosing the mapping type. This will
>> also help when we add WC mappings.
>
> It might be worth mentioning that this patch changes a few mappi
On Wed, May 31, 2017 at 3:14 PM, Jan Vesely wrote:
> On Wed, 2017-05-31 at 18:32 +0100, Emil Velikov wrote:
> > On 31 May 2017 at 18:18, Jan Vesely wrote:
> > > On Wed, 2017-05-31 at 17:48 +0100, Emil Velikov wrote:
> > > > On 31 May 2017 at 16:32, Marek Olšák wrote:
> > > > > On Wed, May 31, 2
On Mon, May 22, 2017 at 2:40 AM, Iago Toral wrote:
> On Sat, 2017-05-20 at 14:09 -0700, Matt Turner wrote:
>> On Thu, May 18, 2017 at 2:43 AM, Iago Toral Quiroga > m> wrote:
>> > The main change is that we now use round*() instead of IROUND*()
>> > which only
>> > worked for signed integer cases.
On Wed, 2017-05-31 at 18:32 +0100, Emil Velikov wrote:
> On 31 May 2017 at 18:18, Jan Vesely wrote:
> > On Wed, 2017-05-31 at 17:48 +0100, Emil Velikov wrote:
> > > On 31 May 2017 at 16:32, Marek Olšák wrote:
> > > > On Wed, May 31, 2017 at 4:17 PM, Jan Vesely
> > > > wrote:
> > > > > On Wed, 2
On Wed, May 31, 2017 at 1:13 PM, Jason Ekstrand
wrote:
> On Wed, May 31, 2017 at 8:27 AM, Jason Ekstrand
> wrote:
>
>> On Wed, May 31, 2017 at 6:09 AM, Pohjolainen, Topi <
>> topi.pohjolai...@gmail.com> wrote:
>>
>>> On Tue, May 30, 2017 at 11:48:15AM +0300, Pohjolainen, Topi wrote:
>>> > On Fri
On Wed, May 31, 2017 at 8:27 AM, Jason Ekstrand
wrote:
> On Wed, May 31, 2017 at 6:09 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
>> On Tue, May 30, 2017 at 11:48:15AM +0300, Pohjolainen, Topi wrote:
>> > On Fri, May 26, 2017 at 04:30:04PM -0700, Jason Ekstrand wrote:
>> > > Th
On Wed, May 31, 2017 at 11:09 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Wed, May 31, 2017 at 09:57:08AM -0700, Jason Ekstrand wrote:
> > On Wed, May 31, 2017 at 9:10 AM, Jason Ekstrand
> > wrote:
> >
> > > On Wed, May 31, 2017 at 2:15 AM, Pohjolainen, Topi <
> > > topi.pohjo
On Wed, May 31, 2017 at 11:05 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Wed, May 31, 2017 at 10:01:30AM -0700, Jason Ekstrand wrote:
> > On Wed, May 31, 2017 at 8:43 AM, Jason Ekstrand
> > wrote:
> >
> > > On Wed, May 31, 2017 at 6:03 AM, Pohjolainen, Topi <
> > > topi.pohjo
On Wed, May 31, 2017 at 09:57:08AM -0700, Jason Ekstrand wrote:
> On Wed, May 31, 2017 at 9:10 AM, Jason Ekstrand
> wrote:
>
> > On Wed, May 31, 2017 at 2:15 AM, Pohjolainen, Topi <
> > topi.pohjolai...@gmail.com> wrote:
> >
> >> On Fri, May 26, 2017 at 04:30:19PM -0700, Jason Ekstrand wrote:
> >
On Wed, May 31, 2017 at 10:01:30AM -0700, Jason Ekstrand wrote:
> On Wed, May 31, 2017 at 8:43 AM, Jason Ekstrand
> wrote:
>
> > On Wed, May 31, 2017 at 6:03 AM, Pohjolainen, Topi <
> > topi.pohjolai...@gmail.com> wrote:
> >
> >> On Fri, May 26, 2017 at 04:30:31PM -0700, Jason Ekstrand wrote:
> >
On Wed, May 31, 2017 at 08:35:22AM -0700, Jason Ekstrand wrote:
> On Wed, May 31, 2017 at 5:40 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
> > On Tue, May 30, 2017 at 08:29:55PM +0300, Pohjolainen, Topi wrote:
> > > On Tue, May 30, 2017 at 07:32:24AM -0700, Jason Ekstrand wrote:
On Wed, May 31, 2017 at 10:22:09AM -0700, Jason Ekstrand wrote:
> On Tue, May 30, 2017 at 7:29 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
> > On Tue, May 30, 2017 at 10:11:26AM +0300, Pohjolainen, Topi wrote:
> > >
> > > These both go to blitter engine which doesn't understand
On Wed, 2017-05-31 at 17:44 +0200, Marek Olšák wrote:
> On Wed, May 31, 2017 at 4:37 PM, Luke A. Guest wrote:
> > Hi,
> >
> > I've just reinstalled Gentoo on my machine and I no longer have
> > AMDGPU-Pro on it due to it using ancient libs. My machine is an FX-8350
> > one, so it's PCIe-2.0. Clov
On 31 May 2017 at 18:18, Jan Vesely wrote:
> On Wed, 2017-05-31 at 17:48 +0100, Emil Velikov wrote:
>> On 31 May 2017 at 16:32, Marek Olšák wrote:
>> > On Wed, May 31, 2017 at 4:17 PM, Jan Vesely wrote:
>> > > On Wed, 2017-05-31 at 13:33 +0100, Emil Velikov wrote:
>> > > > On 29 May 2017 at 16:3
On Tue, May 30, 2017 at 12:40 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Fri, May 26, 2017 at 04:30:10PM -0700, Jason Ekstrand wrote:
> > The new version now takes a range of levels as well as a range of
> > layers. It should also be a tiny bit faster because it only walks th
On Tue, May 30, 2017 at 12:34 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Fri, May 26, 2017 at 04:30:09PM -0700, Jason Ekstrand wrote:
> > ---
> > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 70
> ---
> > 1 file changed, 30 insertions(+), 40 deletio
On Tue, May 30, 2017 at 7:29 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Tue, May 30, 2017 at 10:11:26AM +0300, Pohjolainen, Topi wrote:
> >
> > These both go to blitter engine which doesn't understand hiz. As the
> > destination is resolved just before the blit, why do we need
On Wed, May 31, 2017 at 2:08 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Fri, May 26, 2017 at 04:30:20PM -0700, Jason Ekstrand wrote:
> > ---
> > src/mesa/drivers/dri/i965/brw_context.c| 2 +-
> > src/mesa/drivers/dri/i965/intel_blit.c | 14 --
> >
On Wed, 2017-05-31 at 17:48 +0100, Emil Velikov wrote:
> On 31 May 2017 at 16:32, Marek Olšák wrote:
> > On Wed, May 31, 2017 at 4:17 PM, Jan Vesely wrote:
> > > On Wed, 2017-05-31 at 13:33 +0100, Emil Velikov wrote:
> > > > On 29 May 2017 at 16:33, Marek Olšák wrote:
> > > > > The "ac" function
This series is
Reviewed-by: Rafael Antognolli
On Wed, May 31, 2017 at 01:17:45AM -0700, Kenneth Graunke wrote:
> We can just update the gl_transform_feedback_info fields at link time
> to make the VUE header fields have the right location and component.
> Then we don't need to handle them specia
On 31 May 2017 at 17:55, Eric Engestrom wrote:
> In all codepaths, this var ends up assigned to the struct, except one:
> a cleanup codepath, where the `close()` was removed, leading to fd leaks.
> Remove the temp fd and assign to the struct field directly instead.
>
> CovID: 1213930
> Fixes: 7ec0
On Wed, May 31, 2017 at 8:43 AM, Jason Ekstrand
wrote:
> On Wed, May 31, 2017 at 6:03 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
>> On Fri, May 26, 2017 at 04:30:31PM -0700, Jason Ekstrand wrote:
>> > This commit reworks the resolve tracking for CCS and MCS to use the new
>> >
On Wed, May 31, 2017 at 9:10 AM, Jason Ekstrand
wrote:
> On Wed, May 31, 2017 at 2:15 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
>> On Fri, May 26, 2017 at 04:30:19PM -0700, Jason Ekstrand wrote:
>> > This commit adds a new unified interface for doing resolves. The basic
>> >
In all codepaths, this var ends up assigned to the struct, except one:
a cleanup codepath, where the `close()` was removed, leading to fd leaks.
Remove the temp fd and assign to the struct field directly instead.
CovID: 1213930
Fixes: 7ec07beedf486d8ab901 ("egl/drm: make use of the
On Fri, May 19, 2017 at 11:41:07AM +0200, Lucas Stach wrote:
> The cpu_fini() call pushes the buffer back into the GPU domain, which needs
> to be done for all buffers, not just the ones with CPU written content. The
> etnaviv kernel driver currently doesn't validate this, but may start to do
> so
On Wed, May 31, 2017 at 6:48 PM, Emil Velikov wrote:
> On 31 May 2017 at 16:32, Marek Olšák wrote:
>> On Wed, May 31, 2017 at 4:17 PM, Jan Vesely wrote:
>>> On Wed, 2017-05-31 at 13:33 +0100, Emil Velikov wrote:
On 29 May 2017 at 16:33, Marek Olšák wrote:
> The "ac" functions could al
On 31 May 2017 at 16:32, Marek Olšák wrote:
> On Wed, May 31, 2017 at 4:17 PM, Jan Vesely wrote:
>> On Wed, 2017-05-31 at 13:33 +0100, Emil Velikov wrote:
>>> On 29 May 2017 at 16:33, Marek Olšák wrote:
>>> > The "ac" functions could also be forked and put into r600 if people
>>> > want to prese
On Tue, May 23, 2017 at 12:07 AM, Timothy Arceri wrote:
> 3. The GLSL IR opts are both slow and not always optimal (possibly
> transforming the code to something that's harder to opt later), but due to
> uniform/varying optimisation requirements some optimisations are required
> *before* we can do
On Wed, May 31, 2017 at 5:55 PM, Luke A. Guest wrote:
>
>> Nobody has worked on RadeonSI OpenCL for quite some time. Even the
>> main developer of R600 and RadeonSI OpenCL (Tom Stellard) was mostly
>> working on ROCm when he was at AMD.
>>
>>> So far I've found that gl sharing is missing as are so
On Wed, May 31, 2017 at 2:15 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Fri, May 26, 2017 at 04:30:19PM -0700, Jason Ekstrand wrote:
> > This commit adds a new unified interface for doing resolves. The basic
> > format is that, prior to any surface access such as texturing or
> Nobody has worked on RadeonSI OpenCL for quite some time. Even the
> main developer of R600 and RadeonSI OpenCL (Tom Stellard) was mostly
> working on ROCm when he was at AMD.
>
>> So far I've found that gl sharing is missing as are some entry points in
>> dispatch.cpp.
> ROCm OpenCL has interop
On Wed, May 31, 2017 at 4:37 PM, Luke A. Guest wrote:
> Hi,
>
> I've just reinstalled Gentoo on my machine and I no longer have
> AMDGPU-Pro on it due to it using ancient libs. My machine is an FX-8350
> one, so it's PCIe-2.0. Clover is currently lacking in CL compliance at
> this time.
>
> So, I'
On Wed, May 31, 2017 at 6:03 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Fri, May 26, 2017 at 04:30:31PM -0700, Jason Ekstrand wrote:
> > This commit reworks the resolve tracking for CCS and MCS to use the new
> > isl_aux_state enum. This should provide much more accurate and
On Wed, May 31, 2017 at 5:40 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Tue, May 30, 2017 at 08:29:55PM +0300, Pohjolainen, Topi wrote:
> > On Tue, May 30, 2017 at 07:32:24AM -0700, Jason Ekstrand wrote:
> > > On Tue, May 30, 2017 at 1:43 AM, Pohjolainen, Topi <
> > > topi.poh
On Wed, May 31, 2017 at 4:17 PM, Jan Vesely wrote:
> On Wed, 2017-05-31 at 13:33 +0100, Emil Velikov wrote:
>> On 29 May 2017 at 16:33, Marek Olšák wrote:
>> > The "ac" functions could also be forked and put into r600 if people
>> > want to preserve the OpenCL support. That would remove the depen
On Wed, May 31, 2017 at 6:09 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Tue, May 30, 2017 at 11:48:15AM +0300, Pohjolainen, Topi wrote:
> > On Fri, May 26, 2017 at 04:30:04PM -0700, Jason Ekstrand wrote:
> > > This patch series does a complete overhaul of the current resolve
>
Forgot to mention I would be testing on R9 390 and R9 380 cards.
Thanks,
Luke.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
I've just reinstalled Gentoo on my machine and I no longer have
AMDGPU-Pro on it due to it using ancient libs. My machine is an FX-8350
one, so it's PCIe-2.0. Clover is currently lacking in CL compliance at
this time.
So, I'm wondering if anyone is actually working on it now that AMD have
aba
On Wed, 2017-05-31 at 13:33 +0100, Emil Velikov wrote:
> On 29 May 2017 at 16:33, Marek Olšák wrote:
> > The "ac" functions could also be forked and put into r600 if people
> > want to preserve the OpenCL support. That would remove the dependency
> > on "ac".
> >
I thought amdgpu.a was supposed
https://bugs.freedesktop.org/show_bug.cgi?id=100988
Tom Hudson changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Tom Hudson -
On 31 May 2017 at 01:55, Ian Romanick wrote:
> I don't understand these warnings, and I have even less understanding of
> how "using" fixes them. For example...
>
> On 05/30/2017 01:47 PM, Rob Herring wrote:
>> clang gives warnings about overloaded virtual functions:
>>
>> src/compiler/glsl/linke
On Tue, May 30, 2017 at 11:48:15AM +0300, Pohjolainen, Topi wrote:
> On Fri, May 26, 2017 at 04:30:04PM -0700, Jason Ekstrand wrote:
> > This patch series does a complete overhaul of the current resolve handling
> > framework inside the i916 OpenGL driver. For HiZ and MCS, the current
> > resolve
On Fri, May 26, 2017 at 04:30:31PM -0700, Jason Ekstrand wrote:
> This commit reworks the resolve tracking for CCS and MCS to use the new
> isl_aux_state enum. This should provide much more accurate and easy to
> reason about tracking. In order to understand, for instance, the
> intel_miptree_pre
https://bugs.freedesktop.org/show_bug.cgi?id=101247
--- Comment #1 from Samuel Pitoiset ---
Thanks for reporting this. I saw your piglit test yesterday. It's a bug yes.
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-
On 30 May 2017 at 16:01, gregory hainaut wrote:
> On Mon, 29 May 2017 17:12:05 +0100
> Emil Velikov wrote:
>
>> On 29 May 2017 at 15:45, Dieter Nützel wrote:
>> > Hi Gregory,
>> >
>> > there isn't currently a copy of this on Mesa-Patchwork.
>> > Can you please send one over there?
>> >
>> > And
https://bugs.freedesktop.org/show_bug.cgi?id=101252
Bug ID: 101252
Summary: eglGetDisplay() is not thread safe
Product: Mesa
Version: git
Hardware: Other
OS: Linux (All)
Status: NEW
Severity: normal
On Tue, May 30, 2017 at 08:29:55PM +0300, Pohjolainen, Topi wrote:
> On Tue, May 30, 2017 at 07:32:24AM -0700, Jason Ekstrand wrote:
> > On Tue, May 30, 2017 at 1:43 AM, Pohjolainen, Topi <
> > topi.pohjolai...@gmail.com> wrote:
> >
> > > On Fri, May 26, 2017 at 04:30:18PM -0700, Jason Ekstrand wr
On 30 May 2017 at 17:51, Rob Herring wrote:
> On Tue, May 30, 2017 at 11:46 AM, Mauro Rossi wrote:
>>
>>
>> 2017-05-30 14:23 GMT+02:00 Rob Herring :
>>>
>>> sysmacros.h was getting implicitly included in types.h until recently in
>>> AOSP master. Define MAJOR_IN_SYSMACROS to explicitly include sy
On 29 May 2017 at 16:33, Marek Olšák wrote:
> The "ac" functions could also be forked and put into r600 if people
> want to preserve the OpenCL support. That would remove the dependency
> on "ac".
>
Any objections if we defer this to the person working on r600+OpenCL,
or is that a must for the ser
https://bugs.freedesktop.org/show_bug.cgi?id=101247
Józef Kucia changed:
What|Removed |Added
See Also||https://bugs.winehq.org/sho
https://bugs.freedesktop.org/show_bug.cgi?id=101247
Bug ID: 101247
Summary: Mesa fails to link GLSL programs with unused output
blocks
Product: Mesa
Version: git
Hardware: All
OS: All
Status: NEW
1 - 100 of 123 matches
Mail list logo
