Okay, got it, thank you for your verification
On 8/10/2018 2:15 PM, Tapani Pälli wrote:
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Tapani P?lli
> Sent: Friday, August 10, 2018 2:15 PM
> To: Zhaowei Yuan; mesa-dev@lists.freedesktop
Ping.
Regards,
Qiang
From: Qiang Yu
Sent: Monday, August 6, 2018 11:19:21 AM
To: mesa-dev@lists.freedesktop.org
Cc: Adam Jackson; Michel Dänzer; Eric Engestrom; Emil Velikov; Yu, Qiang
Subject: [PATCH v3 0/6] support config for third-party DRI driver load
Hi;
On 08/10/2018 09:08 AM, Zhaowei Yuan wrote:
Thank you for reminding me of the mistakes, I'll re-commit a PATCH v3,
thanks
However, I've re-tested those failed cases with latest code on master branch
and got the same result. I don't why you didn't see anything wrong on your
board,
it doesn't
Thank you for reminding me of the mistakes, I'll re-commit a PATCH v3,
thanks
However, I've re-tested those failed cases with latest code on master branch
and got the same result. I don't why you didn't see anything wrong on your
board,
it doesn't make sense.
On 08/07/2018 5:58 PM, Tapani Pälli
On 08/09/2018 06:55 PM, Marek Olšák wrote:
On Thu, Aug 9, 2018 at 1:47 AM, Tapani Pälli wrote:
Hi Marek;
On 08/09/2018 02:55 AM, Marek Olšák wrote:
From: Marek Olšák
---
src/mesa/main/queryobj.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/main/quer
On 08/09/2018 03:24 PM, Andres Gomez wrote:
Tapani, should we also include this in the stable queues ?
I was not sure if this is 'critical enough' for stable, but yes I'm OK
including it there!
Thanks;
On Tue, 2018-08-07 at 08:20 +0300, Tapani Pälli wrote:
Return ir_rvalue::error_value w
"Juan A. Suarez Romero" writes:
> Creates different Docker images containing Mesa built with different
> tools (autotools, meson, scons, etc).
>
> The build is done in 3 levels: the first level creates a base image
> with all the requirements to build Mesa.
>
> The second level (based of the firs
On Thu, Aug 09, 2018 at 04:26:06PM +0300, Andres Gomez wrote:
> Ugh!
>
> Unfortunately, as I've commented at:
> https://bugs.freedesktop.org/show_bug.cgi?id=107359
>
> This is now breaking these other CTS tests:
> GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_error_blitframebuffer_mul
CC:
---
src/amd/vulkan/Android.mk | 2 ++
src/amd/vulkan/Makefile.am | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
index cee3744f40b..51b03561fa7 100644
--- a/src/amd/vulkan/Android.mk
+++ b/src/amd/vulkan/Android.mk
@
Quoting Chad Versace (2018-08-09 10:37:33)
> On Tue 07 Aug 2018, Dylan Baker wrote:
> > Quoting Bas Nieuwenhuizen (2018-08-07 16:14:33)
> >
> >
All patches up to here (including this one) have been pushed to master. I had
comments on patch 8, and I want to follow up with our CI team to make sure we
have all the dependencies for python 3 in our CI.
Dylan
Quoting Mathieu Bridon (2018-08-09 01:27:24)
> Instead of copying the list, then sort
On Thu, Aug 9, 2018 at 7:48 PM, Chad Versace wrote:
> On Wed 08 Aug 2018, Bas Nieuwenhuizen wrote:
>> This became kind of messy as python imports cannot really look up
>> parent/sibling directories. I saw some scripts use sys.path but
>> that became even more messy due to import locations.
>>
>> I
On Thu, Aug 9, 2018 at 7:49 PM, Chad Versace wrote:
> On Wed 08 Aug 2018, Bas Nieuwenhuizen wrote:
>> ---
>> src/vulkan/Makefile.am| 3 +
>> src/vulkan/util/meson.build | 2 +
>> src/vulkan/util/vk_entrypoints_gen.py | 515 ++
>> src/vulkan/ut
On Mon, Jul 23, 2018 at 12:40 PM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 65
> ++
> .../nouveau/codegen/nv50_ir_target_gm107.cpp | 6 +-
> .../nouveau/codegen/nv50_ir_target_nvc0.cpp| 1 +
>
This doesn't work with python 2. It's also pointed out to me that we don't
handle translations in meson at all...
Here's the traceback:
make[5]: Entering directory
'/home/jenkins/workspace/Leeroy_3/repos/mesa/build_m64/src/util/xmlpool'
Updating (ca) ca/LC_MESSAGES/options.mo from
/home/jenkins/
Reviewed-by: Marek Olšák
Marek
On Wed, Aug 1, 2018 at 7:07 PM, Eric Anholt wrote:
> This is just asking for tests to get confused about the HW supporting
> atomics in this shader stage or not, such as
> dEQP-GLES31.functional.shaders.opaque_type_indexing.atomic_counter.const_expression_vertex.
Note that the spec says:
"Querying DEPTH_CLAMP will return TRUE if DEPTH_CLAMP_NEAR_AMD _or_
DEPTH_CLAMP_FAR_AMD is enabled."
Marek
On Wed, Aug 1, 2018 at 11:31 PM, Sagar Ghuge wrote:
> Signed-off-by: Sagar Ghuge
> ---
> src/mesa/main/get.c | 1 +
> src/mesa/main/get_hash_params.p
On 08/09/2018 01:09 PM, Marek Olšák wrote:
> On Wed, Aug 1, 2018 at 11:31 PM, Sagar Ghuge wrote:
>> enable _mesa_PushAttrib() and _mesa_PopAttrib()
>> to handle GL_DEPTH_CLAMP_NEAR_AMD and
>> GL_DEPTH_CLAMP_FAR_AMD tokens.
>>
>> Signed-off-by: Sagar Ghuge
>> ---
>> src/mesa/main/attrib.c | 16
On Thu, Aug 2, 2018 at 2:44 PM, Ian Romanick wrote:
> On 08/02/2018 11:30 AM, Ian Romanick wrote:
>> On 08/01/2018 08:31 PM, Sagar Ghuge wrote:
>>> Add some basic types and storage for the
>>> AMD_depth_clamp_separate extension.
>
> I mentioned this on patch 5, but you should word wrap the commit
On Wed, Aug 1, 2018 at 11:31 PM, Sagar Ghuge wrote:
> enable _mesa_PushAttrib() and _mesa_PopAttrib()
> to handle GL_DEPTH_CLAMP_NEAR_AMD and
> GL_DEPTH_CLAMP_FAR_AMD tokens.
>
> Signed-off-by: Sagar Ghuge
> ---
> src/mesa/main/attrib.c | 16
> 1 file changed, 16 insertions(+)
>
On Wed, Aug 8, 2018 at 11:31 AM Jason Ekstrand wrote:
>
> The Vulkan 1.1.82 spec flipped the order to better match D3D.
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/intel/blorp/blorp_blit.c | 11 ++-
> src/intel/common/gen_sample_positions.h| 8
On Wed, 2018-08-08 at 22:41 -0700, Rodrigo Vivi wrote:
> One more CFL ID added to spec.
>
> Align with kernel commit d0e062ebb3a4 ("drm/i915/cfl:
> Add a new CFL PCI ID.")
>
Reviewed-by: José Roberto de Souza
> Cc: José Roberto de Souza
> Signed-off-by: Rodrigo Vivi
> ---
> intel/intel_chip
On Thu, 2018-08-09 at 18:22 +0100, Emil Velikov wrote:
> In the GLX case, it's required due to server-side rendering. One needs
> a separate primitive for each pbuffer, thus the information can be
> passed long the wire.
I can't parse this. "Primitive"?
So, backstory time. GLX_SGIX_pbuffer was t
Sounds like a missing make current somewhere.
Dave.
On Fri., 10 Aug. 2018, 03:28 Marek Olšák, wrote:
> This will leak the renderbuffer, but that's not the biggest problem.
>
> In your bug report, you said that the renderbuffer was created by
> intel_new_renderbuffer, but this change is for st/m
Am 09.08.2018 um 19:28 schrieb Gert Wollny:
> From: Gert Wollny
>
> The GLSL operations findLSB, findMSB, and countBits always return
> a signed integer type. Let TGSI reflect this.
>
> v2: Properly set values in infer_(src|dst)_type (Thanks Roland
> Schneideregger for pointing out problem
On Wed 08 Aug 2018, Bas Nieuwenhuizen wrote:
> ---
> src/vulkan/Makefile.am| 3 +
> src/vulkan/util/meson.build | 2 +
> src/vulkan/util/vk_entrypoints_gen.py | 515 ++
> src/vulkan/util/vk_extensions.py | 92 +
> src/vulkan/util/vk_e
On Wed 08 Aug 2018, Bas Nieuwenhuizen wrote:
> radv was always just mirroring a derived version of the anv
> version, sometimes hacked together and sometimes very behind.
>
> As we grow more vulkan drivers this repetition makes even less
> sense, so lets merge them. I took the anv generators as th
On Wed 08 Aug 2018, Bas Nieuwenhuizen wrote:
> This became kind of messy as python imports cannot really look up
> parent/sibling directories. I saw some scripts use sys.path but
> that became even more messy due to import locations.
>
> I also move the selections of the dispatch table out of the
On Tue 07 Aug 2018, Dylan Baker wrote:
> Quoting Bas Nieuwenhuizen (2018-08-07 16:14:33)
>
>
>
Quoting Eric Engestrom (2018-08-09 08:36:55)
> On Monday, 2018-08-06 17:50:48 -0700, Dylan Baker wrote:
> > ---
> > meson.build | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/meson.build b/meson.build
> > index c7dd5ddfec6..788021c05e9 100644
> > --- a/meson.bu
From: Gert Wollny
The GLSL operations findLSB, findMSB, and countBits always return
a signed integer type. Let TGSI reflect this.
v2: Properly set values in infer_(src|dst)_type (Thanks Roland
Schneideregger for pointing out problems with my 1st approach)
Signed-off-by: Gert Wollny
---
This will leak the renderbuffer, but that's not the biggest problem.
In your bug report, you said that the renderbuffer was created by
intel_new_renderbuffer, but this change is for st/mesa. Something is
horribly wrong here. The intel driver should not ever end up in
st/mesa, because st/mesa is a
Quoting Eric Anholt (2018-08-07 11:14:16)
> Dylan Baker writes:
>
> > ---
> > src/gallium/meson.build | 4 ++-
> > src/gallium/targets/graw-gdi/meson.build | 36
> > 2 files changed, 39 insertions(+), 1 deletion(-)
> > create mode 100644 src/gallium/ta
Quoting Eric Anholt (2018-08-07 11:12:27)
> Dylan Baker writes:
>
> > ---
> > src/gallium/meson.build | 1 +
> > src/gallium/targets/libgl-gdi/meson.build | 44 +++
> > 2 files changed, 45 insertions(+)
> > create mode 100644 src/gallium/targets/libgl-gdi/
Hi Adam,
On 9 August 2018 at 17:41, Adam Jackson wrote:
> On Thu, 2018-08-09 at 17:20 +0100, Emil Velikov wrote:
>
>> If you have a moment, I'd be interested to know why we're creating a X
>> primitive for pbuffer surface.
>> IIRC pbuffers are used of off-screen rendering, thus having zero
>> kno
Am 09.08.2018 um 19:09 schrieb Gert Wollny:
> Am Donnerstag, den 09.08.2018, 18:52 +0200 schrieb Roland Scheidegger:
>> Am 09.08.2018 um 18:18 schrieb Gert Wollny:
>>> Am Donnerstag, den 09.08.2018, 17:10 +0200 schrieb Roland
>>> Scheidegger:
This is incorrect for umsb.
>>>
>>> Hmm, according
Am Donnerstag, den 09.08.2018, 18:52 +0200 schrieb Roland Scheidegger:
> Am 09.08.2018 um 18:18 schrieb Gert Wollny:
> > Am Donnerstag, den 09.08.2018, 17:10 +0200 schrieb Roland
> > Scheidegger:
> > > This is incorrect for umsb.
> >
> > Hmm, according to the TGSI doc all of those operations inclu
Reviewed-by: Marek Olšák
Marek
On Thu, Aug 9, 2018 at 6:46 AM, Gert Wollny wrote:
> The check for ETC2 compatibility was not updated when the fallback
> format was changed.
>
> Fixes: 71867a0a61cea20bf3f6115692e70b0d60f0b70d
>st/mesa: Fall back to R8G8B8A8_SRGB for ETC2
>
> Signed-off-by: G
Am 09.08.2018 um 18:18 schrieb Gert Wollny:
> Am Donnerstag, den 09.08.2018, 17:10 +0200 schrieb Roland Scheidegger:
>> This is incorrect for umsb.
> Hmm, according to the TGSI doc all of those operations including UMSB
> are supposed to return -1 if no bits are set [1], for me that implies
> that
On Thu, 2018-08-09 at 17:20 +0100, Emil Velikov wrote:
> If you have a moment, I'd be interested to know why we're creating a X
> primitive for pbuffer surface.
> IIRC pbuffers are used of off-screen rendering, thus having zero
> knowledge/dependency on the underlying platform.
pbuffers might be
On Thu, 2018-08-09 at 15:54 +0300, Andres Gomez wrote:
> Adam, which is the status of this patch? Is this effectively dropped?
It's still valid, and still not very important. I'd just forgotten it.
Merged now, thanks for the reminder:
remote: remote: I: patch #191858 updated using rev
63a6b719d9
On 9 August 2018 at 13:51, Andres Gomez wrote:
> Emil, this patch has been stalled in the -stable ML for quite some time
> without update.
>
> Unless you say otherwise, I will just ignore it at this point and trust
> that you will also Cc -stable in the future, in case you come with
> another vers
On 9 August 2018 at 13:53, Andres Gomez wrote:
> Emil, this patch never landed in master (nor got a R-b).
>
> Is this still relevant? Could you manage to get somebody to review it?
>
> I'd do it myself but I'm quite ignorant on the GBM bits.
>
I need to respin the whole series since a few corner-c
On 9 August 2018 at 13:58, Andres Gomez wrote:
> Emil, this patch has been stalled in the -stable ML for quite some time
> without update.
>
> Unless you say otherwise, I will just ignore it at this point and trust
> that you will also Cc -stable in the future, in case you come with
> another vers
On 7 August 2018 at 20:32, Eric Anholt wrote:
> This is basically copied from the DRI2 destroy path. Without this,
> Raspberry Pi would quickly run out of CMA during the EGL tests in the CTS
> due to all the pixmaps laying around.
>
> Fixes: f35198badeb9 ("egl/x11: Implement dri3 support with loa
Am Donnerstag, den 09.08.2018, 17:10 +0200 schrieb Roland Scheidegger:
> This is incorrect for umsb.
Hmm, according to the TGSI doc all of those operations including UMSB
are supposed to return -1 if no bits are set [1], for me that implies
that their return type should be signed.
[1] http://gall
piglit testing the max uniform block size:
Before:
FRAG
PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
DCL OUT[0], COLOR
DCL CONST[0][0]
DCL CONST[1][0..4095]
DCL TEMP[0], LOCAL
IMM[0] UINT32 {0, 16, 0, 0}
0: UMUL TEMP[0].x, CONST[0][0]., IMM[0].
1: LOAD OUT[0], CONSTBUF[1], TEMP[0].
2:
On Thursday, 2018-08-09 09:03:02 -0700, Dylan Baker wrote:
> Quoting Juan A. Suarez Romero (2018-08-07 08:49:36)
> > When creating a windows surface with eglCreateWindowSurface(), the
> > width and height returned by eglQuerySurface(EGL_{WIDTH,HEIGHT}) is
> > invalid until buffers are updated (like
Am 09.08.2018 um 17:57 schrieb Marek Olšák:
> On Thu, Aug 9, 2018 at 1:35 AM, Roland Scheidegger wrote:
>> I'm not quite convinced you can really use huge ubos safely? At least
>> direct addressing in tgsi can't work (you've only got a 16bit register
>> index, and it's signed too).
>
> UBOs use t
On Monday, 2018-08-06 17:50:49 -0700, Dylan Baker wrote:
> completely untested
> ---
> src/getopt/meson.build | 29 +
> src/meson.build| 5 +
> 2 files changed, 34 insertions(+)
> create mode 100644 src/getopt/meson.build
>
> diff --git a/src/getopt/meson
Quoting Juan A. Suarez Romero (2018-08-07 08:49:36)
> When creating a windows surface with eglCreateWindowSurface(), the
> width and height returned by eglQuerySurface(EGL_{WIDTH,HEIGHT}) is
> invalid until buffers are updated (like calling glClear()).
>
> But according to EGL 1.5 spec, section 3.
On Thu, Aug 9, 2018 at 1:35 AM, Roland Scheidegger wrote:
> I'm not quite convinced you can really use huge ubos safely? At least
> direct addressing in tgsi can't work (you've only got a 16bit register
> index, and it's signed too).
UBOs use the LOAD instruction if PIPE_CAP_LOAD_CONSTBUF is supp
On Thu, Aug 9, 2018 at 1:47 AM, Tapani Pälli wrote:
> Hi Marek;
>
> On 08/09/2018 02:55 AM, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> ---
>> src/mesa/main/queryobj.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/qu
On 9 August 2018 at 15:46, Eric Engestrom wrote:
> On Tuesday, 2018-08-07 18:17:09 +0100, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> Instead of having multiple guards littered through the code, simply
>> introduce static inline no-op functions when the respective macros are
>> not set.
>>
>>
On Thu, Aug 9, 2018 at 1:28 AM, Roland Scheidegger wrote:
> Am 09.08.2018 um 01:55 schrieb Marek Olšák:
>> From: Marek Olšák
>>
>> ---
>> src/gallium/auxiliary/tgsi/tgsi_ureg.c | 13 -
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/auxiliary/tgsi/tg
On Monday, 2018-08-06 17:50:48 -0700, Dylan Baker wrote:
> ---
> meson.build | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index c7dd5ddfec6..788021c05e9 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1027,9 +1027,9 @@ endif
> if c
This is incorrect for umsb.
If you really want to move so the dst type is signed, you need to add it
to infer_src_type so the src args are unsigned.
FWIW I'd like to think that all 3 of these always operate on unsigned
data (even if they might return signed data), imho they are a lot more
easier to
On Tuesday, 2018-08-07 12:32:04 -0700, Eric Anholt wrote:
> This is basically copied from the DRI2 destroy path. Without this,
> Raspberry Pi would quickly run out of CMA during the EGL tests in the CTS
> due to all the pixmaps laying around.
>
> Fixes: f35198badeb9 ("egl/x11: Implement dri3 supp
On Tuesday, 2018-08-07 18:17:09 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Instead of having multiple guards littered through the code, simply
> introduce static inline no-op functions when the respective macros are
> not set.
>
> Inspired by the same convention from the kernel.
>
> v2
https://bugs.freedesktop.org/show_bug.cgi?id=107533
Brad King changed:
What|Removed |Added
Resolution|FIXED |WONTFIX
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=107533
Brad King changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thursday, 2018-08-09 10:27:24 +0200, Mathieu Bridon wrote:
> Instead of copying the list, then sorting the copy in-place, we can just
> get a new sorted copy directly.
>
> Signed-off-by: Mathieu Bridon
4-7 are
Reviewed-by: Eric Engestrom
> ---
> src/mapi/mapi_abi.py | 6 ++
> 1 file ch
input locations used by input attributes are not handled in the same
way in OpenGL vs Vulkan. There is a detailed explanation of such
differences on the following commit:
c2acf97fcc9b32eaa9778771282758e5652a8ad4
So with this commit, the same adjustment that is done after
glsl_to_nir, is being don
From: Neil Roberts
The value is copied from the gl_program. If we don’t do this then it
will get reset back to zero in brw_shader_gather_info. This isn’t a
problem for GLSL because in that case the nir_shader is initialised
with a copy of the shader_info from the gl_program.
---
src/mesa/main/gl
From: Iago Toral Quiroga
This is the same we do for vulkan drivers
This is needed to pass the following CTS test:
KHR-GL45.gl_spirv.spirv_modules_shader_binary_multiple_shader_objects_test
---
src/mesa/main/glspirv.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/mesa/
So they are not exposed through the introspection API.
It is worth to note that the number of hidden uniforms of GLSL linking
vs SPIR-V linking would be somewhat different due the differen order
of the nir lowerings/optimizations.
For example: gl_FbWposYTransform. This is introduced as part of
ni
From: Neil Roberts
Instead of using the copy of shader_info stored in gl_program, it now
uses the one in nir_shader. This is needed for SPIR-V because the
info.tess.tcs_vertices_out is filled in via _mesa_spirv_to_nir which
happens much later than with a GLSL shader. The copy of shader_data in
gl
As we plan to reuse it for ARB_gl_spirv implementation.
---
src/compiler/glsl/glsl_to_nir.cpp | 17 -
src/compiler/nir/nir.c| 24
src/compiler/nir/nir.h| 3 +++
3 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/src/co
After commit "nir: Use derefs in nir_lower_samplers"
(75286c2d083cdbdfb202a93349e567df0441d5f7) assumes one deref for both
the texture and the sampler. However there are cases (on OpenGL, using
ARB_gl_spirv) where SPIR-V is not providing a sampler, like for
texture query levels ops. Although we cou
Equivalent to the already existing how_declared at GLSL IR. The only
difference is that we are not adding all the declaration_type
available on GLSL, only the one that we will use on the short term. We
would add more mode if needed on the future.
---
src/compiler/nir/nir.c |
From: Neil Roberts
GLSL has gl_VertexID which is supposed to be non-zero-based.
SPIR-V has both VertexIndex and VertexId builtins whose meanings are
defined by the APIs.
Vulkan defines VertexIndex as being non-zero-based. I can’t find
any mention of what VertexId is supposed to be.
GL_ARB_spir
info.gs.output_primitive was already being filled. Not sure why this
is not needed on Vulkan, but we found to be needed for
ARB_gl_spirv. Specifically, this is needed to get the following test
passing:
KHR-GL45.gl_spirv.spirv_validation_builtin_variable_decorations_test
---
src/compiler/spirv/spi
Hi,
this is the fith series for the ongoing support for ARB_gl_spirv. This
time there is not a common topic for all those patches. They are
patches that we think that are ready, and would be good to send to
review in advance, while we finish other main subfeatures.
The tree for this series can be
On Thu, 2018-08-09 at 15:33 +0200, Bas Nieuwenhuizen wrote:
> On Thu, Aug 9, 2018 at 2:56 PM, Andres Gomez wrote:
> > Bas, James, did you eventually come with a resolution for this? Can I
> > just ignore this nominated patch in the -stable ML?
>
> The fix in this patch landed as part of
Great! T
On Thu, Aug 9, 2018 at 2:56 PM, Andres Gomez wrote:
> Bas, James, did you eventually come with a resolution for this? Can I
> just ignore this nominated patch in the -stable ML?
The fix in this patch landed as part of
commit 68dead112e710b261ad33604175d635dec6afd34
Author: Samuel Pitoiset
Date:
Ugh!
Unfortunately, as I've commented at:
https://bugs.freedesktop.org/show_bug.cgi?id=107359
This is now breaking these other CTS tests:
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_error_blitframebuffer_multisampled_framebuffers_different_formats
GTF-GL46.gtf30.GL3Tests.framebuffer
Hi Andreas,
This change shouldn't brake anything. So yes, it can be included in stable.
On Thu, Aug 9, 2018 at 3:44 PM, Andres Gomez wrote:
> Vadym, should we also include this in the stable queues ?
>
> On Mon, 2018-08-06 at 15:52 +0300, vadym.shovkoplias wrote:
> > This fixes both Metro 2033
https://bugs.freedesktop.org/show_bug.cgi?id=107533
--- Comment #2 from Emil Velikov ---
You're correct - the SONAME does stay intact. One could trivially change that
with patchelf.
Let's take a look at the following combinations:
1) standard vs GLVND
names: GL
symbols: standard
2) GLVND
name
Fredrik, which is the status of this series? Several patches got R-b
but nothing has landed so far. Are you in need of more reviews for the
rest of the patches in the series?
On Tue, 2018-06-26 at 23:49 +0200, Fredrik Höglund wrote:
> The Vulkan specification says:
>
>"An execution dependency
Emil, this patch has been stalled in the -stable ML for quite some time
without update.
Unless you say otherwise, I will just ignore it at this point and trust
that you will also Cc -stable in the future, in case you come with
another version.
On Wed, 2017-09-27 at 17:36 +0200, Juan A. Suarez Rom
Bas, James, did you eventually come with a resolution for this? Can I
just ignore this nominated patch in the -stable ML?
On Wed, 2018-03-28 at 15:28 +0200, Bas Nieuwenhuizen wrote:
> No final resolution yet.
>
> I was trying to fix my minor comment, but looks like I have a bunch of
> CTS regress
We agree.
Reviewed-by: Bruce Cherniak
> On Aug 8, 2018, at 6:50 AM, Juan A. Suarez Romero wrote:
>
> On Mon, 2018-08-06 at 11:52 +0200, Juan A. Suarez Romero wrote:
>> RADV now requires LLVM 6.0 or greater, and thus we can't build dist
>> tarball because swr requires LLVM 5.0.
>>
>> Let's bum
Adam, which is the status of this patch? Is this effectively dropped?
On Wed, 2017-12-06 at 16:13 -0500, Adam Jackson wrote:
> On Wed, 2017-12-06 at 15:01 -0500, Ian Romanick wrote:
> > On 12/06/2017 10:32 AM, Emil Velikov wrote:
> > > On 5 December 2017 at 16:10, Adam Jackson wrote:
> > > > This
Emil, this patch never landed in master (nor got a R-b).
Is this still relevant? Could you manage to get somebody to review it?
I'd do it myself but I'm quite ignorant on the GBM bits.
On Mon, 2017-10-16 at 17:04 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Fold the error handling for i
Emil, this patch has been stalled in the -stable ML for quite some time
without update.
Unless you say otherwise, I will just ignore it at this point and trust
that you will also Cc -stable in the future, in case you come with
another version.
On Tue, 2017-09-26 at 18:52 +0200, Juan A. Suarez Rom
Ville, this patch has been stalled in the -stable ML for quite some
time without update.
Unless you say otherwise, I will just ignore it at this point and trust
that you will also Cc -stable in the future, in case you come with
another version.
On Tue, 2017-09-26 at 18:49 +0200, Juan A. Suarez Ro
Jason, this patch has been stalled in the -stable ML for quite some
time without update.
Unless you say otherwise, I will just ignore it at this point and trust
that you will also Cc -stable in the future, in case you come with
another version.
On Tue, 2017-09-26 at 12:31 +0200, Juan A. Suarez Ro
Vadym, should we also include this in the stable queues ?
On Mon, 2018-08-06 at 15:52 +0300, vadym.shovkoplias wrote:
> This fixes both Metro 2033 Redux and Metro Last Light Redux
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99730
> Signed-off-by: Eero Tamminen
> Signed-off-by: Vad
On 9 August 2018 at 12:20, Christian Gmeiner
wrote:
> Am Do., 9. Aug. 2018 um 12:23 Uhr schrieb Emil Velikov
> :
>>
>> On 9 August 2018 at 06:12, Christian Gmeiner
>> wrote:
>> > Signed-off-by: Christian Gmeiner
>> > ---
>> > src/gallium/drivers/tegra/tegra_screen.c | 1 +
>> > 1 file changed,
Tapani, should we also include this in the stable queues ?
On Tue, 2018-08-07 at 08:20 +0300, Tapani Pälli wrote:
> Return ir_rvalue::error_value with ast_post_inc, ast_post_dec if
> parser error was emitted previously. This way process_array_size
> won't see bogus IR generated like with commit 9c
On 9 August 2018 at 06:12, Christian Gmeiner
wrote:
> Gets rid of hard-coded gpu device path.
>
> Signed-off-by: Christian Gmeiner
> ---
3/4 and 4/4 are
Reviewed-by: Emil Velikov
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://l
On 9 August 2018 at 06:12, Christian Gmeiner
wrote:
> This helper is almost a 1:1 copy of tegra_open_render_node().
>
> Signed-off-by: Christian Gmeiner
> ---
> src/loader/loader.c | 65 +
> src/loader/loader.h | 3 +++
> 2 files changed, 68 insertion
Hi,
Sorry I missed the main thought here.
The "gen_group_get_length" function returns *int*
but the "iter_group_offset_bits" function returns *uint32_t*
So *uint32_t*(*int*(-32)) = *0xFFE0U* and it looks like unexpected
behavior for me:
iter_group_offset_bits(iter, iter->group_iter + 1) < *0xF
https://bugs.freedesktop.org/show_bug.cgi?id=106394
mirh changed:
What|Removed |Added
CC||m...@protonmail.ch
--
You are receiving this ma
The "gen_group_get_length" function can return a negative value
and it can lead to the out of bounds group_iter.
Signed-off-by: Andrii Simiklit
---
src/intel/common/gen_decoder.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/intel/common/gen_decoder.c b/src/intel/
Am Do., 9. Aug. 2018 um 12:23 Uhr schrieb Emil Velikov
:
>
> On 9 August 2018 at 06:12, Christian Gmeiner
> wrote:
> > Signed-off-by: Christian Gmeiner
> > ---
> > src/gallium/drivers/tegra/tegra_screen.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/src/gallium/drivers/tegra/te
https://bugs.freedesktop.org/show_bug.cgi?id=107533
--- Comment #1 from Brad King ---
See also commit 27382c0f7ba2ae826531ba4c254741b2a9df1882.
--
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=107533
Bug ID: 107533
Summary: Please restore --with-{gl, osmesa}-lib-name options
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: norm
On 08/08/2018 06:43 PM, Tapani Pälli wrote:
On 08.08.2018 17:31, Lionel Landwerlin wrote:
On 08/08/18 12:05, Lionel Landwerlin wrote:
On 08/08/18 00:14, Bas Nieuwenhuizen wrote:
radv was always just mirroring a derived version of the anv
version, sometimes hacked together and sometimes ver
The check for ETC2 compatibility was not updated when the fallback
format was changed.
Fixes: 71867a0a61cea20bf3f6115692e70b0d60f0b70d
st/mesa: Fall back to R8G8B8A8_SRGB for ETC2
Signed-off-by: Gert Wollny
---
src/mesa/state_tracker/st_extensions.c | 2 +-
1 file changed, 1 insertion(+), 1
1 - 100 of 119 matches
Mail list logo
