[Mesa-dev] [Bug 107022] [RADV] The Witcher 3: Trembling of trees

https://bugs.freedesktop.org/show_bug.cgi?id=107022 soredake changed: What|Removed |Added CC||fds...@krutt.org -- You are receiving this

[Mesa-dev] Testing drm_hwcomposer in RPi

Hi. I would like to try out drm_hwcomposer on a RPi 3. Can anyone point me to a howto or something that tells me how? FYI, this is part of a side project to port drm_hwcomposer to BeagleBones and other things based on TI SoCs Thanks, Chris Simmonds ___

[Mesa-dev] [Bug 106958] Mass Effect Andromeda renders correctly on RX480 POLARIS but BAD ON RX VEGA 64 on wine 3.10 stagingf with DXVK

https://bugs.freedesktop.org/show_bug.cgi?id=106958 --- Comment #8 from Samuel Pitoiset --- Don't you see the renderdoc overlay? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev

Re: [Mesa-dev] [PATCH v3] i965/gen6/gs: Handle case where a GS doesn't allocate VUE

Thanks for testing Mark. Andrii, I'll add my Reviewed-by and and push the patch to master later today (I'll also queue it for the next stable release). Thanks for fixing this! Iago On Fri, 2018-06-22 at 13:18 -0700, Mark Janes wrote: > Tested-by: Mark Janes > > Iago Toral writes: > > > Than

[Mesa-dev] [PATCH] travis: use https for all the links

From: Emil Velikov Signed-off-by: Emil Velikov --- .travis.yml | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/.travis.yml b/.travis.yml index 012cc9139e0..903bd2dc8fc 100644 --- a/.travis.yml +++ b/.travis.yml @@ -9,9 +9,9 @@ cache: env: global: -- XO

[Mesa-dev] [PATCH 4/5] mesa: add compat profile support for ARB_multi_draw_indirect

--- src/mesa/main/extensions_table.h | 2 +- src/mesa/vbo/vbo_exec_array.c| 75 +++- 2 files changed, 74 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h index cba1ef6ba7c..1a4014c646b 100644 --- a/src/

[Mesa-dev] Radeonsi OpenGL 4.0 compat profile

This series is intended to be applied on top of my previous compat series [1]. Note I'm going to drop the last two patches from that series, patch 10 was sent by mistake and I've submitted a spec bug in regards to patch 11. I originally planned not to send this series until ARB_vertex_attrib_6

[Mesa-dev] [PATCH 1/5] mesa: generate GL_INVALID_OPERATION using draw indirect in dlist

The spec doesn't explicitly say to generate an error but since DrawArraysInstanced* and DrawElementsInstanced* do, it makes sense to do it for these functions also. --- src/mesa/main/dlist.c | 47 +++ 1 file changed, 47 insertions(+) diff --git a/src/mesa/m

[Mesa-dev] [PATCH 2/5] mesa: add ARB_draw_indirect support to compat profile

--- src/mesa/main/bufferobj.c| 3 +- src/mesa/main/extensions_table.h | 2 +- src/mesa/vbo/vbo_exec_array.c| 66 +++- 3 files changed, 67 insertions(+), 4 deletions(-) diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c index 67f9cd0a902..1

[Mesa-dev] [PATCH 5/5] radeonsi: enable OpenGL 4.0 compat profile

--- src/gallium/drivers/radeonsi/si_get.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeonsi/si_get.c b/src/gallium/drivers/radeonsi/si_get.c index 0e8617d0fee..a99626416e7 100644 --- a/src/gallium/drivers/radeonsi/si_get.c +++ b/src/gallium/drivers/r

[Mesa-dev] [PATCH 3/5] mesa: make valid_draw_indirect_multi() accessible externally

We will use this to add compat support to ARB_multi_draw_indirect in the following patch. --- src/mesa/main/draw_validate.c | 24 src/mesa/main/draw_validate.h | 3 +++ 2 files changed, 15 insertions(+), 12 deletions(-) diff --git a/src/mesa/main/draw_validate.c b/src/me

Re: [Mesa-dev] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

Please note I've fixed up make check where is was broken when enabling some of these extensions. You can see all of the latests compat patches here: https://gitlab.freedesktop.org/tarceri/mesa/commits/ARB_gpu_shader_fp64 On 22/06/18 18:47, Timothy Arceri wrote: I've send all of these patches

[Mesa-dev] [PATCH] radv: fix HTILE metadata initialization in presence of subpass clears

If the driver ends up by performing a slow depthstencil clear, the HTILE metadata won't be initialized correctly. This fixes random VM faults on Polaris while running CTS with Bas's runner. This doesn't seem to regress performance. CC: Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_cmd

[Mesa-dev] [RESEND PATCH v5 1/3] gallium/util: Fix build error due to cast to different size

Signed-off-by: Robert Foss Reviewed-by: Tomasz Figa Reviewed-by: Marek Olšák --- Changes since v4: - Added r-b from Marek Changes since v3: - Added r-b from Tomasz src/gallium/auxiliary/util/u_debug_stack_android.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/

[Mesa-dev] [RESEND PATCH v5 0/3] egl/android: Add DRM node probing and filtering

[RESEND] due to the previous version sent to the ML mistakenly being v4 again. Please excuse the spam. This series replaces the dependency on GRALLOC_MODULE_PERFORM_GET_DRM_FD with DRM node probing and disables the support for drm_gralloc. The series has been tested on Qemu+AOSP, where a virtio g

[Mesa-dev] [RESEND PATCH v5 2/3] egl/android: #ifdef out flink name support

From: Rob Herring Maintaining both flink names and prime fd support which are provided by 2 different gralloc implementations is problematic because we have a dependency on a specific gralloc implementation header. This mostly disables the dependency on the gralloc implementation and headers. Th

[Mesa-dev] [RESEND PATCH v5 3/3] egl/android: Add DRM node probing and filtering

This patch both adds support for probing & filtering DRM nodes and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD gralloc call. Currently the filtering is based just on the driver name, and the desired name is supplied using the "drm.gpu.vendor_name" Android property. Signed-off-b

Re: [Mesa-dev] [PATCH] radv: fix HTILE metadata initialization in presence of subpass clears

Reviewed-by: Bas Nieuwenhuizen Still not sure why that would cause VM faults though. On Mon, Jun 25, 2018 at 1:34 PM, Samuel Pitoiset wrote: > If the driver ends up by performing a slow depthstencil clear, > the HTILE metadata won't be initialized correctly. > > This fixes random VM faults on P

Re: [Mesa-dev] [PATCH] radv: fix HTILE metadata initialization in presence of subpass clears

On 06/25/2018 01:51 PM, Bas Nieuwenhuizen wrote: Reviewed-by: Bas Nieuwenhuizen Still not sure why that would cause VM faults though. Me neither, especially because the VM faults only happen when running CTS with multithreads... On Mon, Jun 25, 2018 at 1:34 PM, Samuel Pitoiset wrote:

[Mesa-dev] [PATCH] nir: fixup intrinsic comment

Now the deref is the first src. Signed-off-by: Rob Clark --- src/compiler/nir/nir_intrinsics.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler/nir/nir_intrinsics.py b/src/compiler/nir/nir_intrinsics.py index e38d94b2d8a..4ec2aab574b 100644 --- a/src/compiler/ni

Re: [Mesa-dev] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

I'll test these tonight, Dying Light in particular required an override - hopefully that won't be necessary any more On Mon, 25 Jun 2018 at 12:26 Timothy Arceri wrote: > Please note I've fixed up make check where is was broken when enabling > some of these extensions. You can see all of the late

Re: [Mesa-dev] [PATCH mesa 2/4] vulkan: add VK_EXT_display_control [v8]

Hello Keith, I am not able to build Mesa after this patch: wsi/wsi_common_display.c:991:4: error: unknown field ‘sequence_handler’ specified in initializer     .sequence_handler = wsi_display_sequence_handler,     ^ wsi/wsi_common_display.c:991:24: warning: initialization from incompatible po

[Mesa-dev] [PATCH] radv: enable VK_EXT_shader_stencil_export

The driver already supports exporting the stencil value. The following CTS test now pass: dEQP-VK.pipeline.shader_stencil_export.op_replace Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_extensions.py | 1 + src/amd/vulkan/radv_shader.c | 1 + 2 files changed, 2 insertions(+) diff

Re: [Mesa-dev] [PATCH] nir: fixup intrinsic comment

Reviewed-by: Samuel Iglesias Gonsálvez On 25/06/18 14:17, Rob Clark wrote: > Now the deref is the first src. > > Signed-off-by: Rob Clark > --- > src/compiler/nir/nir_intrinsics.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/compiler/nir/nir_intrinsics.py > b/

[Mesa-dev] [PATCH] radv: ignore pInheritanceInfo for primary command buffers

From the Vulkan spec: "If this is a primary command buffer, then this value is ignored." 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 i

Re: [Mesa-dev] [PATCH mesa 2/4] vulkan: add VK_EXT_display_control [v8]

Danylo Piliaiev writes: > Hello Keith, > > I am not able to build Mesa after this patch: > > wsi/wsi_common_display.c:991:4: error: unknown field ‘sequence_handler’ > specified in initializer >     .sequence_handler = wsi_display_sequence_handler, Sounds like you need a newer libdrm that inclu

[Mesa-dev] [PATCH 0/4] fixes primarily for LLVM trunk support v2

These code changes were made in between some of the formatting changes. Unforunately we do have another formatting patch coming in after this, but I will keep that separate. These patches are primarily focused on enhancing the BuilderGfxMem in our internal rasterizer and to support changes in the

[Mesa-dev] [PATCH 3/4] swr/rast: Handling removed LLVM intrinsics in trunk

- Functionality replaced with emulated intrinsics - Fixes Bug 106558 --- .../jitter/functionpasses/lower_x86.cpp | 40 +++ 1 file changed, 40 insertions(+) diff --git a/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86.cpp b/src/gallium/drivers/swr/rasteri

[Mesa-dev] [PATCH 2/4] swr/rast: Adding SCATTERPS functionality to BuilderGfxMem

--- .../swr/rasterizer/jitter/builder_gfx_mem.cpp | 13 + .../drivers/swr/rasterizer/jitter/builder_gfx_mem.h | 6 ++ 2 files changed, 19 insertions(+) diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.cpp b/src/gallium/drivers/swr/rasterizer/jitter/bu

[Mesa-dev] [PATCH 4/4] swr/rast: Fix addPassesToEmitFile usage with llvm-7.0.

From: Vinson Lee Fix build error after llvm-7.0svn r332881 ("CodeGen: Add a dwo output file argument to addPassesToEmitFile and hook it up to dwo output."). CXX rasterizer/jitter/libmesaswr_la-JitManager.lo rasterizer/jitter/JitManager.cpp:368:93: error: too few arguments to function cal

[Mesa-dev] [PATCH 1/4] swr/rast: Adding Read/Write specifier to TranslateGfxAddress stack

- Removing unused generic translate function - Requiring read/write specifier in builder_gfx_mem --- .../swr/rasterizer/jitter/builder_gfx_mem.cpp | 18 - .../swr/rasterizer/jitter/builder_gfx_mem.h | 37 ++- 2 files changed, 28 insertions(+), 27 deletions(-) diff --git

Re: [Mesa-dev] [PATCH mesa 2/4] vulkan: add VK_EXT_display_control [v8]

Thanks, then should this dependency be expressed in autoconf and meson? - Danil On 25.06.18 17:32, Keith Packard wrote: Danylo Piliaiev writes: Hello Keith, I am not able to build Mesa after this patch: wsi/wsi_common_display.c:991:4: error: unknown field ‘sequence_handler’ specified in in

[Mesa-dev] [PATCH] virgl: Add support for glGetMultisample

Use caps to obtain the multisample sample positions for up to 16 positions and implement the according Gallium interface. Signed-off-by: Gert Wollny --- This patch requires another patch against virglrenderer to work. src/gallium/drivers/virgl/virgl_context.c | 48 +++ src/

Re: [Mesa-dev] [PATCH] virgl: Add support for glGetMultisample

On Mon, Jun 25, 2018 at 10:55 AM, Gert Wollny wrote: > diff --git a/src/gallium/drivers/virgl/virgl_screen.c > b/src/gallium/drivers/virgl/virgl_screen.c > index c9d8b84062..e8d1c75177 100755 > --- a/src/gallium/drivers/virgl/virgl_screen.c > +++ b/src/gallium/drivers/virgl/virgl_screen.c > @@ -4

Re: [Mesa-dev] [PATCH mesa 2/4] vulkan: add VK_EXT_display_control [v8]

Danylo Piliaiev writes: > Thanks, then should this dependency be expressed in autoconf and > meson? Yup; looks like we missed a step. -- -keith signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https:

[Mesa-dev] [PATCH] virgl: Add support for glGetMultisample (v2)

Use caps to obtain the multisample sample positions for up to 16 positions and implement the according Gallium interface. v2: remove unrelated chunk (thanks Ilia Mirkin) Signed-off-by: Gert Wollny --- This patch requires another patch against virglrenderer to work. src/gallium/drivers/virgl/v

Re: [Mesa-dev] [PATCH mesa 2/4] vulkan: add VK_EXT_display_control [v8]

Also to fix a part of the issue in autoconf (with xcb-randr) I sent the patch previously. I believe it won't merge cleanly now, should I remake it? And I noticed that in meson build xcb-randr dependency is set to >= 1.12 : dep_xcb_xrandr = depe

Re: [Mesa-dev] [PATCH 0/2] r600: Fix array texture slice index evaluation

I didn't actually get the original email for some reason, so can't comment inline as I'm just looking it up at patchwork... But the array offset stuff (the first patch) looks completely bogus to me, array textures do not support offsets for the array index, at least not in any shader language I kno

Re: [Mesa-dev] [PATCH 3/4] glsl/glcpp/tests: reinstate srcdir/abs_builddir blurb

Quoting Dylan Baker (2018-06-21 08:15:20) > Quoting Emil Velikov (2018-04-24 10:49:21) > > From: Emil Velikov > > > > Bring back the "detection" of the said variables, to allow > > standalone execution. > > > > Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python > > script") > >

Re: [Mesa-dev] [PATCH] mesa: Unconditionally enable floating-point textures

I know I'm a bit late to the party here, but WooHoo! We've been waiting for this to go away for years now. While we still probably need to keep some workaround code around for a bit since various "system" versions won't have it for a while, we can finally start reliably depending on floating poin

[Mesa-dev] [PATCH 0/2] Two stable fixes for call instructions

These two patches are fixes for call instructions that get the basemark shaders to pass NIR validation. Since the deref instruction stuff has landed, these will have to go straight to stable without ever hitting master. Dylan, please merge to whatever place you merge stable things once they've ha

[Mesa-dev] [PATCH 1/2] nir: Handle call instructions in foreach_src

Even though they don't have regular sources, they do have derefs and those may have implied sources that should be handled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106980 --- src/compiler/nir/nir.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH 1/2] nir: Handle call instructions in foreach_src

Even though they don't have regular sources, they do have derefs and those may have implied sources that should be handled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106980 --- src/compiler/nir/nir.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH 2/2] nir/validate: Use the type from the tail of call parameter derefs

Otherwise, if what gets passed into the function call is a deref chain longer than just a variable deref, we would use the type of the entire variable rather than the type of the thing being dereferenced. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106980 --- src/compiler/nir/nir_valid

[Mesa-dev] [PATCH 2/2] nir/validate: Use the type from the tail of call parameter derefs

Otherwise, if what gets passed into the function call is a deref chain longer than just a variable deref, we would use the type of the entire variable rather than the type of the thing being dereferenced. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106980 --- src/compiler/nir/nir_valid

[Mesa-dev] [Bug 106980] Basemark GPU vulkan benchmark fails.

https://bugs.freedesktop.org/show_bug.cgi?id=106980 --- Comment #5 from Jason Ekstrand --- I just sent two patches for stable which fix the validation issues. Turns out there's nothing wrong with spirv_to_nir, just the validator having issues. Sadly, that means the hang is likely real. :-( --

Re: [Mesa-dev] [PATCH v2 1/4] mesa: add header for share bptc decompress functions

This looks OK, but did you try to build other gallium state trackers? They don't link with anything in src/mesa, so the build will fail, because the bptc functions are missing. The solution used for other formats was to put all functions into header files, see texcompress_*_tmp.h. Another solution

Re: [Mesa-dev] [RESEND PATCH v5 0/3] egl/android: Add DRM node probing and filtering

Pushed. On 2018-06-25 13:39, Robert Foss wrote: [RESEND] due to the previous version sent to the ML mistakenly being v4 again. Please excuse the spam. This series replaces the dependency on GRALLOC_MODULE_PERFORM_GET_DRM_FD with DRM node probing and disables the support for drm_gralloc. The se

Re: [Mesa-dev] Testing drm_hwcomposer in RPi

Hey Chris, On Fri, Jun 22, 2018 at 12:09 PM, chris simmonds wrote: > Hi. > > I would like to try out drm_hwcomposer on a RPi 3. Can anyone point me to a > howto or something that tells me how? > > FYI, this is part of a side project to port drm_hwcomposer to BeagleBones > and other things based o

[Mesa-dev] [PATCH 1/6] i965/vec4: Silence unused parameter warnings in vec4 compiler tests

From: Ian Romanick src/intel/compiler/test_vec4_copy_propagation.cpp: In member function ‘virtual brw::dst_reg* copy_propagation_vec4_visitor::make_reg_for_system_value(int)’: src/intel/compiler/test_vec4_copy_propagation.cpp:57:51: warning: unused parameter ‘location’ [-Wunused-parameter]

[Mesa-dev] [PATCH 2/6] i965/vec4/dce: Don't narrow the write mask if the flags are used

From: Ian Romanick In an instruction sequence like cmp(8).ge.f0.0 vgrf17:D, vgrf2.:D, vgrf9.:D (+f0.0) sel(8) vgrf1:UD, vgrf8.xyzw:UD, vgrf1.xyzw:UD The other fields of vgrf17 may be unused, but the CMP still needs to generate the other flag bits. To my surprise, nothin

[Mesa-dev] [PATCH 0/6] More cmod propagation and CSEL instructions

Patch series also available at: https://cgit.freedesktop.org/~idr/mesa/log/?h=cmod-propagation-work ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/6] i965/fs: Eliminate unary op on operand of compare-with-zero

From: Ian Romanick All Gen7+ platforms had similar results. (Broadwell shown) total instructions in shared programs: 14715715 -> 14715709 (<.01%) instructions in affected programs: 474 -> 468 (-1.27%) helped: 6 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 1.12%

[Mesa-dev] [PATCH 5/6] i965/fs: Allow Boolean conditions in CSEL generation

From: Ian Romanick This can increase register pressure. I think there may be some ways to mitigate this, but that will take more work. By percentage of instructions reduced, the most helped shader had a block of code like: cmp.z.f0(8) g51<1>D g21<8,8,1>D 1D (+f0) sel(8)

[Mesa-dev] [PATCH 4/6] i965/fs: Relax type matching rules in cmod propagation from MOV instructions

From: Ian Romanick To allow cmod propagation from a MOV in a sequence like: and(16) g31<1>UD g20<8,8,1>UD g22<8,8,1>UD mov.nz.f0(16) null<1>F g31<8,8,1>D A similar change to the vec4 backend had no effect. The SIMD8 and SIMD16 shaders in two UE4 demos are helped

[Mesa-dev] [PATCH 6/6] i965/vec4: Propagate conditional modifiers from more compares to other compares

From: Ian Romanick If there is a CMP.NZ that compares a single component (via a . swizzle, for example) with 0, it can propagate its conditional modifier back to a previous CMP that writes only that component. The specific case that I saw was: cmp.l.f0(8) g42<1>.xF g61<4>.xF

Re: [Mesa-dev] [PATCH 0/1] swr/rast: last swr formatting changes for a while

On Friday, 2018-06-22 09:11:25 -0500, Alok Hota wrote: > Sorry for the churn on these patches. They had to be split in three due > to some code changes in between a mass formatting change. Anyway this > patch contains only formatting changes for the files that were updated > in the last patch It's

Re: [Mesa-dev] [PATCH] nir: add lowering for gl_HelperInvocation

On 06/19/2018 08:24 AM, Rob Clark wrote: > v2: reword comment about lower_helper_invocations to be more clear > that it might not work on all hardware > v3: add special variant of load_sample_id which does not imply per- > sample shading > > Signed-off-by: Rob Clark > --- > Yeah, new intr

Re: [Mesa-dev] [PATCH] nir: add lowering for gl_HelperInvocation

On Mon, Jun 25, 2018 at 2:23 PM, Ian Romanick wrote: > On 06/19/2018 08:24 AM, Rob Clark wrote: >> v2: reword comment about lower_helper_invocations to be more clear >> that it might not work on all hardware >> v3: add special variant of load_sample_id which does not imply per- >> sample s

Re: [Mesa-dev] [PATCH] nir: add lowering for gl_HelperInvocation

On Mon, Jun 25, 2018 at 2:29 PM, Ilia Mirkin wrote: > On Mon, Jun 25, 2018 at 2:23 PM, Ian Romanick wrote: >> On 06/19/2018 08:24 AM, Rob Clark wrote: >>> v2: reword comment about lower_helper_invocations to be more clear >>> that it might not work on all hardware >>> v3: add special variant

Re: [Mesa-dev] [PATCH] nir: add lowering for gl_HelperInvocation

On Mon, Jun 25, 2018 at 2:38 PM, Rob Clark wrote: > On Mon, Jun 25, 2018 at 2:29 PM, Ilia Mirkin wrote: >> On Mon, Jun 25, 2018 at 2:23 PM, Ian Romanick wrote: >>> On 06/19/2018 08:24 AM, Rob Clark wrote: v2: reword comment about lower_helper_invocations to be more clear that it mi

[Mesa-dev] [PATCH] mesa: Save and restore NV_fog_distance & FOG_COORD_SRC state

FOG_DISTANCE_MODE_NV & FOG_COORD_SRC weren't getting saved into display lists or restored on glPopAttrib(GL_FOG_BIT). Signed-off-by: Nicholas Miell --- src/mesa/main/attrib.c | 4 src/mesa/main/dlist.c | 2 ++ 2 files changed, 6 insertions(+) diff --git a/src/mesa/main/attrib.c b/src/mesa

Re: [Mesa-dev] [PATCH] mesa: Save and restore NV_fog_distance & FOG_COORD_SRC state

On 06/25/2018 11:53 AM, Nicholas Miell wrote: > FOG_DISTANCE_MODE_NV & FOG_COORD_SRC weren't getting saved > into display lists or restored on glPopAttrib(GL_FOG_BIT). Good catch. How did you detect this? Do we have any test cases? > > Signed-off-by: Nicholas Miell > --- > src/mesa/main/attr

Re: [Mesa-dev] [PATCH 0/2] Two stable fixes for call instructions

Quoting Jason Ekstrand (2018-06-25 09:13:03) > These two patches are fixes for call instructions that get the basemark > shaders to pass NIR validation. Since the deref instruction stuff has > landed, these will have to go straight to stable without ever hitting > master. > > Dylan, please merge

Re: [Mesa-dev] [PATCH] mesa: Save and restore NV_fog_distance & FOG_COORD_SRC state

On 06/25/2018 12:04 PM, Ian Romanick wrote: > On 06/25/2018 11:53 AM, Nicholas Miell wrote: >> FOG_DISTANCE_MODE_NV & FOG_COORD_SRC weren't getting saved >> into display lists or restored on glPopAttrib(GL_FOG_BIT). > > Good catch. How did you detect this? Do we have any test cases? > I honest

Re: [Mesa-dev] [PATCH 0/2] Two stable fixes for call instructions

On June 25, 2018 12:09:50 Dylan Baker wrote: Quoting Jason Ekstrand (2018-06-25 09:13:03) These two patches are fixes for call instructions that get the basemark shaders to pass NIR validation. Since the deref instruction stuff has landed, these will have to go straight to stable without ever

[Mesa-dev] Does Mesa have a policy for OpenGL token naming?

When extensions get promoted into OpenGL itself, they keep the same token names minus the _EXT or whatever postfix, which means grepping for the tokens in the OpenGL specification will find the implementation in the Mesa source even if it still uses the original token names from the extension. Unf

Re: [Mesa-dev] [PATCH 0/2] Two stable fixes for call instructions

Quoting Jason Ekstrand (2018-06-25 12:36:39) > On June 25, 2018 12:09:50 Dylan Baker wrote: > > > Quoting Jason Ekstrand (2018-06-25 09:13:03) > >> These two patches are fixes for call instructions that get the basemark > >> shaders to pass NIR validation. Since the deref instruction stuff has >

Re: [Mesa-dev] [PATCH] travis: use https for all the links

On Monday, 2018-06-25 11:03:04 +0100, Emil Velikov wrote: > From: Emil Velikov > > Signed-off-by: Emil Velikov Good idea :) Reviewed-by: Eric Engestrom > --- > .travis.yml | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/.travis.yml b/.travis.yml > inde

Re: [Mesa-dev] [PATCH 0/2] r600: Fix array texture slice index evaluation

Am Montag, den 25.06.2018, 17:36 +0200 schrieb Roland Scheidegger: > I didn't actually get the original email for some reason, so can't > comment inline as I'm just looking it up at patchwork... > But the array offset stuff (the first patch) looks completely bogus > to me, array textures do not sup

[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

https://bugs.freedesktop.org/show_bug.cgi?id=106595 --- Comment #19 from Philip Rebohle --- The DXVK bug causing the aspect mask to be 0 was introduced on June 12th and was fixed a few days ago, but apparently the issue persists. -- You are receiving this mail because: You are the QA Contact fo

Re: [Mesa-dev] [PATCH 1/2] nouveau: Add basic memory object support

On Fri, 22 Jun 2018 20:37:19 -0400 Ilia Mirkin wrote: > On Fri, Jun 22, 2018 at 8:22 PM, Miguel Angel Vico > wrote: > > > > > > On Thu, 21 Jun 2018 22:09:14 -0400 > > Ilia Mirkin wrote: > > > >> Hi Miguel, > >> > >> Preface: I know little about this ext, so feel free to educate me on > >>

Re: [Mesa-dev] [PATCH 0/2] r600: Fix array texture slice index evaluation

Am 25.06.2018 um 22:13 schrieb Gert Wollny: > Am Montag, den 25.06.2018, 17:36 +0200 schrieb Roland Scheidegger: >> I didn't actually get the original email for some reason, so can't >> comment inline as I'm just looking it up at patchwork... >> But the array offset stuff (the first patch) looks co

Re: [Mesa-dev] Does Mesa have a policy for OpenGL token naming?

On 06/25/2018 12:41 PM, Nicholas Miell wrote: > When extensions get promoted into OpenGL itself, they keep the same > token names minus the _EXT or whatever postfix, which means grepping for > the tokens in the OpenGL specification will find the implementation in > the Mesa source even if it still

Re: [Mesa-dev] [PATCH 0/2] Two stable fixes for call instructions

Series is Reviewed-by: Ian Romanick On 06/25/2018 09:13 AM, Jason Ekstrand wrote: > These two patches are fixes for call instructions that get the basemark > shaders to pass NIR validation. Since the deref instruction stuff has > landed, these will have to go straight to stable without ever hit

Re: [Mesa-dev] [PATCH] Plumb invariant output attrib thru TGSI

ping... On Wed, Jun 20, 2018 at 5:55 PM, Robert Tarasov wrote: > From: "Joe M. Kniss" > > Add support for glsl 'invariant' modifier for output data declarations. > Gallium drivers that use TGSI serialization currently loose invariant > modifiers in glsl shaders. > > v2: use boolean for invarian

[Mesa-dev] [PATCH] nir/opt_if: Remove unneeded phis if we make progress

Now that SSA values can be derefs and they have special rules, we have to be a bit more careful about our LCSSA phis. In particular, we need to clean up in case LCSSA ended up creating a phi node for a deref. This fixes validation issues with some Vulkan CTS tests with the new deref instructions.

Re: [Mesa-dev] [PATCH 01/19] radeonsi: clean up passing the is_monolithic flag for compilation

Hello Marek, after this series landed I get this: Making all in targets/pipe-loader make[4]: Verzeichnis „/opt/mesa/src/gallium/targets/pipe-loader“ wird betreten CXXLDpipe_r600.la ../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a(radeon_drm_surface.o): In function `rade

Re: [Mesa-dev] [PATCH 01/19] radeonsi: clean up passing the is_monolithic flag for compilation

If I disable 'r600' all is fine, but... --with-gallium-drivers=radeonsi,swrast --with-gallium-drivers=r600,radeonsi,swrast Worked before OK. Dieter Am 26.06.2018 01:51, schrieb Dieter Nützel: Hello Marek, after this series landed I get this: Making all in targets/pipe-loader make[4]: Verzeic

[Mesa-dev] [Bug 105699] s3tc fbo-generatemipmap-formats tests fail unless optimized

https://bugs.freedesktop.org/show_bug.cgi?id=105699 Mark Janes changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [Mesa-dev] [PATCH 01/19] radeonsi: clean up passing the is_monolithic flag for compilation

On 26/06/18 09:51, Dieter Nützel wrote: Hello Marek, after this series landed I get this: Making all in targets/pipe-loader make[4]: Verzeichnis „/opt/mesa/src/gallium/targets/pipe-loader“ wird betreten   CXXLD    pipe_r600.la ../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a

[Mesa-dev] [PATCH] radeon: duplicate cmask surface for now.

From: Dave Airlie The radeon winsys isn't linked against the ac code, I have vague memories of this causing some problems before, for now fix the build but just duplicating the code. --- .../winsys/radeon/drm/radeon_drm_surface.c| 62 ++- 1 file changed, 61 insertions(+), 1 d

Re: [Mesa-dev] [PATCH] radeon: duplicate cmask surface for now.

Compiling tested. (Didn't have any r600 hw in my box currently.) could be tb ;-) Thanks for your fast fix! Dieter Am 26.06.2018 02:50, schrieb Dave Airlie: From: Dave Airlie The radeon winsys isn't linked against the ac code, I have vague memories of this causing some problems before, for now

Re: [Mesa-dev] [PATCH] radeon: duplicate cmask surface for now.

Reviewed-by: Marek Olšák Thanks! Marek On Mon, Jun 25, 2018 at 8:50 PM, Dave Airlie wrote: > From: Dave Airlie > > The radeon winsys isn't linked against the ac code, I have vague > memories of this causing some problems before, for now fix the build > but just duplicating the code. > --- >

Re: [Mesa-dev] [PATCH] swr: bump minimum supported LLVM version to 5.0

Good timing. I have a patch that removes LLVM 5.0 support from AMD Mesa drivers. :) Marek On Thu, Jun 21, 2018 at 5:51 AM, Eric Engestrom wrote: > On Thursday, 2018-06-21 11:42:29 +0200, Juan A. Suarez Romero wrote: >> On Tue, 2018-06-19 at 11:53 +0200, Juan A. Suarez Romero wrote: >> > On Mon,

Re: [Mesa-dev] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

Am 25.06.2018 13:26, schrieb Timothy Arceri: Please note I've fixed up make check where is was broken when enabling some of these extensions. You can see all of the latests compat patches here: https://gitlab.freedesktop.org/tarceri/mesa/commits/ARB_gpu_shader_fp64 For the whole series (1-9 f

Re: [Mesa-dev] [PATCH 01/19] radeonsi: clean up passing the is_monolithic flag for compilation

R300 had the same problem. Linking to amd_common ends up pulling in addrlib too. Jfyi On June 25, 2018 5:48:51 PM PDT, Timothy Arceri wrote: >On 26/06/18 09:51, Dieter Nützel wrote: >> Hello Marek, >> >> after this series landed I get this: >> >> Making all in targets/pipe-loader >> make[4]: V

Re: [Mesa-dev] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

Hi I can confirm I no longer need to pass MESA_GL_VERSION_OVERRIDE to Dying Light Tested-by: Mike Lothian Cheers Mike On Tue, 26 Jun 2018 at 04:41 Dieter Nützel wrote: > Am 25.06.2018 13:26, schrieb Timothy Arceri: > > Please note I've fixed up make check where is was broken when enabling >