[Mesa-dev] [PATCH v2 19/19] intel/fs: Rework KSP data to be SIMD width-based

--- src/intel/compiler/brw_compiler.h | 53 +-- src/intel/compiler/brw_fs.cpp | 35 +++ src/intel/compiler/brw_fs_visitor.cpp | 2 +- 3 files changed, 43 insertions(+), 47 deletions(-) diff --git a/src/intel/compiler/brw_compiler.h

[Mesa-dev] [PATCH v2 18/19] intel/compiler: Add and use helpers for working with KSP indices

The pixel shader dispatch table is kind-of a confusing mess. This adds some helpers for dealing with it and for easily extracting the correct data from wm_prog_data. --- src/intel/blorp/blorp_genX_exec.h | 65 src/intel/compiler/brw_compiler.h | 85

Re: [Mesa-dev] Wrap up of depth 30 patches for nouveau.

The prime case is interesting ... esp since it's all completely manufactured. NVIDIA can render to both rbg/bgr orderings, and I suspect other GPUs can too. However for scanout, only one is supported. I don't have any great suggestions for how to resolve this cleanly, but figured I'd point it out.

[Mesa-dev] [PATCH 4/5] egl/wayland: Allow client->server format conversion for PRIME offload.

Support PRIME render offload between a Wayland server gpu and a Wayland client gpu with different channel ordering for their color formats, e.g., between Intel drivers which currently only support ARGB2101010 and XRGB2101010 import/display and nouveau which only supports ABGR2101010 rendering and

[Mesa-dev] [PATCH 5/5] egl/wayland-drm: Only announce formats via wl_drm which the driver supports.

Check if a pixel format is supported by the Wayland servers gpu driver before exposing it to the client via wl_drm, so we avoid reporting formats to the client which the server gpu can't handle. Restrict this reporting to the new color depth 30 formats for now, as the ARGB/XRGB and RGB565

[Mesa-dev] [PATCH 3/5] egl/x11: Handle both depth 30 formats for eglCreateImage(). (v3)

We need to distinguish if the backing storage of a pixmap is XRGB2101010 or XBGR2101010, as different gpu hw supports different formats. NVidia hw prefers XBGR, whereas AMD and Intel are happy with XRGB. Use the red channel mask of the first depth 30 visual of the x-screen to distinguish which hw

[Mesa-dev] [PATCH 1/5] egl/wayland: Add 10bpc BGR configs

From: Daniel Stone Add support for XBGR2101010 and ABGR2101010. Signed-off-by: Daniel Stone Reviewed-by: Eric Engestrom Reviewed-by: Mario Kleiner Tested-by: Mario Kleiner

[Mesa-dev] Wrap up of depth 30 patches for nouveau.

Hi, this series contains all the remaining patches for depth 30 support on nouveau and possible future driver with xBGR2101010 ordering instead of the xRGB2101010 ordering already supported since Mesa 18.0. These are the ones i obsessively tested with success. First two patches are Daniel's,

[Mesa-dev] [PATCH 2/5] gbm: Add support for 10bpp BGR formats

From: Daniel Stone Add support for XBGR2101010 and ABGR2101010 formats. Signed-off-by: Daniel Stone Reviewed-by: Mario Kleiner Tested-by: Mario Kleiner Tested-by: Ilia Mirkin

[Mesa-dev] [PATCH] intel/eu: Set EXECUTE_1 when setting the rounding mode in cr0

Fixes: d6cd14f2131a5b "i965/fs: Define new shader opcode to..." --- src/intel/compiler/brw_eu_emit.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c index 6c9dced..4f51d51 100644 --- a/src/intel/compiler/brw_eu_emit.c +++

Re: [Mesa-dev] [PATCH 2/2] r600/compute: Mark several functions as static

On Fri, 2018-05-18 at 21:31 -0500, Aaron Watry wrote: > On Fri, May 18, 2018 at 1:15 PM, Jan Vesely wrote: > > On Thu, 2018-05-17 at 19:20 -0500, Aaron Watry wrote: > > > They're not used anywhere else, so keep them private > > > > > > Signed-off-by: Aaron Watry

Re: [Mesa-dev] [PATCH 2/2] r600/compute: Mark several functions as static

On Fri, May 18, 2018 at 1:15 PM, Jan Vesely wrote: > On Thu, 2018-05-17 at 19:20 -0500, Aaron Watry wrote: >> They're not used anywhere else, so keep them private >> >> Signed-off-by: Aaron Watry > > I'm not sure what the original purpose of the removed

[Mesa-dev] [Bug 106572] Simply linking against libOpenCL.so tries accessing the GPU

https://bugs.freedesktop.org/show_bug.cgi?id=106572 Bug ID: 106572 Summary: Simply linking against libOpenCL.so tries accessing the GPU Product: Mesa Version: git Hardware: Other OS: All Status:

Re: [Mesa-dev] [PATCH 07/19] intel/fs: Add explicit last_rt flag to fb writes orthogonal to eot.

Just an observation -- old code was based on eot || other cond. New code seems to set last_rt only when eot is set. Is there a last_rt setting missing? Or was the extra condition superfluous before? On Fri, May 18, 2018, 19:35 Jason Ekstrand wrote: > From: Francisco Jerez

[Mesa-dev] [ANNOUNCE] mesa 18.1.0

Mesa 18.1.0 is now available. Here is a short list of notable features compared to 18.0 - OpenGL 3.1 with ARB_compatibility on nv50, nvc0, r600, radeonsi, softpipe, llvmpipe, svga - GL_ARB_bindless_texture on nvc0/maxwell+ - GL_ARB_transform_feedback_overflow_query on nvc0 - GL_EXT_semaphore

[Mesa-dev] [PATCH 19/19] intel/fs: Rework KSP data to be SIMD width-based

--- src/intel/compiler/brw_compiler.h | 38 +++ src/intel/compiler/brw_fs.cpp | 35 src/intel/compiler/brw_fs_visitor.cpp | 2 +- 3 files changed, 34 insertions(+), 41 deletions(-) diff --git

[Mesa-dev] [PATCH 16/19] intel/fs: Remove program key argument from generator.

From: Francisco Jerez Reviewed-by: Jason Ekstrand --- src/intel/compiler/brw_fs.cpp | 4 ++-- src/intel/compiler/brw_fs.h| 2 -- src/intel/compiler/brw_fs_generator.cpp| 3 +-- src/intel/compiler/brw_shader.cpp

[Mesa-dev] [PATCH 17/19] i965: Re-arrange shader kernel setup in WM state

--- src/mesa/drivers/dri/i965/genX_state_upload.c | 94 --- 1 file changed, 57 insertions(+), 37 deletions(-) diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c b/src/mesa/drivers/dri/i965/genX_state_upload.c index 6178bfa..eef5828 100644 ---

[Mesa-dev] [PATCH 11/19] intel/fs: Pull FB write implied headers from src[0]

Now that we have the implied header in src[0] for tracking purposes, we may as well use it in the generator. This makes things a tiny bit more general. --- src/intel/compiler/brw_fs_generator.cpp | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git

[Mesa-dev] [PATCH 18/19] intel/compiler: Add and use helpers for working with KSP indices

The pixel shader dispatch table is kind-of a confusing mess. This adds some helpers for dealing with it and for easily extracting the correct data from wm_prog_data. --- src/intel/blorp/blorp_genX_exec.h | 47 ++- src/intel/compiler/brw_compiler.h | 85

[Mesa-dev] [PATCH 04/19] intel/fs: Rename a local variable so it doesn't shadow component()

From: Francisco Jerez v2 (Jason Ekstrand): - Break the refactor into its own patch Reviewed-by: Jason Ekstrand --- src/intel/compiler/brw_fs_nir.cpp | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[Mesa-dev] [PATCH 12/19] intel/eu: Return new instruction to caller from brw_fb_WRITE().

From: Francisco Jerez Reviewed-by: Jason Ekstrand --- src/intel/compiler/brw_eu.h | 20 ++-- src/intel/compiler/brw_eu_emit.c | 24 +--- 2 files changed, 23 insertions(+), 21 deletions(-) diff --git

[Mesa-dev] [PATCH 09/19] intel/fs: Fix Gen4-5 FB write AA data payload munging for non-EOT writes.

From: Francisco Jerez Reviewed-by: Jason Ekstrand --- src/intel/compiler/brw_fs_generator.cpp | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/src/intel/compiler/brw_fs_generator.cpp

[Mesa-dev] [PATCH 10/19] intel/fs: Properly track implied header regs read by FB writes

The FB write opcode on gen4-5 does implied copies from g0 and g1 to the message payload. With this commit, we start tracking that as part of the IR by having the FB write read from g0-1. --- src/intel/compiler/brw_fs.cpp | 17 - 1 file changed, 16 insertions(+), 1 deletion(-)

[Mesa-dev] [PATCH 15/19] intel/fs: Set up FB write message headers in the visitor

Doing instruction header setup in the generator is aweful for a number of reasons. For one, we can't schedule the header setup at all. For another, it means lots of implied writes which the instruction scheduler and other passes can't properly read about. The second isn't a huge problem for FB

[Mesa-dev] [PATCH 14/19] intel/fs: Fix implied_mrf_writes() for headerless FB writes.

From: Francisco Jerez Reviewed-by: Jason Ekstrand --- src/intel/compiler/brw_fs.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp index 069959e..3e9ccc4 100644 ---

[Mesa-dev] [PATCH 08/19] intel/fs: FS_OPCODE_REP_FB_WRITE has side effects

It doesn't matter since we don't ever run replicated write shaders through the optimizer but it's good to be complete. --- src/intel/compiler/brw_shader.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/intel/compiler/brw_shader.cpp b/src/intel/compiler/brw_shader.cpp index

[Mesa-dev] [PATCH 13/19] intel/fs: Fix fs_inst::flags_written() for Gen4-5 FB writes.

From: Francisco Jerez Reviewed-by: Jason Ekstrand --- src/intel/compiler/brw_fs.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp index 600d901..069959e 100644 ---

[Mesa-dev] [PATCH 07/19] intel/fs: Add explicit last_rt flag to fb writes orthogonal to eot.

From: Francisco Jerez Reviewed-by: Jason Ekstrand --- src/intel/compiler/brw_fs.cpp | 1 + src/intel/compiler/brw_fs_generator.cpp | 6 +- src/intel/compiler/brw_fs_visitor.cpp | 2 ++ src/intel/compiler/brw_ir_fs.h | 1 + 4

[Mesa-dev] [PATCH 06/19] intel/fs: Replace the CINTERP opcode with a simple MOV

From: Francisco Jerez The only reason it was it's own opcode was so that we could detect it and adjust the source register based on the payload setup. Now that we're using the ATTR file for FS inputs, there's no point in having a magic opcode for this. v2 (Jason

[Mesa-dev] [PATCH 05/19] intel/fs: Use the ATTR file for FS inputs

From: Francisco Jerez This replaces the special magic opcodes which implicitly read inputs with explicit use of the ATTR file. v2 (Jason Ekstrand): - Break into multiple patches - Change the units of the FS ATTR to be in logical scalars Reviewed-by: Jason Ekstrand

[Mesa-dev] [PATCH 00/19] intel: Pre-work for enabling SIMD32 fragment shaders

For a while now, Curro has had a branch floating around to enable SIMD32 fragment shaders. I'm trying to revive it and get things in shape for possibly merging. This series contains a bunch of refactor patches which don't really have anything to do with SIMD32 other than that they make it

[Mesa-dev] [PATCH 03/19] intel/eu: Remove brw_codegen::compressed_stack.

From: Francisco Jerez Reviewed-by: Jason Ekstrand --- src/intel/compiler/brw_eu.h | 1 - 1 file changed, 1 deletion(-) diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h index 120a74f..2655cdb 100644 ---

[Mesa-dev] [PATCH 01/19] intel/fs: Assert that the gen4-6 plane restrictions are followed

The fall-back does not work correctly in SIMD16 mode and the register allocator should ensure that we never hit this case anyway. --- src/intel/compiler/brw_fs_generator.cpp | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/intel/compiler/brw_fs_generator.cpp

[Mesa-dev] [PATCH 02/19] intel/fs: Use groups for SIMD16 LINTERP on gen11+

This is better than compression control because it naturally extends to SIMD32. --- src/intel/compiler/brw_fs_generator.cpp | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/intel/compiler/brw_fs_generator.cpp b/src/intel/compiler/brw_fs_generator.cpp index

[Mesa-dev] [PATCH] ac/surface: Only align linear power of two fmt textures.

We're not sharing 32_32_32 formats between different GPUs, so we do not have to align for vega on pre-vega cards. Fixes: e361970ed73 "radv: Add support for IMG_DATA_FORMAT_32_32_32." --- src/amd/common/ac_surface.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Mesa-dev] [Bug 106570] support VK_direct_mode_display for vulkan?

https://bugs.freedesktop.org/show_bug.cgi?id=106570 Jason Ekstrand changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop.

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

The extension requires GL 3.2 (actually just geometry shaders), but we don't have GS in the compatibility profile yet. Marek On Fri, May 18, 2018 at 3:06 AM, Timothy Arceri wrote: > With the previous commit everything we need should be there. > --- >

[Mesa-dev] [Bug 106570] support VK_direct_mode_display for vulkan?

https://bugs.freedesktop.org/show_bug.cgi?id=106570 d3c...@gmail.com changed: What|Removed |Added CC||d3c...@gmail.com -- You are

[Mesa-dev] [Bug 106570] support VK_direct_mode_display for vulkan?

https://bugs.freedesktop.org/show_bug.cgi?id=106570 Bug ID: 106570 Summary: support VK_direct_mode_display for vulkan? Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [Mesa-dev] [PATCH v2] nir: Implement optional b2f->iand lowering

Am Mi., 2. Mai 2018 um 09:50 Uhr schrieb Alyssa Rosenzweig < aly...@rosenzweig.io>: > This pass is required by the Midgard compiler; our instruction set uses > NIR-style booleans (~0 for true) but lacks a dedicated b2f instruction. > Normally, this lowering pass would be implemented in a

Re: [Mesa-dev] threading in OSMesa and gallium swr driver

On May 16, 2018, at 9:25 AM, Alexandre > wrote: Thank you for your answer. I understand I can control the number of threads and prevent them to be assigned to actual hardware threads. Preventing oversubscription

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

On Fri, May 18, 2018 at 2:27 PM, Benedikt Schemmer wrote: > > > Am 18.05.2018 um 20:05 schrieb Ilia Mirkin: >> On Fri, May 18, 2018 at 1:54 PM, Benedikt Schemmer wrote: >>> so the gll is ok? >>> >>> my idea with the glc is that this particular extension would no

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

Am 18.05.2018 um 20:05 schrieb Ilia Mirkin: > On Fri, May 18, 2018 at 1:54 PM, Benedikt Schemmer wrote: >> so the gll is ok? >> >> my idea with the glc is that this particular extension would no longer be >> advertised as soon as the app >> request a context where the

Re: [Mesa-dev] [PATCH 2/2] r600/compute: Mark several functions as static

On Thu, 2018-05-17 at 19:20 -0500, Aaron Watry wrote: > They're not used anywhere else, so keep them private > > Signed-off-by: Aaron Watry I'm not sure what the original purpose of the removed functions was. If you recall please add it to the commit message. Either way:

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

On Fri, May 18, 2018 at 1:54 PM, Benedikt Schemmer wrote: > so the gll is ok? > > my idea with the glc is that this particular extension would no longer be > advertised as soon as the app > request a context where the functionality is already part of it (ie OpenGL >= > 4.0) Why

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

so the gll is ok? my idea with the glc is that this particular extension would no longer be advertised as soon as the app request a context where the functionality is already part of it (ie OpenGL >= 4.0) Do you think a minimum GLSL version could be added to this table (maybe replacing the

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

On Fri, May 18, 2018 at 1:27 PM, Benedikt Schemmer wrote: > Am I on the right track to assume that Timothy's patch should read > > +EXT(ARB_gpu_shader5 , ARB_gpu_shader5 > , 32, 40, x , x , 2010) > > to give GL_ARB_gpu_shader5 a

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

Am I on the right track to assume that Timothy's patch should read +EXT(ARB_gpu_shader5 , ARB_gpu_shader5 , 32, 40, x , x , 2010) to give GL_ARB_gpu_shader5 a minimum required legacy OpenGL version of 3.2 and core 4.0 as per spec? I wanted to

Re: [Mesa-dev] [PATCH 1/1] travis: Adapt to radeonsi dropping support for LLVM 4

Reviewed-by: Marek Olšák Marek On Thu, May 17, 2018 at 10:45 PM, Jan Vesely wrote: > meson Vulkan, Clover, and autotools Vulkan need to be switched to llvm 5 > > Fixes: f9eb1ef870eba9fdacf9a8cbd815ec3bff81db05 > Signed-off-by: Jan Vesely

[Mesa-dev] [PATCH 6/7] radv: add set_loc_shader_ptr() helper

This helper will hep for switching to 32-bit GPU pointers. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_nir_to_llvm.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/src/amd/vulkan/radv_nir_to_llvm.c

[Mesa-dev] [PATCH 4/7] radv: allocate the upload BO in the 32-bit addr space

Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_cmd_buffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c index a8359ac092..3636b2c8d9 100644 ---

[Mesa-dev] [PATCH 2/7] radv/winsys: allow to allocate BOs in the 32-bit addr space

This introduces a new flag called RADEON_FLAG_32BIT. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_radeon_winsys.h | 1 + src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH 7/7] radv: add support for 32-bit pointers in user data SGPRs

We still use 64-bit GPU pointers for all ring buffers because llvm.amdgcn.implicit.buffer.ptr doesn't seem to support 32-bit GPU pointers for now. This can be improved later anyways. Vega10: Totals from affected shaders: SGPRS: 1008722 -> 1026710 (1.78 %) VGPRS: 706580 -> 707136 (0.08 %) Spilled

[Mesa-dev] [PATCH 5/7] radv: allocate descriptor BOs in the 32-bit addr space

Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_descriptor_set.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_descriptor_set.c b/src/amd/vulkan/radv_descriptor_set.c index 9d783b8b6d..27dd5b08e2 100644 ---

[Mesa-dev] [PATCH 3/7] radv: set amdgpu-32bit-address-high-bits LLVM attribute

Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_nir_to_llvm.c | 6 ++ src/amd/vulkan/radv_shader.c | 1 + src/amd/vulkan/radv_shader.h | 1 + 3 files changed, 8 insertions(+) diff --git a/src/amd/vulkan/radv_nir_to_llvm.c

[Mesa-dev] [PATCH 0/7] radv: implement 32-bit GPU pointers for user SGPRs

Hi list, This series implements support for 32-bit GPU pointers which reduces the number of user SGPRs that are needed for binding descriptors. There is no CTS regressions and all games seem to get a minor performance boost (tested on Polaris/Vega). If you want to test or run some benchmarks

[Mesa-dev] [PATCH 1/7] radv/winsys: request high address

This is needed for 32-bit GPU pointers. Ported from RadeonSI. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git

Re: [Mesa-dev] [virglrenderer-devel] [PATCH] virgl: set texture buffer offset alignment to disable ARB_texture_buffer_range.

Reviewed-by: Gurchetan Singh On Fri, May 18, 2018 at 6:01 AM Elie Tournier wrote: > Wrong ML. I add > > On Fri, May 18, 2018 at 10:46:29AM +1000, Dave Airlie wrote: > > From: Dave Airlie

[Mesa-dev] [PATCH mesa 1/2] dri: fix error value returned by driGLFormatToImageFormat()

0 is not a valid value for the __DRI_IMAGE_FORMAT_* enum. It is, however, the value of MESA_FORMAT_NONE, which two of the callers (i915 & i965) checked for. The other callers (that check for errors, ie. st/dri) already check for __DRI_IMAGE_FORMAT_NONE. Signed-off-by: Eric Engestrom

[Mesa-dev] [PATCH mesa 2/2] dri: replace two-way switch case with a table lookup

Signed-off-by: Eric Engestrom --- src/mesa/drivers/dri/common/dri_util.c | 142 + 1 file changed, 76 insertions(+), 66 deletions(-) diff --git a/src/mesa/drivers/dri/common/dri_util.c b/src/mesa/drivers/dri/common/dri_util.c index

[Mesa-dev] [PATCH mesa] egl/x11: deduplicate depth-to-format logic

Suggested-by: Emil Velikov Signed-off-by: Eric Engestrom --- src/egl/drivers/dri2/platform_x11.c | 35 ++-- src/egl/drivers/dri2/platform_x11_dri3.c | 21 ++ src/egl/drivers/dri2/platform_x11_dri3.h | 3 ++

Re: [Mesa-dev] [PATCH] draw: get rid of special logic to not emit null tris

Thanks for testing, but radeonsi never uses draw - for radeon gallium drivers, only r300 does, and then only for the IGPs without vertex shaders. Roland Am 18.05.2018 um 05:48 schrieb Dieter Nützel: > Tested-by: Dieter Nützel > > on RX580 > > with UH, UV, glmark2,

Re: [Mesa-dev] [PATCH v2 03/14] etnaviv: rs: add support for multi layer formats

Am Fr., 4. Mai 2018 um 09:56 Uhr schrieb Lucas Stach : > Am Dienstag, den 01.05.2018, 16:48 +0200 schrieb Christian Gmeiner: > > The binary blob driver supports 'multi layer' formats. For > > instance: gcvSURF_A16B16G16R16F_2_A8R8G8B8 > > < format

Re: [Mesa-dev] [ANNOUNCE] mesa 18.0.4

2018-05-17 20:48 GMT+02:00 Juan A. Suarez Romero : > Mesa 18.0.4 is now available. > > In this release we have: > > r600 driver gets a fix for constant buffer boounds, which fixes rendering bugs > in Trine and Witcher 1. > > Several fixes for RADV driver: fixes around alpha

[Mesa-dev] [PATCH] i965: Fix output register sizes when variable ranges are interleaved

In 6f5abf31466aed this code was fixed to calculate the maximum size of an attribute in a seperate pass and then allocate the registers to that size. However this wasn’t taking into account ranges that overlap but don’t have the same starting location. For example: layout(location = 0, component =

Re: [Mesa-dev] [virglrenderer-devel] [PATCH] virgl: set texture buffer offset alignment to disable ARB_texture_buffer_range.

Wrong ML. I add On Fri, May 18, 2018 at 10:46:29AM +1000, Dave Airlie wrote: > From: Dave Airlie > > The host side hasn't got support for this feature yet, so don't enable it > unless we get the caps from the host. > > This makes the texture

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

On 18/05/18 22:20, Benedikt Schemmer wrote: Indeed it does, I've written a little test program where I can request specific OpenGL versions. I think that used to work, now if I request anything <= 3.1 I get 3.1 if request >= 3.2 I get 4.5. GL_ARB_gpu_shader5 is available in all of them. If I

Re: [Mesa-dev] [PATCH v2] mesa: handle a bunch of formats in IMPLEMENTATION_COLOR_READ_*

I have run this patch on my Intel host running various CTS in a virgl guest. Not sure if this constitutes as a Tested-by or a Acked-by, but at least it is a datapoint. Cheers, Jakob. On Fri, May 18, 2018 at 11:04 AM, Tomeu Vizoso wrote: > Virgl could save a lot of

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

On Fri, May 18, 2018 at 8:20 AM, Benedikt Schemmer wrote: > Indeed it does, I've written a little test program where I can request > specific OpenGL versions. > I think that used to work, now if I request anything <= 3.1 I get 3.1 if > request >= 3.2 I get 4.5. >

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

Indeed it does, I've written a little test program where I can request specific OpenGL versions. I think that used to work, now if I request anything <= 3.1 I get 3.1 if request >= 3.2 I get 4.5. GL_ARB_gpu_shader5 is available in all of them. If I force the GL version the version string

[Mesa-dev] [Bug 106511] radv: MSAA broken on SI (assertion failure in vkCreateImage)

https://bugs.freedesktop.org/show_bug.cgi?id=106511 --- Comment #1 from Turo Lamminen --- More info: 2x and 4x crash but 8x works. When the assertion fails, index and m_noOfEntries are both 32. -- You are receiving this mail because: You are the assignee for the

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

The check is against what the driver max is, not what the application requested. Using overrides messes up this logic, it seems. On Fri, May 18, 2018, 06:14 Benedikt Schemmer wrote: > Yes its backwards and it seems it doesn't work anymore ;) > Seems the loophole I was using got

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

Yes its backwards and it seems it doesn't work anymore ;) Seems the loophole I was using got removed. Problem remains that applications that could use an legacy extension are not aware of it and will simply/usually not request it: MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

Hi Benedikt, I think you have this backwards. compute_version() computes the version of OpenGL supported by the driver by checking what extensions it advertises. See version 2 of my patch to see where the extensions are enabled. I don't think this is something that can be automated, it

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

A list of extension requirements and interactions extracted from the GL_* files on Khronos so this is messy but relatively complete I've started to introduce key phrases like "This extension requires" so that this could become machine readable in the future. --- ./WGL_ARB_make_current_read.txt

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

Hi Timothy, I was looking into something similar myself. Great to see someone working on getting legacy extensions available to the applications that can actually use them! Another thing I noticed is that extensions aren't advertised at the correct feature level. The code below works and does a

[Mesa-dev] [PATCH v2] mesa: handle a bunch of formats in IMPLEMENTATION_COLOR_READ_*

Virgl could save a lot of work converting buffers in the host side between formats if Mesa supported a bunch of other formats when reading pixels. This commit adds cases to handle specific formats so that the values reported by the two calls match more closely the underlying native formats. In

[Mesa-dev] [PATCH v2 2/2] mesa: enable ARB_gpu_shader5 in compat

With the previous commit everything we need should be there. --- src/mesa/drivers/dri/i965/intel_extensions.c | 3 ++- src/mesa/main/extensions_table.h | 2 +- src/mesa/state_tracker/st_extensions.c | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git

Re: [Mesa-dev] [PATCH 1/3] mesa/main/shaderapi: Use generate_sha1() unconditionally

> Agreed, using ENABLE_SHADER_CACHE to guard some OS specifics is dirty, it > should be only guarding shader cache itself. I found this online, but I'm not sure if it can be used as part of mesa license etc. It looks quite reasonable (except for the include of sys/file.h) which isnt needed

Re: [Mesa-dev] [PATCH] radv: pass radv_nir_compiler_options directly to create_llvm_function()

Reviewed-by: Timothy Arceri On 18/05/18 18:43, Samuel Pitoiset wrote: Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_nir_to_llvm.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

[Mesa-dev] [PATCH] radv: pass radv_nir_compiler_options directly to create_llvm_function()

Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_nir_to_llvm.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/amd/vulkan/radv_nir_to_llvm.c b/src/amd/vulkan/radv_nir_to_llvm.c index 1384bf0bdba..9b9619b877e 100644 ---

Re: [Mesa-dev] [PATCH] radeonsi: skip ES output stores for undefined output components

Reviewed-by: Samuel Pitoiset On 05/18/2018 12:14 AM, Marek Olšák wrote: From: Marek Olšák --- src/gallium/drivers/radeonsi/si_shader.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/drivers/radeonsi/si_shader.c

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

Actually we need some GLSL Compat version checks before doing this. I'll send a patch 1.5 to do that. On 18/05/18 17:06, Timothy Arceri wrote: With the previous commit everything we need should be there. --- src/mesa/main/extensions_table.h | 2 +- 1 file changed, 1 insertion(+), 1

[Mesa-dev] [PATCH 1/2] mesa: stop hiding query parameters from OpenGL compat

Just let the extension detection do its job as we will be adding compat profile support in future, also we want these to work with compat profile version overrides. --- src/mesa/main/get_hash_params.py | 21 +++-- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git

[Mesa-dev] [PATCH 2/2] mesa: enable ARB_gpu_shader5 in compat

With the previous commit everything we need should be there. --- src/mesa/main/extensions_table.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h index 945b462122c..86ce6ec2318 100644 ---

Re: [Mesa-dev] [PATCH] vbo: remove MaxVertexAttribStride assert check.

Hi Dave, On Friday, 18 May 2018 06:57:19 CEST Dave Airlie wrote: > > May be I should take care of all of these type of asserts, also the ones > > with MaxVertexAttribRelativeOffset and care for not checking them > > when the extension version is unavailable or checking against the OpenGL > > spec

Re: [Mesa-dev] [PATCH 2/4] i965/miptree: Simplify the switch in supports_ccs

Reviewed-by: Tapani Pälli On 05/17/2018 12:00 AM, Nanley Chery wrote: --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c

Re: [Mesa-dev] [PATCH 0/4] intel: Make get_ccs_surf succeed in alloc_aux

On Wed, May 16, 2018 at 02:00:28PM -0700, Nanley Chery wrote: > Topi noticed that in intel_miptree_alloc_aux, we allowed CCS surface > retrieval to fail, but asserted that HiZ and MCS surface retrieval would > succeed. This series gets rid of that inconsistency and modifies some > related