Re: [Mesa-dev] [PATCH v2 2/3] vulkan/wsi: Report the correct min/maxImageCount

Jason Ekstrand writes: > Hey, Neil! Hey Jason :) > Yeah... That's a bit unfortunate. The problem is that we have no way of > returning a different number of images depending on the mode. In theory, > we could start out at 2 and return SUBOPTIMAL and force the

Re: [Mesa-dev] [PATCH] nir/spirv: Allow loop breaks in a switch body.

Dave just told me on IRC about the SPIR-V opt discussion: https://github.com/KhronosGroup/SPIRV-Tools/issues/850 Assuming this actually solves the problem, Reviewed-by: Jason Ekstrand I would like to see CTS tests written for this and we had better die horribly without

Re: [Mesa-dev] [PATCH v2 2/3] vulkan/wsi: Report the correct min/maxImageCount

Hey, Neil! On October 1, 2017 3:12:46 PM Neil Roberts wrote: Jason Ekstrand writes: + /* For true mailbox mode, we need at least 4 images: +* 1) One to scan out from +* 2) One to have queued for scan-out +* 3) One to be currently

Re: [Mesa-dev] [PATCH] nir/spirv: Allow loop breaks in a switch body.

This looks correct but how did you come across it? Are there tests? On October 1, 2017 3:38:26 PM Bas Nieuwenhuizen wrote: Per the SPIR-V spec 2.11 Structured Control Flow: "The only blocks in a construct that can branch outside the construct are ... - a break

[Mesa-dev] [PATCH 3/3] st/va: add RGB support to vlVaPutSurface

--- src/gallium/state_trackers/va/surface.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/va/surface.c b/src/gallium/state_trackers/va/surface.c index 643cdcd54a..4c2f4b5452 100644 --- a/src/gallium/state_trackers/va/surface.c +++

[Mesa-dev] [PATCH 2/3] st/va: don't re-allocate interlaced buffer with pakced format

It caused corruption, when vlVaPutImage putting raw data to the fields v2: add RGB formats, since it got upload from here too. Cc: mesa-sta...@lists.freedesktop.org Cc: Andy Furniss --- src/gallium/state_trackers/va/image.c | 10 ++ 1 file changed, 6 insertions(+),

Re: [Mesa-dev] [PATCH 1/2] st/va: don't re-allocate interlaced buffer with pakced YUV format

Hi Andy, On 2017-10-01 07:13 PM, Andy Furniss wrote: Hmm, maybe this could be extended to allow bgrx which works with vdpau but not - mpv --vo=vaapi lines-576.png Thanks for testing. RGB raw data video output is totally separated case from YUYV for both vdpau and vaapi, it goes to

Re: [Mesa-dev] [PATCH 1/2] st/va: don't re-allocate interlaced buffer with pakced YUV format

Hmm, maybe this could be extended to allow bgrx which works with vdpau but not - mpv --vo=vaapi lines-576.png Andy Furniss wrote: Tested-by: Andy Furniss Leo Liu wrote: It caused corruption, when vlVaPutImage putting YUV to the fields Cc:

Re: [Mesa-dev] [PATCH 1/2] st/va: don't re-allocate interlaced buffer with pakced YUV format

Tested-by: Andy Furniss Leo Liu wrote: It caused corruption, when vlVaPutImage putting YUV to the fields Cc: mesa-sta...@lists.freedesktop.org Cc: Andy Furniss --- src/gallium/state_trackers/va/image.c | 8 1 file changed, 4

Re: [Mesa-dev] [PATCH 2/2] st/vdpau: don't re-allocate interlaced buffer with packed YUV format

Tested-by: Andy Furniss Leo Liu wrote: It caused corruption, when vlVdpVideoSurfacePutBitsYCbCr putting YUV to the fields Cc: mesa-sta...@lists.freedesktop.org Cc: Andy Furniss --- src/gallium/state_trackers/vdpau/surface.c | 2 ++ 1 file

[Mesa-dev] [PATCH] nir/spirv: Allow loop breaks in a switch body.

Per the SPIR-V spec 2.11 Structured Control Flow: "The only blocks in a construct that can branch outside the construct are ... - a break block for the innermost loop it is inside of. ..." With "Break block: A block containing a branch to the Merge Block of a loop header's merge instruction."

Re: [Mesa-dev] [PATCH v2 2/3] vulkan/wsi: Report the correct min/maxImageCount

Jason Ekstrand writes: > + /* For true mailbox mode, we need at least 4 images: > +* 1) One to scan out from > +* 2) One to have queued for scan-out > +* 3) One to be currently held by the Wayland compositor > +* 4) One to render to > +*/ >

[Mesa-dev] Fwd: errors for mesa master Android build 862

FYI, 2 Android build errors on i965 and r600 started in the last week. I've been traveling and haven't investigated. Rob -- Forwarded message -- From: Date: Sat, Sep 30, 2017 at 5:19 PM Subject: errors for mesa master Android build 862 To:

Re: [Mesa-dev] [PATCH 19/19] radv: remove unused radv_meta_state::btoi::render_pass handle

Patches 2-7, 10-19 are Reviewed-by: Bas Nieuwenhuizen On Fri, Sep 29, 2017 at 5:49 PM, Samuel Pitoiset wrote: > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_private.h | 1 - > 1 file changed, 1

Re: [Mesa-dev] [PATCH 08/19] radv: remove the resummarize decompress depth state

I'd like to keep this due to potential use for fixing the htile bugs. See e.g. https://bugs.freedesktop.org/show_bug.cgi?id=102488 On Fri, Sep 29, 2017 at 5:48 PM, Samuel Pitoiset wrote: > It's unused. > > Signed-off-by: Samuel Pitoiset >

Re: [Mesa-dev] [PATCH 09/19] radv: remove radv_layout_is_htile_compressed()

I'd like to keep this because they specify different concepts: has_htile is whether the htile metadata is valid in combination with the image data, i.e. we can enable htile reads if we want, and don't have to . is_htile_compressed is whether we cannot read the data without the htile metadata.

Re: [Mesa-dev] [PATCH 01/19] radv: skip the decompression color pass when CMASK/FMASK/DCC are disabled

On 1 Oct. 2017 22:03, "Bas Nieuwenhuizen" wrote: Why add this? It sounds like extra code for no reason? Also why add it after the meta saves? Dave. On Fri, Sep 29, 2017 at 5:48 PM, Samuel Pitoiset wrote: > This should be a no-op. > >

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2

On 28/09/17 04:41, Lukas Rusak wrote: > Hello all, > > I'm bumping this to layout some progress that has been made on our (Kodi) > side and hopefully we can create a road map for what needs to be done on > the amd side to get it working with our vaapi implementation. > > I have merged the

[Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

This is a new interface in libva2 to support wider use-cases of passing surfaces to external APIs. In particular, this allows export of NV12 and P010 surfaces. v2: Convert surfaces to progressive before exporting them (Christian). v3: Set destination rectangle to match source when converting

[Mesa-dev] [PATCH 1/2] st/dri: Add definitions to allow importing 16-bit surfaces

Necessary to support P010/P016 surfaces for video. Signed-off-by: Mark Thompson --- src/gallium/state_trackers/dri/dri2.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c index

Re: [Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

On 29/09/17 17:25, Leo Liu wrote: > On 09/29/2017 11:37 AM, Leo Liu wrote: >> On 09/29/2017 10:45 AM, Andy Furniss wrote: >>> Marek Olšák wrote: Can you test this? >>> >>> My mpv test case is fixed by >>> >>> radeonsi/uvd: fix planar formats broken since f70f6baaa3bb0f8b280ac2eaea69bb >> >>

Re: [Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

On 29/09/17 15:45, Andy Furniss wrote: > Marek Olšák wrote: >> Can you test this? > > My mpv test case is fixed by > > radeonsi/uvd: fix planar formats broken since f70f6baaa3bb0f8b280ac2eaea69bb Also good for my VAAPI case; dropped the revert from my series. Thanks, - Mark >> >> Thanks, >>

Re: [Mesa-dev] Mesa 17.2.2 release candidate

On Sun, 2017-10-01 at 10:10 +0200, Bas Nieuwenhuizen wrote: > > > > Rejected (3) > > > > > > Bas Nieuwenhuizen (1): > > radv: Check for GFX9 for 1D arrays in image_size intrinsic. > > Addresses earlier commits 61ad2f13 and 6dcc54b4 which > > did not land in branch

Re: [Mesa-dev] [PATCH] etnaviv: Set up GC3000 states, fix point sprite rendering

On Sun, Oct 01, 2017 at 01:46:05PM +0200, Christian Gmeiner wrote: > Okay.. hopefully we do not forget to remove them here when it gets > used during state emission like PE_ALPHA_COLOR_EXT0. But I > am fine with that change and will shut up. Yes, it should be removed then. Though if I understand

[Mesa-dev] [PATCH v2 2/2] etnaviv: Set up unknown GC3000 states

Set up new states that the blob started setting for GC3000 consistently. This makes sure that when another test or driver leaves the GPU in unpredictable state, these states are set up correctly for our rendering. Signed-off-by: Wladimir J. van der Laan ---

[Mesa-dev] [PATCH v2 1/2] etnaviv: Fix point sprite rendering on GC3000

Setting PA_VIEWPORT_UNK state correctly is necessary to make point sprite rendering on GC3000 work. Signed-off-by: Wladimir J. van der Laan --- src/gallium/drivers/etnaviv/etnaviv_context.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[Mesa-dev] [PATCH v2 0/2] etnaviv: Set up GC3000 states, fix point sprite rendering

Set up new states that the blob started setting for GC3000 consistently. This makes sure that when another test or driver leaves the GPU in unpredictable state, these states are set up correctly for our rendering. Also, setting PA_VIEWPORT_UNK00A84 to fui(8192.0) is necessary to make point

Re: [Mesa-dev] [PATCH v2] etnaviv: Do GC3000 resolve-in-place when possible

2017-09-30 10:11 GMT+02:00 Wladimir J. van der Laan : > If an RS blit is done with source exactly the same as destination, and > the hardware supports this, do an in-place resolve. This only fills in > tiles that have not been rendered to using information from the TS. > > This

Re: [Mesa-dev] [PATCH 2/2] etnaviv: Add support for DP2 instruction

2017-10-01 11:21 GMT+02:00 Wladimir J. van der Laan : > A two-component dot product instruction is supported with HALTI2, use it > on hardware that supports it. > > Signed-off-by: Wladimir J. van der Laan Reviewed-by: Christian Gmeiner

Re: [Mesa-dev] [PATCH 1/2] etnaviv: Support opcodes with bit 6 set in assembler

2017-10-01 11:21 GMT+02:00 Wladimir J. van der Laan : > Support opcodes with bit 6 set in assembler, and assert that only ops > 0x00..0x7f are used. > > Signed-off-by: Wladimir J. van der Laan Reviewed-by: Christian Gmeiner > ---

Re: [Mesa-dev] [PATCH 01/19] radv: skip the decompression color pass when CMASK/FMASK/DCC are disabled

Why add this? It sounds like extra code for no reason? On Fri, Sep 29, 2017 at 5:48 PM, Samuel Pitoiset wrote: > This should be a no-op. > > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_meta_fast_clear.c | 3 +++ > 1 file

[Mesa-dev] [Bug 102634] 0 Color write masks with multiple render targets redirects color outputs to wrong attachment

https://bugs.freedesktop.org/show_bug.cgi?id=102634 Bas Nieuwenhuizen changed: What|Removed |Added Status|NEW |RESOLVED

Re: [Mesa-dev] [PATCH] etnaviv: Set up GC3000 states, fix point sprite rendering

On Oct 1, 2017 13:38, "Lucas Stach" wrote: Am Sonntag, den 01.10.2017, 12:46 +0200 schrieb Christian Gmeiner: > 2017-09-26 12:29 GMT+02:00 Wladimir J. van der Laan : > > Set up new states that the blob started setting for GC3000 consistently. > > > >

Re: [Mesa-dev] [PATCH] etnaviv: Set up GC3000 states, fix point sprite rendering

2017-10-01 13:38 GMT+02:00 Lucas Stach : > Am Sonntag, den 01.10.2017, 12:46 +0200 schrieb Christian Gmeiner: >> 2017-09-26 12:29 GMT+02:00 Wladimir J. van der Laan : >> > Set up new states that the blob started setting for GC3000 consistently. >> > >> >

Re: [Mesa-dev] [PATCH] etnaviv: Set up GC3000 states, fix point sprite rendering

Am Sonntag, den 01.10.2017, 12:46 +0200 schrieb Christian Gmeiner: > 2017-09-26 12:29 GMT+02:00 Wladimir J. van der Laan : > > Set up new states that the blob started setting for GC3000 consistently. > > > > This makes sure that when another test or driver leaves the GPU in > >

Re: [Mesa-dev] [PATCH] etnaviv: Set up GC3000 states, fix point sprite rendering

2017-09-26 12:29 GMT+02:00 Wladimir J. van der Laan : > Set up new states that the blob started setting for GC3000 consistently. > > This makes sure that when another test or driver leaves the GPU in > unpredictable state, these states are set up correctly for our > rendering. >

Re: [Mesa-dev] [PATCH 2/4] gallium/vl: don't use the template keyword

Am 29.09.2017 um 23:27 schrieb Marek Olšák: From: Marek Olšák for C++ editors Reviewed-by: Christian König --- src/gallium/auxiliary/vl/vl_winsys_dri.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-)

[Mesa-dev] [PATCH 1/2] etnaviv: Support opcodes with bit 6 set in assembler

Support opcodes with bit 6 set in assembler, and assert that only ops 0x00..0x7f are used. Signed-off-by: Wladimir J. van der Laan --- src/gallium/drivers/etnaviv/etnaviv_asm.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH 2/2] etnaviv: Add support for DP2 instruction

A two-component dot product instruction is supported with HALTI2, use it on hardware that supports it. Signed-off-by: Wladimir J. van der Laan --- src/gallium/drivers/etnaviv/etnaviv_compiler.c | 3 ++- src/gallium/drivers/etnaviv/etnaviv_disasm.c | 1 +

[Mesa-dev] [PATCH 0/2] etnaviv: Support opcode bit 6 assembler, add DP2 instruction

Support opcodes with bit 6 set in assembler, then use that to add the DP2 instruction, supported with HALTI2. Wladimir J. van der Laan (2): etnaviv: Support opcodes with bit 6 set in assembler etnaviv: Add support for DP2 instruction src/gallium/drivers/etnaviv/etnaviv_asm.c | 5 -

Re: [Mesa-dev] Mesa 17.2.2 release candidate

> > Rejected (3) > > > Bas Nieuwenhuizen (1): > radv: Check for GFX9 for 1D arrays in image_size intrinsic. > Addresses earlier commits 61ad2f13 and 6dcc54b4 which did not > land in branch Hi, can we still get this in? This addresses a regression in 17.2.1 . I just

[Mesa-dev] [PATCH] radv: Check for GFX9 for 1D arrays in image_size intrinsic.

Only on GFX9 we implement them as 2D images. This fixes: dEQP-VK.image.image_size.1d_array.readonly_12x34 dEQP-VK.image.image_size.1d_array.readonly_1x1 dEQP-VK.image.image_size.1d_array.readonly_32x32 dEQP-VK.image.image_size.1d_array.readonly_7x1