On Thursday, May 18, 2017 9:28:17 PM PDT Kenneth Graunke wrote:
> On Tuesday, March 28, 2017 11:58:54 PM PDT Iago Toral Quiroga wrote:
> > Writing and testing are two different things and they can be set separately
> > by the application. If an application wants to record depth data without
> > car
On 05/19/2017 04:19 AM, Xu, Randy wrote:
-Original Message-
From: Rob Herring [mailto:r...@kernel.org]
Sent: Friday, May 19, 2017 6:01 AM
To: Emil Velikov
Cc: Chih-Wei Huang ; ML mesa-dev ; Xu, Randy
Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
configure and
On Tuesday, March 28, 2017 11:58:54 PM PDT Iago Toral Quiroga wrote:
> Writing and testing are two different things and they can be set separately
> by the application. If an application wants to record depth data without
> caring for the depth test, it can enable depth test and set the depth
> com
APPLE_vertex_array_object support was removed in 7927d0378fc7.
However it turns out we can't remove the functions because this
can cause issues when libglapi is used together with DRI1 drivers
which were branched off from master a few years ago.
---
src/mapi/glapi/gen/APPLE_vertex_array_object.xml
From: Tvrtko Ursulin
Building on top of the previous patch which exported the concept
of engine classes and instances, we can also use this instead of
the current awkward engine selection uAPI.
This is primarily interesting for the VCS engine selection which
is a) currently done via disjoint set
From: Tvrtko Ursulin
Engine discovery uAPI allows userspace to probe for engine
configuration and features without needing to maintain the
internal PCI id based database.
This enables removal of code duplications across userspace
components.
Probing is done via the new DRM_IOCTL_I915_GEM_ENGINE
This series is :
Reviewed-by: Lionel Landwerlin
Thanks for doing this.
Although you seem to have a multithreaded scenario in mind, this will
probably help single threaded stacks like Clutter/Cogl & Mesa all using
the same event queue.
-
Lionel
On 16/05/17 11:05, Daniel Stone wrote:
Untang
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Friday, May 19, 2017 6:01 AM
> To: Emil Velikov
> Cc: Chih-Wei Huang ; ML mesa-dev d...@lists.freedesktop.org>; Xu, Randy
> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
> configure and reo
For the gallium state tracker a tgsi binary may have been evicted
from the cache to make space. In this case we would take the
fallback path and recompile/link the shader.
On i965 there are a number of reasons we can get to the program
upload stage and have neither IR nor a valid cached binary.
Fo
When we fallback currently the gl_program objects are re-allocated.
This is likely to change when the i965 cache lands, but for now
this fixes a crash when using MESA_GLSL=cache_fb. This env var
simulates the fallback path taken when a tgsi cache item doesn't
exist due to being evicted previously
On 18 May 2017 at 19:53, Nicolai Hähnle wrote:
> Hi all,
>
> This is v2 of the second half of a series I sent earlier, to move
> radv to a shared code base for surface computations. I integrated
> patches by Dave that should fix radv issues. The series is also at
> https://cgit.freedesktop.org/~nh
This platform passes the following GLES3 tests:
ES3-CTS.functional.texture.compressed.astc.endpoint_value_hdr_cem_*
Signed-off-by: Nanley Chery
---
src/mesa/drivers/dri/i965/intel_extensions.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/
Signed-off-by: Nanley Chery
---
src/intel/isl/isl.h | 14 ++
src/intel/isl/isl_format.c | 32 ++--
src/intel/isl/isl_format_layout.csv | 14 ++
3 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/src/intel/is
We simply pick r4 if available (anything else would force a MOV), then
round-robin through accumulators (avoids physical regfile RAW delay
slots), then round-robin through the physical regfile.
The effect on instruction count is pretty impressive:
total instructions in shared programs: 76563 -> 7
All the paths looping over adjacency had guards against considering
themselves (the non-obvious one was ra_any_neighbors_conflict(), which has
in_stack set).
---
src/util/register_allocate.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/src/util/regi
VC4 has had a tension, similar to pre-Sandybridge Intel, where we want to
use low-numbered registers (more parallelism on Intel, fewer delay slots
on vc4), but in order to give instruction scheduling the most freedom to
avoid delays we want to round-robin between registers of the same cost.
Our two
I was going to indent this code another level, and decided it would be
easier to read as a helper.
---
src/util/register_allocate.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c
inde
Thomas Helland writes:
> Use our knowledge that pointers are at least 4 byte aligned to remove
> the useless digits. Then shift by 6, 10, and 14 bits and add this to
> the original pointer, effectively folding in the entropy of the higher
> bits of the pointer into a 4-bit section. Stopping at 14
Both patches are:
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, May 18, 2017 at 5:25 AM, Emil Velikov wrote:
> On 18 May 2017 at 05:10, Chih-Wei Huang wrote:
>> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>>>
-Original Message-
From: Palli, Tapani
>
> It's just applied. Isn't it?
> Yesterday without this patch
> the co
On 19/05/17 05:01, Thomas Helland wrote:
This is shorter and easier on the eyes. At the same time this
also ensures that we are always asserting that the table pointer
is not NULL. Currently that was not done for all situations.
Can we also have another patch that moves _mesa_HashUnlockMutex an
rb
On Thu, May 11, 2017 at 4:46 PM, Nanley Chery wrote:
> The DXT1_RGB* format does not provide the correct behavior for Vulkan in
> the case where color_0 <= color_1. BC1_RGB_UNORM with a alpha set to 1
> provides the behavior which matches the spec.
>
> Bugzilla: https://bugs.freedesktop.org/s
On Thu, May 18, 2017 at 11:23 PM, Matt Arsenault wrote:
>
>> On May 18, 2017, at 22:46, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> so that LLVM doesn't allocate SGPRs where XNACK is.
>>
>> Cc: 17.1
>
> You shouldn’t be explicitly enabling xnack. This sounds like a workaround for
> a back
Every push a developer does to a travis-enabled github comes back as fail,
because the unit tests are already failing:
Testing util_format_dxt5_rgba_pack_rgba_float ...
FAILED: 40 bd 48 90 20 01 12 20 53 76 ab 32 00 10 15 50 obtained
f8 11 c5 0c 9a 73 b4 9c f6 8f ab 32 2a 9a 9
Reviewed-by: Marek Olšák
Marek
On Thu, May 18, 2017 at 9:39 PM, Thomas Helland
wrote:
> Use our knowledge that pointers are at least 4 byte aligned to remove
> the useless digits. Then shift by 6, 10, and 14 bits and add this to
> the original pointer, effectively folding in the entropy of the
Cool, thanks!
Reviewed-by: Lionel Landwerlin
On 18/05/17 22:10, Jason Ekstrand wrote:
I just sent a patch to address that. Thanks!
On Thu, May 18, 2017 at 2:04 PM, Lionel Landwerlin
mailto:lionel.g.landwer...@intel.com>>
wrote:
This looks good, but I wonder whether we're missing a vk
Reviewed-by: Lionel Landwerlin
On 18/05/17 22:09, Jason Ekstrand wrote:
We weren't wrapping this before because anv_cmd_buffer_execbuf may throw
a more meaningful error message. However, we do change the error code
into VK_ERROR_DEVICE_LOST, so we should print a new message.
---
src/intel/vu
> On May 18, 2017, at 22:46, Marek Olšák wrote:
>
> From: Marek Olšák
>
> so that LLVM doesn't allocate SGPRs where XNACK is.
>
> Cc: 17.1
You shouldn’t be explicitly enabling xnack. This sounds like a workaround for a
backend bug, and this has other consequences than changing the reserved
I just sent a patch to address that. Thanks!
On Thu, May 18, 2017 at 2:04 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> This looks good, but I wonder whether we're missing a vk_errorf() in
> anv_QueueSubmit() when we get an error from anv_cmd_buffer_execbuf().
> In that case it
We weren't wrapping this before because anv_cmd_buffer_execbuf may throw
a more meaningful error message. However, we do change the error code
into VK_ERROR_DEVICE_LOST, so we should print a new message.
---
src/intel/vulkan/anv_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This looks good, but I wonder whether we're missing a vk_errorf() in
anv_QueueSubmit() when we get an error from anv_cmd_buffer_execbuf().
In that case it looks like we won't abort.
On 18/05/17 21:51, Jason Ekstrand wrote:
This is mostly for running in our CI system to prevent dEQP from
continu
---
src/intel/vulkan/anv_device.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 8eed7f3..532d4b9 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -153,6 +153,18 @@ anv_physical_
---
src/intel/vulkan/anv_device.c | 6 --
src/intel/vulkan/anv_private.h | 11 ++-
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 9444ff8..bb02378 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src
This patch is completely untested but the math and logic should be
right. It's mostly intended as an example of how to extend the pass.
---
src/intel/blorp/blorp_clear.c | 80 ++-
1 file changed, 63 insertions(+), 17 deletions(-)
diff --git a/src/intel/blo
This makes us walk over the heaps one at a time and add the types for
LLC and !LLC to each heap.
---
src/intel/vulkan/anv_device.c | 76 +++
1 file changed, 40 insertions(+), 36 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_
---
src/intel/vulkan/anv_device.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 8bf52cc..b0ccbbb 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1758,6 +1758,7 @@ void
Instead of returning valid types as just a number, we now walk the list
and check the buffer's usage against the usage flags we store in the new
anv_memory_type structure. Currently, valid_buffer_usage == ~0.
---
src/intel/vulkan/anv_device.c | 21 +++--
src/intel/vulkan/anv_priv
The idea behind doing this was to make it easier to set various flags.
However, we have enough custom flag settings floating around the driver
that this is more of a nuisance than a help.
---
src/intel/vulkan/anv_allocator.c | 17 ++---
src/intel/vulkan/anv_device.c| 12 ++-
---
src/intel/vulkan/anv_device.c | 42 --
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 6ea8dfe..8eed7f3 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/a
---
src/intel/vulkan/anv_image.c | 12 ++--
src/intel/vulkan/genX_cmd_buffer.c | 9 +
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index d21e055..d65ef47 100644
--- a/src/intel/vulkan/anv_image.c
Before, we were just comparing the type index to 0. Now we actually
look the type up in the table and check its properties to determine what
kind of mapping we want to do.
---
src/intel/vulkan/anv_device.c | 12 ++--
src/intel/vulkan/anv_private.h | 2 +-
2 files changed, 7 insertions(+
This doesn't matter right now since it only affects whether or not we
set the kernel bit but, if we ever do anything else based on it, we'll
want it to be correct per-gen.
---
src/intel/vulkan/anv_device.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/a
---
src/intel/vulkan/anv_device.c | 113 +
src/intel/vulkan/anv_private.h | 8 ++-
2 files changed, 77 insertions(+), 44 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index b80715f..523d40e 100644
--- a/src/intel
Up until now, we've been memsetting the auxiliary surface to 0 at
BindImageMemory time to ensure that it is properly initialized.
However, this isn't correct because apps are allowed to freely alias
memory between different images and buffers so long as they properly
track whether or not a particul
---
src/intel/isl/isl.c| 7 +++
src/intel/isl/isl.h| 6 ++
src/mesa/drivers/dri/i965/intel_blit.c | 2 +-
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index f89f351..86eaf61 100644
--- a/src
---
src/intel/blorp/blorp.h | 5 +++
src/intel/blorp/blorp_clear.c | 101 ++
2 files changed, 106 insertions(+)
diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
index eab75d7..9d3c9ad 100644
--- a/src/intel/blorp/blorp.h
+++ b/src/inte
This causes dEQP-VK.api.copy_and_blit.resolve_image.partial.* to start
failing due to test bugs. See CL 1031 for a test fix.
---
src/intel/vulkan/anv_blorp.c | 40 ++
src/intel/vulkan/anv_private.h | 5 +
src/intel/vulkan/genX_cmd_buffer.c | 25 +
This patch series aims to fix the remaining 48-bit problems in the Vulkan
driver. As such, the entire thing will be CC'd to stable before landing.
The first 5 patches fix the driver to handle memory aliasing correctly.
Vulkan allows you to bind multiple buffers or images to overlapping memory
reg
This is mostly for running in our CI system to prevent dEQP from
continuing on to the next test if we get a GPU hang. As it currently
stands, dEQP uses the same VkDevice for almost all tests and if one of
the tests hangs, we set the anv_device::device_lost flag and report
VK_ERROR_DEVICE_LOST for
From: Marek Olšák
so that LLVM doesn't allocate SGPRs where XNACK is.
Cc: 17.1
---
src/gallium/drivers/radeonsi/si_pipe.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index eaa
+Ken
On Tue, May 16, 2017 at 10:17:11AM -0700, Nanley Chery wrote:
> The procedure for decompressing an opaque BC1 Vulkan format is dependant on
> the
> comparison of two colors stored in the first 32 bits of the compressed block.
> Here's the specified OpenGL (and Vulkan) behavior for reference:
Looks good to me.
Reviewed-by: Samuel Pitoiset
On 05/18/2017 09:01 PM, Thomas Helland wrote:
This is shorter and easier on the eyes. At the same time this
also ensures that we are always asserting that the table pointer
is not NULL. Currently that was not done for all situations.
---
src/mes
Use our knowledge that pointers are at least 4 byte aligned to remove
the useless digits. Then shift by 6, 10, and 14 bits and add this to
the original pointer, effectively folding in the entropy of the higher
bits of the pointer into a 4-bit section. Stopping at 14 means we can
add the entropy fro
This is shorter and easier on the eyes. At the same time this
also ensures that we are always asserting that the table pointer
is not NULL. Currently that was not done for all situations.
---
src/mesa/main/hash.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff
Eric Anholt writes:
> This series came out of fixing dEQP failures on vc4's GLES2 context.
> Mesa was allowing RGB565 textures, which is only valid with
> GL_OES_required_internalformat. Rather than disable RGB565, I decided
> the extension was easy enough to support.
>
> I've sent one piglit te
Hey,
Emil Velikov wrote on 18.05.2017 18:17:
> On 18 May 2017 at 16:34, Rowley, Timothy O wrote:
>> We could use a gen_builder.h generated from llvm-3.9 for all current
>> versions of llvm at this time (as the changes are now just llvm IR
>> additions), but I’m not sure how to enforce that the per
On Thu, May 18, 2017 at 06:38:04PM +0100, Emil Velikov wrote:
> On 18 May 2017 at 18:32, Emil Velikov wrote:
> > Hi Nanley,
> >
> > Has the patch need superseded by any chance or it's lacking review?
> >
> I'm blind - of course it is (alongside v3 2/2).
>
> At the same time neither of the two has
Hi Nicolai,
Afaict this patch depends the following two. And while the latter
seems fairly trivial, I'm less confident about the former.
Can you shed some light here - do we need this patch for 17.1, does it
have any requirements?
9fd9a7d0ba39ed2328b1d48cd8ae83f070202f51 radeonsi: remove VS epilo
On 18 May 2017 at 18:32, Emil Velikov wrote:
> Hi Nanley,
>
> Has the patch need superseded by any chance or it's lacking review?
>
I'm blind - of course it is (alongside v3 2/2).
At the same time neither of the two has landed in master even though
they've been reviewed by Ken.
Just a humble ping
Hi Nanley,
Has the patch need superseded by any chance or it's lacking review?
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Gents,
seems like this patch hasn't landed in master yet.
Has it fallen through the cracks or?
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=101071
--- Comment #5 from war...@o2.pl ---
Emil,
One thing:
in configure I see:
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINA
On Thu 18 May 2017, Tapani Pälli wrote:
> On 05/18/2017 12:16 AM, Tomasz Figa wrote:
> > Hi,
> >
> > On Tue, May 16, 2017 at 11:35 PM, Tapani Pälli
> > wrote:
> > >
> > > On 05/16/2017 08:10 PM, Chad Versace wrote:
> > > > On Tue 16 May 2017, Tapani Pälli wrote:
> > > > >
> > > > >
> > > > >
On Fri, May 12, 2017 at 4:38 PM, Anuj Phogat wrote:
> gen10 specific functions:
> isl_gen10*()
> gen10_blorp_exec()
> gen10_init_atoms()
>
> Signed-off-by: Anuj Phogat
> ---
> src/intel/isl/isl.c | 12 +---
> src/mesa/drivers/dri/i965/brw_blorp.c| 2 +-
>
Hi Emil,
On 18 May 2017 at 17:22, Emil Velikov wrote:
> On 16 May 2017 at 11:02, Daniel Stone wrote:
>> Ideally get_back_bo() failing should store a failure flag inside the
>> surface and cause the next SwapBuffers to fail, but for the meantime,
>> restore the correct behaviour such that get_bac
On Thu, May 18, 2017 at 05:20:38PM +0100, Tvrtko Ursulin wrote:
>
> On 18/05/2017 14:37, Chris Wilson wrote:
> >On Thu, May 18, 2017 at 02:06:35PM +0100, Tvrtko Ursulin wrote:
> >>
> >>But this problem in general can also be solved separately from
> >>class-instance addressing via engine feature m
Reviewed-by: Marek Olšák
Marek
On Thu, May 18, 2017 at 7:22 AM, Timothy Arceri wrote:
> This will explicitly state that we are following the fallback
> path when we find invalid/corrupt cache items. It will also
> output the fallback message when the fallback path is forced
> via an environment
This patch:
Reviewed-by: Marek Olšák
Marek
On Thu, May 18, 2017 at 11:53 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This is needed by radv for dEQP-VK.renderpass.simple.stencil
> ---
> src/amd/common/ac_surface.c | 75
> ++---
> 1 file chang
Hi Dan,
On 16 May 2017 at 11:02, Daniel Stone wrote:
> Ideally get_back_bo() failing should store a failure flag inside the
> surface and cause the next SwapBuffers to fail, but for the meantime,
> restore the correct behaviour such that get_back_bo() no longer fails.
JFYI, we already have the e
On 18/05/2017 14:37, Chris Wilson wrote:
On Thu, May 18, 2017 at 02:06:35PM +0100, Tvrtko Ursulin wrote:
On 18/05/2017 13:24, Chris Wilson wrote:
Yes, I would argue to defer it until later. One problem I have at the
moment is that not all members of a class are equal, HEVC-capable
engines and
On 18 May 2017 at 16:34, Rowley, Timothy O wrote:
>
> We could use a gen_builder.h generated from llvm-3.9 for all current
> versions of llvm at this time (as the changes are now just llvm IR
> additions), but I’m not sure how to enforce that the person creating the
> tarball has a particular ver
On May 17, 2017, at 12:08 PM, Emil Velikov
mailto:emil.l.veli...@gmail.com>> wrote:
On 10 May 2017 at 03:51, Chuck Atkins
mailto:chuck.atk...@kitware.com>> wrote:
I just tried to build 17.0.4-rc4 from the tarball with swr enabled and got
errors about my python not having mako:
make[5]: Enterin
On Thu, May 18, 2017 at 03:58:26PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Building on top of the previous patch which exported the concept
> of engine classes and instances, we can also use this instead of
> the current awkward engine selection uAPI.
>
> This is primarily intere
On 18/05/2017 15:10, Emil Velikov wrote:
Hi Tvrtko,
On 18 May 2017 at 14:06, Tvrtko Ursulin wrote:
struct drm_i915_engine_info {
/** Engine instance number. */
__u32 instance;
__u32 rsvd;
/** Engine specific features and info. */
#define DRM_I915_ENGINE_H
https://bugs.freedesktop.org/show_bug.cgi?id=98833
--- Comment #19 from Daniel Stone ---
(In reply to Daniel Stone from comment #18)
> Right, here we are:
> https://lists.freedesktop.org/archives/mesa-dev/2017-May/155791.html
Eero, are you able to test this?
--
You are receiving this mail beca
Hi Tvrtko,
On 18 May 2017 at 14:06, Tvrtko Ursulin wrote:
> struct drm_i915_engine_info {
> /** Engine instance number. */
> __u32 instance;
> __u32 rsvd;
>
> /** Engine specific features and info. */
> #define DRM_I915_ENGINE_HAS_HEVCBIT(0)
>
On Thu, May 18, 2017 at 02:30:56PM +0100, Tvrtko Ursulin wrote:
>
> On 17/05/2017 17:44, Chris Wilson wrote:
> >On Wed, May 17, 2017 at 04:40:57PM +0100, Tvrtko Ursulin wrote:
> >>+static struct intel_engine_cs *get_engine_class(struct drm_i915_private
> >>*i915,
> >>+
On Thu, May 18, 2017 at 02:06:35PM +0100, Tvrtko Ursulin wrote:
>
> On 18/05/2017 13:24, Chris Wilson wrote:
> >Yes, I would argue to defer it until later. One problem I have at the
> >moment is that not all members of a class are equal, HEVC-capable
> >engines and the reset do not belong to the s
On 17/05/2017 17:44, Chris Wilson wrote:
On Wed, May 17, 2017 at 04:40:57PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Building on top of the previous patch which exported the concept
of engine classes and instances, we can also use this instead of
the current awkward engine selection
https://bugs.freedesktop.org/show_bug.cgi?id=101071
--- Comment #4 from Emil Velikov ---
> [piotro@minimyth-dev ~]$ ldd -r
> /home/piotro/minimyth-dev/images/build/usr/lib/gcc/x86_64-minimyth-linux-gnu/
> 5.3.0/libstdc++.so
> linux-vdso.so.1 (0x7ffee99fd000)
> libm.so.6 => /us
On 18/05/2017 13:24, Chris Wilson wrote:
On Thu, May 18, 2017 at 01:13:20PM +0100, Tvrtko Ursulin wrote:
On 18/05/2017 12:10, Chris Wilson wrote:
On Thu, May 18, 2017 at 01:55:59PM +0300, Joonas Lahtinen wrote:
On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
B
https://bugs.freedesktop.org/show_bug.cgi?id=101088
--- Comment #3 from raffa...@zoho.com ---
Sorry previously attached backtrace is invalid, please ignore it.
--
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=99467
Sven Arvidsson changed:
What|Removed |Added
CC||s...@whiz.se
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=101088
--- Comment #2 from raffa...@zoho.com ---
Created attachment 131405
--> https://bugs.freedesktop.org/attachment.cgi?id=131405&action=edit
winedbg backtrace
winedbg crashes at startup with memory corruption
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=101071
--- Comment #3 from war...@o2.pl ---
Emil,
BTW, You wrote:
Can you check with the libstdc++.so authors that they use "-no-undefined
-Wl,--no-undefined" to the LDFLAGS. It will flag issues as the binary is
linked.
why then I hasn't any issues
On Thu, May 18, 2017 at 01:13:20PM +0100, Tvrtko Ursulin wrote:
>
> On 18/05/2017 12:10, Chris Wilson wrote:
> >On Thu, May 18, 2017 at 01:55:59PM +0300, Joonas Lahtinen wrote:
> >>On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote:
> >>>From: Tvrtko Ursulin
> >>>
> >>>Building on top of the
On 18/05/2017 12:10, Chris Wilson wrote:
On Thu, May 18, 2017 at 01:55:59PM +0300, Joonas Lahtinen wrote:
On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Building on top of the previous patch which exported the concept
of engine classes and instances, we can also
https://bugs.freedesktop.org/show_bug.cgi?id=101088
--- Comment #1 from raffa...@zoho.com ---
`-O2` was looking fine, but turns out it's just a little more stable. Less
glitches and fewer crashes, but still broken.
--
You are receiving this mail because:
You are the assignee for the bug.
You are
https://bugs.freedesktop.org/show_bug.cgi?id=101088
Bug ID: 101088
Summary: `gallium: remove pipe_index_buffer and
set_index_buffer` causes glitches and crash in gallium
nine
Product: Mesa
Version: git
H
On 18.05.2017 12:43, Marek Olšák wrote:
On Thu, May 18, 2017 at 12:41 PM, Marek Olšák wrote:
On Thu, May 18, 2017 at 11:31 AM, Nicolai Hähnle wrote:
On 17.05.2017 21:38, Marek Olšák wrote:
From: Marek Olšák
This decreases the size of CE RAM dumps to L2, or the size of descriptor
uploads w
On Thu, May 18, 2017 at 01:55:59PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Building on top of the previous patch which exported the concept
> > of engine classes and instances, we can also use this instead of
> > the
On 05/18/2017 12:16 AM, Tomasz Figa wrote:
Hi,
On Tue, May 16, 2017 at 11:35 PM, Tapani Pälli wrote:
On 05/16/2017 08:10 PM, Chad Versace wrote:
On Tue 16 May 2017, Tapani Pälli wrote:
On 05/16/2017 02:04 AM, Chad Versace wrote:
Fixes regressions in Android CtsVerifier.apk on Intel Chrom
On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Building on top of the previous patch which exported the concept
> of engine classes and instances, we can also use this instead of
> the current awkward engine selection uAPI.
>
> This is primarily interesting fo
On Thu, May 18, 2017 at 12:41 PM, Marek Olšák wrote:
> On Thu, May 18, 2017 at 11:31 AM, Nicolai Hähnle wrote:
>> On 17.05.2017 21:38, Marek Olšák wrote:
>>>
>>> From: Marek Olšák
>>>
>>> This decreases the size of CE RAM dumps to L2, or the size of descriptor
>>> uploads without CE.
>>> ---
>>>
On Thu, May 18, 2017 at 11:31 AM, Nicolai Hähnle wrote:
> On 17.05.2017 21:38, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> This decreases the size of CE RAM dumps to L2, or the size of descriptor
>> uploads without CE.
>> ---
>> src/gallium/drivers/radeonsi/si_compute.c | 28 ++--
Can you make sure whatever you do it's well tested
I shudder every time I see such requests as it nearly always seems to cause
breakage for me
On Thu, 18 May 2017 at 11:25 Emil Velikov wrote:
> On 18 May 2017 at 05:10, Chih-Wei Huang wrote:
> > 2017-05-18 12:01 GMT+08:00 Xu, Randy :
> >>
> >>>
On Thu, May 18, 2017 at 11:28 AM, Nicolai Hähnle wrote:
> On 17.05.2017 21:38, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> Constant buffers: slot[16], .. slot[31] (ascending)
>> Shader buffers: slot[15], .. slot[0] (descending)
>>
>> The idea is that if we have 4 constant buffers and 2 shade
On 18 May 2017 at 03:55, Chih-Wei Huang wrote:
> 2017-05-17 21:11 GMT+08:00 Emil Velikov :
>> On 17 May 2017 at 13:45, Rob Herring wrote:
>>> On Wed, May 17, 2017 at 12:10 AM, Chih-Wei Huang
>>> wrote:
Commit 6facb0c0 ("android: fix libz dynamic library dependencies")
unconditionally a
On 18 May 2017 at 05:10, Chih-Wei Huang wrote:
> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>>
>>> -Original Message-
>>> From: Palli, Tapani
>>> >
>>> > It's just applied. Isn't it?
>>> > Yesterday without this patch
>>> > the color format is mismatch apparently.
>>>
>>> Yeah we do need this.
On 18 May 2017 at 08:21, Tapani Pälli wrote:
> Function droid_swap_buffers may get called without dri2_surf->buffer set,
> in these cases we don't have a back buffer set either. Patch fixes segfault
> seen with 3DMark that uses android.opengl.GLSurfaceView for rendering it's UI.
>
> backtrace:
>
1 - 100 of 135 matches
Mail list logo
