From: Vadym Shovkoplias
Fix incomplete check of input params in blorp_surf_convert_to_uncompressed()
which can lead to NULL pointer dereferencing.
---
src/intel/blorp/blorp_blit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/bl
On 27/11/17 23:36, Ian Romanick wrote:
> On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
>> From: Nicolai Hähnle
>>
>> For drivers to declare which SPIR-V features they support.
>> ---
>> src/mesa/main/mtypes.h | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/src/mesa/main/mtypes.
On 27/11/17 23:02, Ian Romanick wrote:
> On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
>> From: Alejandro Piñeiro
>>
>> Needed for ARB_gl_spirv. Right now those are the same that the intel
>> vulkan driver, but those are not shared. From the ARB_spirv_extensions
>> spec:
>>
>>"3. If a new
On 27/11/17 23:12, Ian Romanick wrote:
> On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
>> From: Alejandro Piñeiro
>>
>> ---
>> src/mapi/glapi/gen/ARB_spirv_extensions.xml | 13
>> src/mapi/glapi/gen/Makefile.am | 1 +
>> src/mapi/glapi/gen/gl_API.xml |
On 11/27/2017 5:26 PM, Nicolai Hähnle wrote:
On 24.11.2017 06:22, Satyajit Sahu wrote:
Add tiled to linear conversion and expose outside mesa. This function
converts
tiled image to linear and vice versa.
One of the use-case is, a chromiumos test case where the captured fb is
compared against
On 11/27/2017 11:15 PM, Ian Romanick wrote:
On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
From: Nicolai Hähnle
---
src/mapi/glapi/gen/ARB_gl_spirv.xml | 21 ++
src/mapi/glapi/gen/Makefile.am | 1 +
src/mapi/glapi/gen/gl_API.xml | 4 +++
src/mapi/gl
2017-11-27 7:32 GMT+01:00 Wladimir J. van der Laan :
> Hello Christian,
>
> On Sat, Nov 25, 2017 at 05:10:36PM +0100, Christian Gmeiner wrote:
>> 2017-11-18 10:44 GMT+01:00 Wladimir J. van der Laan :
>> > Update state objects to add new state, and emit function to emit new
>> > state.
>> >
>> > Sig
On 11/27/2017 11:06 AM, Alejandro Piñeiro wrote:
On 27/11/17 03:22, Timothy Arceri wrote:
I suspect this patch doesn't compile. I think pEntryPoint is meant to
be passed as an argument to this function.
pEntryPoint is passed as an argument. What makes you think it is not?
It is the second pa
On 11/27/2017 11:34 PM, Ian Romanick wrote:
On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
From: Nicolai Hähnle
v2: Add a gl_shader_spirv_data member to gl_shader, which already
encapsulates a gl_spirv_module where the binary will be saved.
(Eduardo Lima)
---
src/mesa/main/glspirv
On Monday, 2017-11-27 14:44:58 -0500, Ben Crocker wrote:
> Power8, Power8NV, and Power9 are supported on an equal footing
> with X86.
>
> Cc: "17.2" "17.3"
> Signed-off-by: Ben Crocker
> ---
> docs/llvmpipe.html | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
>
On Mon, 2017-11-27 at 18:37 +0100, Juan A. Suarez Romero wrote:
> Commit 78942e ("mesa: shrink VERT_ATTRIB bitfields to 32 bits") uses
> vs_prog_data->vs_inputs as if it were a 32-bit unsigned integer.
>
> But actually it is a 64-bit integer, and as such it is used in other
> parts of Mesa code.
This patch series is still unreviewed.
Sam
On Tue, 2017-11-21 at 07:25 +0100, Samuel Iglesias Gonsálvez wrote:
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/compiler/spirv/spirv_to_nir.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/compiler/spirv/spirv_to_nir.c
> b/src/
This patch is still unreviewed.
Sam
On Wed, 2017-11-15 at 07:39 +0100, Samuel Iglesias Gonsálvez wrote:
> We can write to the same output but in different components, like
> in this example:
>
> layout(location = 0, component = 0) out ivec2 dEQP_FragColor_0;
> layout(location = 0, component = 2)
This patch series is still unreviewed.
Sam
On Thu, 2017-11-09 at 12:48 +0100, Samuel Iglesias Gonsálvez wrote:
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/compiler/glsl/link_interface_blocks.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/gl
This patch is still unreviewed.
Sam
On Tue, 2017-11-14 at 09:45 +0100, Samuel Iglesias Gonsálvez wrote:
> The HW has some limits but, according to the spec, we can create
> the image as it has not yet any memory backing it. This patch
> logs a debug error and set the size to the UINT64_MAX in ord
This patch is still unreviewed.
Sam
On Wed, 2017-10-18 at 09:54 +0200, Samuel Iglesias Gonsálvez wrote:
> Fixes:
>
> dEQP-VK.spirv_assembly.instruction.*.image_sampler.*
>
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/compiler/spirv/vtn_cfg.c | 19 +++
> 1 file change
On Monday, 2017-11-27 22:00:43 +0100, Robert Foss wrote:
> Hey Rob,
>
> On Mon, 2017-11-27 at 13:42 -0600, Rob Herring wrote:
> > On Mon, Nov 27, 2017 at 8:14 AM, Robert Foss > om> wrote:
> > > From: Tomasz Figa
> > >
> > > There is no API available to properly query the
> > > IMPLEMENTATION_DE
Hi,
I've already prepared a patch that documents this, I was going to post
it with the v2 of this series. My version looks like this:
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 6b5c5bbb36..9c04a3c727 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2
On Monday, 2017-11-27 19:08:42 -0800, Jason Ekstrand wrote:
> On Mon, Nov 27, 2017 at 7:00 PM, Ian Romanick wrote:
>
> > I am strongly in favor of this precedent. One thing that has annoyed me
> > for years about Mesa's OpenGL code is the use of mixed suffixes through
> > the code base as an ext
On Monday, 2017-11-27 13:21:31 +0200, Tapani Pälli wrote:
>
>
> On 11/15/2017 03:22 PM, Eduardo Lima Mitev wrote:
> > From: Alejandro Piñeiro
> >
> > Ideally this should be generated somehow. One option would be gather
> > all the extension dependencies listed on the core grammar, but there
> >
Hi;
On 11/27/2017 04:14 PM, Robert Foss wrote:
From: Tomasz Figa
There is no API available to properly query the IMPLEMENTATION_DEFINED
format. As a workaround we rely here on gralloc allocating either
an arbitrary YCbCr 4:2:0 or RGBX_, with the latter being recognized
by lock_ycbcr failin
On Monday, 2017-11-27 12:53:39 -0800, Ian Romanick wrote:
> On 11/27/2017 10:46 AM, Dylan Baker wrote:
> > Quoting Eric Engestrom (2017-11-27 09:46:57)
> >> On Saturday, 2017-11-25 18:45:14 +0100, Gert Wollny wrote:
> >>> Am Freitag, den 24.11.2017, 18:07 + schrieb Eric Engestrom:
> Signed
On Friday, 2017-11-24 19:20:12 +0100, Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Fri, Nov 24, 2017 at 7:07 PM, Eric Engestrom
> wrote:
> > Signed-off-by: Eric Engestrom
> > ---
> > src/amd/Android.addrlib.mk | 2 --
> > src/amd/Makefile.addrlib.am
Hash maps might use pointer keys (which people surely might want to
use to hash values) in which case a 0 value is perfectly acceptable.
It's only if the hash function needs to deference the pointer that we
want to be sure it's not NULL.
v2: Add assert in _mesa_fnv32_1a_accumulate_block (Ian)
Sig
Signed-off-by: Eric Engestrom
---
src/mapi/glapi/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mapi/glapi/meson.build b/src/mapi/glapi/meson.build
index 14ffa68ad0daa06a32ed..470431de33d81a26d367 100644
--- a/src/mapi/glapi/meson.build
+++ b/src/mapi/glapi/me
On 28 November 2017 at 10:45, Tapani Pälli wrote:
> Hi;
>
>
> On 11/27/2017 04:14 PM, Robert Foss wrote:
>>
>> From: Tomasz Figa
>>
>> There is no API available to properly query the IMPLEMENTATION_DEFINED
>> format. As a workaround we rely here on gralloc allocating either
>> an arbitrary YCbCr
Dylan/Jon already beat you to it ;-)
See patch "meson: fix generated source inclusion on macOS and Windows"
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 28 November 2017 at 02:56, Ian Romanick wrote:
> On 11/23/2017 05:32 AM, Emil Velikov wrote:
>> Hi Eric,
>>
>> On 22 November 2017 at 17:59, Eric Engestrom
>> wrote:
>>> A recent thread [1] made me check our local specs to see which ones were
>>> upstream. This series removes the ones that ar
Hi Clayton,
On 28 November 2017 at 03:41, Clayton Craft wrote:
> This resolves following test failures by partially
> reverting "mesa: shrink VERT_ATTRIB bitfields to 32 bits":
> KHR-GL46.enhanced_layouts.varying_array_locations
> KHR-GL46.enhanced_layouts.varying_locations
> KHR-GL46.enhanced_la
On Tue, Nov 28, 2017 at 8:49 PM, Emil Velikov wrote:
> On 28 November 2017 at 10:45, Tapani Pälli wrote:
>> Hi;
>>
>>
>> On 11/27/2017 04:14 PM, Robert Foss wrote:
>>>
>>> From: Tomasz Figa
>>>
>>> There is no API available to properly query the IMPLEMENTATION_DEFINED
>>> format. As a workaround
On Tue, Nov 28, 2017 at 7:12 PM, Eric Engestrom
wrote:
> On Monday, 2017-11-27 22:00:43 +0100, Robert Foss wrote:
>> Hey Rob,
>>
>> On Mon, 2017-11-27 at 13:42 -0600, Rob Herring wrote:
>> > On Mon, Nov 27, 2017 at 8:14 AM, Robert Foss > > om> wrote:
>> > > From: Tomasz Figa
>> > >
>> > > There i
On 28/11/17 11:36, Eric Engestrom wrote:
> On Monday, 2017-11-27 13:21:31 +0200, Tapani Pälli wrote:
>>
>> On 11/15/2017 03:22 PM, Eduardo Lima Mitev wrote:
>>> From: Alejandro Piñeiro
>>>
>>> Ideally this should be generated somehow. One option would be gather
>>> all the extension dependencies l
On Tuesday, 2017-11-28 11:51:32 +, Emil Velikov wrote:
> Dylan/Jon already beat you to it ;-)
> See patch "meson: fix generated source inclusion on macOS and Windows"
Indeed, thanks ^^
I saw that series though, but somehow forgot about it.
Reviewing it now.
>
> -Emil
On Tuesday, 2017-11-28 14:01:38 +0100, Alejandro Piñeiro wrote:
> On 28/11/17 11:36, Eric Engestrom wrote:
> > On Monday, 2017-11-27 13:21:31 +0200, Tapani Pälli wrote:
> >>
> >> On 11/15/2017 03:22 PM, Eduardo Lima Mitev wrote:
> >>> From: Alejandro Piñeiro
> >>>
> >>> Ideally this should be gene
On 28/11/17 14:13, Eric Engestrom wrote:
> On Tuesday, 2017-11-28 14:01:38 +0100, Alejandro Piñeiro wrote:
>> On 28/11/17 11:36, Eric Engestrom wrote:
>>> On Monday, 2017-11-27 13:21:31 +0200, Tapani Pälli wrote:
On 11/15/2017 03:22 PM, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro
Julien, this looks like a good candidate to nominate for inclusion in
the 17.2 stable queue.
What do you think?
On Tue, 2017-07-25 at 15:31 +0100, Julien Isorce wrote:
> The picture_is was assumed to be a frame number so in 0-31.
> But the vaapi client gstreamer-vaapi uses the surfaces handles
>
On Tuesday, 2017-11-28 21:59:52 +0900, Tomasz Figa wrote:
> On Tue, Nov 28, 2017 at 7:12 PM, Eric Engestrom
> wrote:
> > On Monday, 2017-11-27 22:00:43 +0100, Robert Foss wrote:
> >> Hey Rob,
> >>
> >> On Mon, 2017-11-27 at 13:42 -0600, Rob Herring wrote:
> >> > On Mon, Nov 27, 2017 at 8:14 AM, Ro
Forgot to include mesa-stable ...
On Tue, 2017-11-28 at 15:32 +0200, Andres Gomez wrote:
> Julien, this looks like a good candidate to nominate for inclusion in
> the 17.2 stable queue.
>
> What do you think?
>
> On Tue, 2017-07-25 at 15:31 +0100, Julien Isorce wrote:
> > The picture_is was assu
On Tue, 2017-11-28 at 11:58 +, Emil Velikov wrote:
> Hi Clayton,
>
> On 28 November 2017 at 03:41, Clayton Craft wrote:
> > This resolves following test failures by partially
> > reverting "mesa: shrink VERT_ATTRIB bitfields to 32 bits":
> > KHR-GL46.enhanced_layouts.varying_array_locations
>
From: Nicolai Hähnle
The flag is on the pipe_resource, not the r600_resource.
I don't see an obvious bug related to this, but it could potentially lead
to suboptimal placement of some resources.
Fixes: a41587433c4d ("gallium/radeon: add R600_RESOURCE_FLAG_UNMAPPABLE")
---
src/gallium/drivers/r
Denis, this looks like a good candidate to nominate for inclusion in
the 17.2 stable queue.
What do you think?
On Tue, 2017-09-12 at 23:38 +0300, Denis Pauk wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102552
>
> v2: Patch cleanup proposed by Nicolai Hähnle.
> * deleted ch
From: Nicolai Hähnle
Together with "radeonsi: fix the R600_RESOURCE_FLAG_UNMAPPABLE check",
this ensures that sparse buffers are placed in VRAM.
Noticed by an assertion that started triggering with commit d4fac1e1d7
("gallium/radeon: enable suballocations for VRAM with no CPU access")
Fixes KHR
Am Dienstag, den 28.11.2017, 08:45 +1100 schrieb Timothy Arceri:
>
>
> >
> > If I understand the comments in opt_array_splitting, arrays of
> > arrays are not properly handled there. Curretly, I don't see how I
> > can fix this, because I simply didn't look at any code there
> > before.
>
> The
Matt, this looks like a good candidate to nominate for inclusion in
the 17.2 stable queue.
What do you think?
On Thu, 2017-09-28 at 23:05 -0700, Matt Turner wrote:
> 64-bit operations on Atom parts have additional restrictions over their
> big-core counterparts (validated by later patches).
>
>
On Mon, Nov 27, 2017 at 07:05:54PM -0800, Jason Ekstrand wrote:
> ---
> src/intel/vulkan/anv_blorp.c | 38
> ++
> src/intel/vulkan/anv_private.h | 9 +
> src/intel/vulkan/genX_cmd_buffer.c | 11 ++-
> 3 files changed, 33 insertions(+)
Nicolai, this looks like a good candidate to nominate for inclusion in
all the stable queues.
What do you think?
On Tue, 2017-10-10 at 14:09 +0200, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> The intended rule has been clarified in GLSL 4.60, Section 8.13.2
> (Interpolation Functions):
>
On Tue, Nov 21, 2017 at 4:13 PM, Eric Anholt wrote:
> v2: Remove the callback, leave avoiding the recursion up to the caller
> (probably by rewriting the vtbl either in pctx or u_resource_vtbl)
hmm, that is still a bit ugly.. and looking at the equiv thing that
Ilia implemented in freedreno,
Nicolai, this looks like a good candidate to nominate for inclusion in
all the stable queues.
What do you think?
On Thu, 2017-11-09 at 20:00 +0100, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
> The docs are not very concise in what this really does, however both
> Alex Deucher and Ni
https://bugs.freedesktop.org/show_bug.cgi?id=103955
Bug ID: 103955
Summary: Using array in structure results in wrong GLSL
compilation output
Product: Mesa
Version: 17.3
Hardware: All
OS: Linux (All)
On Mon, Nov 27, 2017 at 07:05:50PM -0800, Jason Ekstrand wrote:
> This patch series is a major rework of the aux tracking and fast clear code
> in our Vulkan driver. It's broken up into three basic pieces:
>
> 1) Patches 1-13 rework the way layout transitions work and add some
> additional g
On Tue, 2017-11-28 at 16:05 +0200, Andres Gomez wrote:
> Nicolai, this looks like a good candidate to nominate for inclusion in
^^^
I meant Roland 😕
> all the stable queues.
>
> What do you think?
>
> On Thu, 2017-11-09 at 20:00 +0100, srol...@vmware.com wrote:
> > From: Roland Scheidegger
https://bugs.freedesktop.org/show_bug.cgi?id=103955
--- Comment #1 from Younghun Jang ---
(correction)
I made a wrong assumption about Chrome's SW renderer. Running Chrome with
`LIBGL_ALWAYS_SOFTWARE=1` does not make Chrome default to its own SW renderer.
This only happens with VBox GPU.
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=103955
--- Comment #2 from Ilia Mirkin ---
Created attachment 135757
--> https://bugs.freedesktop.org/attachment.cgi?id=135757&action=edit
shader_test that repros the issue
In the TGSI this comes out as
FRAG
PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
DC
On Tue, Nov 28, 2017 at 5:49 AM, Emil Velikov wrote:
> On 28 November 2017 at 10:45, Tapani Pälli wrote:
>> Hi;
>>
>>
>> On 11/27/2017 04:14 PM, Robert Foss wrote:
[...]
>>> + /* HACK: See droid_create_image_from_prime_fd() and b/32077885. */
>>> + { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,
https://bugs.freedesktop.org/show_bug.cgi?id=103955
--- Comment #3 from Ilia Mirkin ---
The GLSL IR seems questionable too...
: GLSL IR for linked fragment program 3:
(
(declare (location=2 shader_out ) vec4 gl_FragColor)
(declare (temporary ) vec4 gl_FragColor)
(declare (location=0 uniform ) Se
On Tue, Nov 28, 2017 at 11:27 PM, Rob Herring wrote:
> On Tue, Nov 28, 2017 at 5:49 AM, Emil Velikov
> wrote:
>> On 28 November 2017 at 10:45, Tapani Pälli wrote:
>>> Hi;
>>>
>>>
>>> On 11/27/2017 04:14 PM, Robert Foss wrote:
>
> [...]
>
+ /* HACK: See droid_create_image_from_prime_fd()
https://bugs.freedesktop.org/show_bug.cgi?id=103814
--- Comment #4 from Nicolai Hähnle ---
Thanks for the report. I cannot reproduce this on VI with latest Mesa and LLVM.
Could you please (1) try with latest Mesa and LLVM (e.g. Padoka PPA if you're o
on Ubuntu) and (2) provide the output of glxin
From: Nicolai Hähnle
---
src/gallium/drivers/radeon/r600_pipe_common.c | 431 ---
src/gallium/drivers/radeon/r600_pipe_common.h | 4 -
src/gallium/drivers/radeonsi/si_pipe.c | 432
src/gallium/drivers/radeonsi/si_pipe.h | 4 +
On 28 November 2017 at 13:44, Andres Gomez wrote:
> Denis, this looks like a good candidate to nominate for inclusion in
> the 17.2 stable queue.
>
> What do you think?
>
Patch seems safe, but it's a bit meh since it says "segfault" without
specifying any usecase.
IIRC the only example is a "This
On Tue, Nov 28, 2017 at 3:46 PM, Emil Velikov wrote:
> On 28 November 2017 at 13:44, Andres Gomez wrote:
>> Denis, this looks like a good candidate to nominate for inclusion in
>> the 17.2 stable queue.
>>
>> What do you think?
>>
> Patch seems safe, but it's a bit meh since it says "segfault" wi
Internal addrlib doesn't contain BRAHMA_BUILD, so removing that
definition is safe.
The assert change is also OK. We'll just discard any new addrlib code
that might replace it, because standard C assert is the only think we
need.
Marek
On Tue, Nov 28, 2017 at 12:03 PM, Eric Engestrom
wrote:
> O
On 28.11.2017 14:58, Andres Gomez wrote:
Nicolai, this looks like a good candidate to nominate for inclusion in
all the stable queues.
What do you think?
It's a rare enough use case, but the change is small and there seem to
have been no regressions, so sure, go ahead for both of them.
Than
This is:
Reviewed-by: Andres Gomez
Vadym, let me know if you need someone to push your change.
On Mon, 2017-11-27 at 12:15 +0200, vadim.shovkopl...@gmail.com wrote:
> From: Vadym Shovkoplias
>
> Fix incomplete check of input params in blorp_surf_convert_to_uncompressed()
> which can lead to N
On Tue, Nov 28, 2017 at 5:56 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Mon, Nov 27, 2017 at 07:05:54PM -0800, Jason Ekstrand wrote:
> > ---
> > src/intel/vulkan/anv_blorp.c | 38 ++
>
> > src/intel/vulkan/anv_private.h | 9
On Tue, Nov 28, 2017 at 2:29 AM, Eric Engestrom
wrote:
> On Monday, 2017-11-27 19:08:42 -0800, Jason Ekstrand wrote:
> > On Mon, Nov 27, 2017 at 7:00 PM, Ian Romanick
> wrote:
> >
> > > I am strongly in favor of this precedent. One thing that has annoyed
> me
> > > for years about Mesa's OpenGL
On Monday, 2017-11-27 13:58:27 +, Jon Turney wrote:
> This series lets me build a mesa for Cygwin configured with:
>
> -Ddri-drivers=swrast -Dgallium-drivers= -Dplatforms=x11,surfaceless
> -Dglx=dri -Dvulkan-drivers=
>
> I'm really not sure about (2/8), the autotools build does something t
DEBUG_FP & DEBUG_VP were removed in 8c41a14c5ef0b8d2b0f1.
Changing #if to #ifdef silences the warnings, but I think one of these
options would be better:
- the code has been disabled to 12 years, we could just remove it.
- if the point is to have it in debug builds, we could s/DEBUG_.P/DEBUG/
The
On 28.11.2017 09:34, Sahu, Satyajit wrote:
[snip]
--- a/src/gallium/targets/dri/dri.sym
+++ b/src/gallium/targets/dri/dri.sym
@@ -4,6 +4,11 @@
__driDriverGetExtensions*;
nouveau_drm_screen_create;
radeon_drm_winsys_create;
+ ac_compute_surface;
+ ac_que
On Tue, 2017-11-28 at 11:18 +, Lionel Landwerlin wrote:
> Hash maps might use pointer keys (which people surely might want to
> use to hash values) in which case a 0 value is perfectly acceptable.
> It's only if the hash function needs to deference the pointer that we
dereference -
On Mon, Nov 27, 2017 at 2:10 PM, Marek Olšák wrote:
> On Mon, Nov 27, 2017 at 1:02 PM, Nicolai Hähnle wrote:
>> On 24.11.2017 22:32, Marek Olšák wrote:
>>>
>>> From: Marek Olšák
>>>
>>> r600_resource is malloc'd.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103808
>>
>>
>> Coul
https://bugs.freedesktop.org/show_bug.cgi?id=103732
Bruce Cherniak changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/swr
--- Comment #7 fro
Am 28.11.2017 um 15:11 schrieb Andres Gomez:
> On Tue, 2017-11-28 at 16:05 +0200, Andres Gomez wrote:
>> Nicolai, this looks like a good candidate to nominate for inclusion in
> ^^^
> I meant Roland 😕
:-)
Yes I think that makes sense. Albeit
71e630753ebbee82e8f8709da5488296b2c070c8 (doing t
Looks alright to me too. And it's shorter :-).
Roland
Am 28.11.2017 um 11:17 schrieb Miklós Máté:
> Hi,
>
> I've already prepared a patch that documents this, I was going to post
> it with the v2 of this series. My version looks like this:
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main
https://bugs.freedesktop.org/show_bug.cgi?id=103732
Bruce Cherniak changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |bruce.chern...@intel.com
https://bugs.freedesktop.org/show_bug.cgi?id=103699
Fredrik Höglund changed:
What|Removed |Added
Attachment #135512|0 |1
is obsolete|
On Tue, Nov 28, 2017 at 8:42 AM, Tomasz Figa wrote:
> On Tue, Nov 28, 2017 at 11:27 PM, Rob Herring wrote:
>> On Tue, Nov 28, 2017 at 5:49 AM, Emil Velikov
>> wrote:
>>> On 28 November 2017 at 10:45, Tapani Pälli wrote:
Hi;
On 11/27/2017 04:14 PM, Robert Foss wrote:
>>
>> [
This patch causes a perf drop in sascha gears. I'm investigating.
On Mon, Nov 27, 2017 at 7:06 PM, Jason Ekstrand
wrote:
> ---
> src/intel/vulkan/genX_cmd_buffer.c | 187 +-
> ---
> 1 file changed, 65 insertions(+), 122 deletions(-)
>
> diff --git a/src/intel/vu
On Tue, Nov 28, 2017 at 10:07 AM, Jason Ekstrand
wrote:
> This patch causes a perf drop in sascha gears. I'm investigating.
>
Found it! Read below.
> On Mon, Nov 27, 2017 at 7:06 PM, Jason Ekstrand
> wrote:
>
>> ---
>> src/intel/vulkan/genX_cmd_buffer.c | 187 +-
Quoting Emil Velikov (2017-11-27 06:31:35)
> IIRC Windows mandates binaries with unresolved symbols.
> Other platforms allow such behaviour.
>
> I think we want to set b_lundef=true, to catch these issues as part of
> the build process.
> We already do so in the autotools, android and at least par
https://bugs.freedesktop.org/show_bug.cgi?id=100151
Bruce Cherniak changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |bruce.chern...@intel.com
On Mon, Nov 27, 2017 at 07:05:55PM -0800, Jason Ekstrand wrote:
> This got lost in all of the aspect vs. plane rebasing of YCBCR.
> ---
> src/intel/vulkan/anv_image.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
This patch is
Reviewed-by: Nanley Chery
> diff --git a/src/intel/vulk
Cc: Chad Versace
---
src/intel/isl/isl.h | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index e3acb0e..cf53b5a 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -1565,10 +1565,25 @@ isl_drm_modifi
Am Dienstag, den 28.11.2017, 10:53 + schrieb Eric Engestrom:
>
> > The parameters to a preprocessor macro are (basically) just
> > text. They are not evaluated until after the macro is
> > expanded. I'm 93.2% sure removing the guards around the assert()
> > should be fine in this case.
>
>
For the series:
Reviewed-by: Marek Olšák
Marek
On Tue, Nov 28, 2017 at 2:44 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Together with "radeonsi: fix the R600_RESOURCE_FLAG_UNMAPPABLE check",
> this ensures that sparse buffers are placed in VRAM.
>
> Noticed by an assertion that start
Can we use this instead?
https://cgit.freedesktop.org/~mareko/mesa/commit/?h=master&id=65f55ddb4b0140f0beb0868381be5edac64b5137
Marek
On Tue, Nov 28, 2017 at 3:45 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 431 --
On Mon, Nov 27, 2017 at 07:06:02PM -0800, Jason Ekstrand wrote:
> They are static functions so there's no real need to have the genX and
> it just makes the function names longer.
> ---
> src/intel/vulkan/genX_cmd_buffer.c | 34 +-
> 1 file changed, 17 insertions(+)
On 11/28/2017 07:49 AM, Eric Engestrom wrote:
> DEBUG_FP & DEBUG_VP were removed in 8c41a14c5ef0b8d2b0f1.
>
> Changing #if to #ifdef silences the warnings, but I think one of these
> options would be better:
> - the code has been disabled to 12 years, we could just remove it.
> - if the point is t
On 11/27/2017 03:20 AM, Timothy Arceri wrote:
> On 16/11/17 00:22, Eduardo Lima Mitev wrote:
>> ---
>> src/mesa/main/glspirv.c | 51
>> ++---
>> 1 file changed, 48 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main
On Tue, Nov 21, 2017 at 3:05 PM, Chad Versace
wrote:
> On Wed 08 Nov 2017, Jason Ekstrand wrote:
> > The old code made a new miptree that referenced the same BO as the
> > renderbuffer and just trusted in the memory aliasing to work. There are
> > only two ways in which the new miptree is liable
Hi,
This is a heads-up that I'm preparing a v2 of this series incorporating
all the feedback received so far.
I plan to submit it imminently (tomorrow?) and several patches have
diverged quite a bit; so please hold on for a few hours on any review
you might have planned.
Thanks!
Eduardo
On 11/
On 11/28/2017 08:04 AM, Andres Gomez wrote:
> On Tue, 2017-11-28 at 11:18 +, Lionel Landwerlin wrote:
>> Hash maps might use pointer keys (which people surely might want to
>> use to hash values) in which case a 0 value is perfectly acceptable.
>> It's only if the hash function needs to deferen
On 11/28/2017 03:55 AM, Emil Velikov wrote:
> On 28 November 2017 at 02:56, Ian Romanick wrote:
>> On 11/23/2017 05:32 AM, Emil Velikov wrote:
>>> Hi Eric,
>>>
>>> On 22 November 2017 at 17:59, Eric Engestrom
>>> wrote:
A recent thread [1] made me check our local specs to see which ones wer
Lionel Landwerlin writes:
> Hash maps might use pointer keys (which people surely might want to
> use to hash values) in which case a 0 value is perfectly acceptable.
> It's only if the hash function needs to deference the pointer that we
> want to be sure it's not NULL.
>
> v2: Add assert in _me
https://bugs.freedesktop.org/show_bug.cgi?id=103699
--- Comment #21 from Germano Massullo ---
Hi there my system has
- Mesa 17.2.4;
- KDE Plasma 5.10
on Fedora 26 and I think I am experiencing this problem. I opened a Firefox
bugreport before finding out about this Mesa bugreport
https://bugzill
Also... it looks like only a few patches in this series got reviewed.
Did the whole thing actually land?
On 11/28/2017 05:54 AM, Andres Gomez wrote:
> Matt, this looks like a good candidate to nominate for inclusion in
> the 17.2 stable queue.
>
> What do you think?
>
> On Thu, 2017-09-28 at 23:
https://bugs.freedesktop.org/show_bug.cgi?id=103732
--- Comment #8 from Bruce Cherniak ---
The root cause to this bug was fixed in a post-17.2 patch (b9aa0fa7) "swr:
Handle resource across context changes". It's in mesa master and the
forthcoming 17.3.
The test still fails occasionally, but doe
Based on my (weak) understanding things in this part of the code, I
think this is ok. There are a couple minor nits below. With those
addressed and unless Jason has (time to give) some objections, this patch is
Reviewed-by: Ian Romanick
On 11/28/2017 02:06 AM, Samuel Iglesias Gonsálvez wrote:
On 11/28/2017 02:01 AM, Iago Toral wrote:
>
> On Mon, 2017-11-27 at 18:37 +0100, Juan A. Suarez Romero wrote:
>> Commit 78942e ("mesa: shrink VERT_ATTRIB bitfields to 32 bits") uses
>> vs_prog_data->vs_inputs as if it were a 32-bit unsigned integer.
>>
>> But actually it is a 64-bit integer, and a
On Tue, Nov 14, 2017 at 10:39 PM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> We can write to the same output but in different components, like
> in this example:
>
> layout(location = 0, component = 0) out ivec2 dEQP_FragColor_0;
> layout(location = 0, component = 2) out ivec2 dEQP
https://bugs.freedesktop.org/show_bug.cgi?id=103332
--- Comment #3 from Bruce Cherniak ---
Hello Laurent,
Have you had any success a with testcase that illustrates the failure you are
seeing?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for t
1 - 100 of 310 matches
Mail list logo
