Re: [Mesa-dev] [PATCH 1/2] util: try to fix the Android build

On 09/10/2018 08:02 AM, Tapani Pälli wrote: Thanks Marek, this fixes the build. (and reason for breakage was that bionic does not have pthread_setaffinity_np) Reviewed-by: Tapani Pälli On 09/09/2018 04:02 AM, Marek Olšák wrote: From: Marek Olšák ---   src/util/u_thread.h | 7 +--

Re: [Mesa-dev] [PATCH 1/2] util: try to fix the Android build

Thanks Marek, this fixes the build. Reviewed-by: Tapani Pälli On 09/09/2018 04:02 AM, Marek Olšák wrote: From: Marek Olšák --- src/util/u_thread.h | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/util/u_thread.h b/src/util/u_thread.h index ec0d9a7..0c20ebb

[Mesa-dev] [AppVeyor] mesa master #8841 failed

Build mesa 8841 failed Commit 240af61494 by Dave Airlie on 8/28/2018 10:32 PM: virgl: don't send a shader create with no data. (v2)\n\nThis fixes the situation where we'd send a shader with just the\nheader and no data.\n\npiglit/glsl-max-varyings test was

[Mesa-dev] [Bug 107878] Artifacting Hair on Overwatch vega56

https://bugs.freedesktop.org/show_bug.cgi?id=107878 Bug ID: 107878 Summary: Artifacting Hair on Overwatch vega56 Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: normal

Re: [Mesa-dev] [PATCH] mesa: Validate the result of pipe_transfer_map in make_texture

And apparently I am incapable of operating git send-email, so it failed to include my context: When using Freecad, I was getting intermittent segfaults inside of mesa. I traced it down to this path in st_cb_drawpixels.c where the result of pipe_transfer_map wasn't being checked. In my case, it

[Mesa-dev] [PATCH] mesa: Validate the result of pipe_transfer_map in make_texture

--- src/mesa/state_tracker/st_cb_drawpixels.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c b/src/mesa/state_tracker/st_cb_drawpixels.c index cb50b7104a..8d39b8a01b 100644 --- a/src/mesa/state_tracker/st_cb_drawpixels.c +++

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 10/09/18 11:01, Matt Turner wrote: On Sun, Sep 9, 2018 at 5:00 PM Timothy Arceri wrote: On 10/09/18 09:52, Matt Turner wrote: On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri wrote: On 10/09/18 09:22, Ian Romanick wrote: On 09/08/2018 06:37 AM, Jason Ekstrand wrote: Is there going to be

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 10/09/18 10:21, Timothy Arceri wrote: On 10/09/18 10:00, Ian Romanick wrote: On 09/09/2018 04:57 PM, Ian Romanick wrote: On 09/09/2018 04:52 PM, Matt Turner wrote: On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri wrote: On 10/09/18 09:22, Ian Romanick wrote: On 09/08/2018 06:37 AM, Jason

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On Sun, Sep 9, 2018 at 5:00 PM Timothy Arceri wrote: > On 10/09/18 09:52, Matt Turner wrote: > > On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri wrote: > >> > >> On 10/09/18 09:22, Ian Romanick wrote: > >>> On 09/08/2018 06:37 AM, Jason Ekstrand wrote: > Is there going to be an accompanying

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 10/09/18 10:40, Ian Romanick wrote: On 09/09/2018 05:00 PM, Timothy Arceri wrote: Ian made it pretty clear he didn't want a debate and had already made up his mind. "We decided years ago that we were not going to support this horrible, underspecified steaming pile of an extension in Mesa. 

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 09/09/2018 05:00 PM, Timothy Arceri wrote: > Ian made it pretty clear he didn't want a debate and had already made up > his mind. > > "We decided years ago that we were not going to support this horrible, > underspecified steaming pile of an extension in Mesa.  I am not > interested in going

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 10/09/18 10:00, Ian Romanick wrote: On 09/09/2018 04:57 PM, Ian Romanick wrote: On 09/09/2018 04:52 PM, Matt Turner wrote: On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri wrote: On 10/09/18 09:22, Ian Romanick wrote: On 09/08/2018 06:37 AM, Jason Ekstrand wrote: Is there going to be an

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 10/09/18 09:52, Ian Romanick wrote: On 09/09/2018 04:41 PM, Timothy Arceri wrote: On 10/09/18 09:22, Ian Romanick wrote: On 09/08/2018 06:37 AM, Jason Ekstrand wrote: Is there going to be an accompanying series on the piglit list?  I don't see anything there immediately. Which is one of

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 09/09/2018 04:57 PM, Ian Romanick wrote: > On 09/09/2018 04:52 PM, Matt Turner wrote: >> On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri wrote: >>> >>> On 10/09/18 09:22, Ian Romanick wrote: On 09/08/2018 06:37 AM, Jason Ekstrand wrote: > Is there going to be an accompanying series on

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 10/09/18 09:52, Matt Turner wrote: On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri wrote: On 10/09/18 09:22, Ian Romanick wrote: On 09/08/2018 06:37 AM, Jason Ekstrand wrote: Is there going to be an accompanying series on the piglit list? I don't see anything there immediately. Which

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 09/09/2018 04:52 PM, Matt Turner wrote: > On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri wrote: >> >> On 10/09/18 09:22, Ian Romanick wrote: >>> On 09/08/2018 06:37 AM, Jason Ekstrand wrote: Is there going to be an accompanying series on the piglit list? I don't see anything there

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri wrote: > > On 10/09/18 09:22, Ian Romanick wrote: > > On 09/08/2018 06:37 AM, Jason Ekstrand wrote: > >> Is there going to be an accompanying series on the piglit list? I don't > >> see anything there immediately. > > > > Which is one of the major

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 09/09/2018 04:41 PM, Timothy Arceri wrote: > On 10/09/18 09:22, Ian Romanick wrote: >> On 09/08/2018 06:37 AM, Jason Ekstrand wrote: >>> Is there going to be an accompanying series on the piglit list?  I don't >>> see anything there immediately. >> >> Which is one of the major reasons we

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 10/09/18 09:22, Ian Romanick wrote: On 09/08/2018 06:37 AM, Jason Ekstrand wrote: Is there going to be an accompanying series on the piglit list?  I don't see anything there immediately. Which is one of the major reasons we decided we'd never implement this extension in Mesa. To test it

Re: [Mesa-dev] [PATCH 01/13] mesa: add a list of EXT_direct_state_access to dispatch sanity

On 10/09/18 08:54, Ian Romanick wrote: We decided years ago that we were not going to support this horrible, underspecified steaming pile of an extension in Mesa. I am not interested in going back on that decision now or, frankly, ever. This will only hurt users of Mesa and continue the "just

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

On 09/08/2018 06:37 AM, Jason Ekstrand wrote: > Is there going to be an accompanying series on the piglit list?  I don't > see anything there immediately. Which is one of the major reasons we decided we'd never implement this extension in Mesa. To test it to the quality levels that we expect, it

Re: [Mesa-dev] [PATCH 01/13] mesa: add a list of EXT_direct_state_access to dispatch sanity

We decided years ago that we were not going to support this horrible, underspecified steaming pile of an extension in Mesa. I am not interested in going back on that decision now or, frankly, ever. On 09/07/2018 09:31 PM, Timothy Arceri wrote: > This extension is huge and this gives us a TODO

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_vertex_program in core profile

No. This is one is definitely out. ARB_vertex_program *require* all of the legacy stuff that core profile removes. There is no way this one is valid. On 09/07/2018 09:20 PM, Timothy Arceri wrote: > This extension is required by "Wolfenstein: The Old Blood". Without > it the app causes wine to

[Mesa-dev] [Bug 99765] Make Octopus OpenCL support work on Clover and RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=99765 Timothy Arceri changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover QA

[Mesa-dev] [Bug 94273] Clover on RadeonSI OpenCL segfault during testing of clBLAS

https://bugs.freedesktop.org/show_bug.cgi?id=94273 Timothy Arceri changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.

[Mesa-dev] [Bug 91305] [clover/kaveri] When running JohnTheRipper OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec

https://bugs.freedesktop.org/show_bug.cgi?id=91305 Timothy Arceri changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.

[Mesa-dev] [Bug 100105] Make Theano OpenCL support work on Clover and RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=100105 Timothy Arceri changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover

[Mesa-dev] [Bug 102009] [clover, amdgcn] Blender crashes when compiling OpenCL kernel

https://bugs.freedesktop.org/show_bug.cgi?id=102009 Timothy Arceri changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.

[Mesa-dev] [Bug 82717] OpenCL support for mandelbulber-opencl

https://bugs.freedesktop.org/show_bug.cgi?id=82717 Timothy Arceri changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.

[Mesa-dev] [Bug 107115] Make darktable OpenCL support work on Clover and RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=107115 Timothy Arceri changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.

[Mesa-dev] [Bug 87738] [OpenCL] Please add Image support

https://bugs.freedesktop.org/show_bug.cgi?id=87738 Timothy Arceri changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover

[Mesa-dev] [Bug 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Timothy Arceri changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/Clover QA

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

https://bugs.freedesktop.org/show_bug.cgi?id=107873 --- Comment #3 from Ahmed Elsayed --- I tried both OpenGL and Vulkan and same gave me the same behavior. I am trying to compile Mesa 18.3 for the third time because it failed in the last 2 times. I hope it will be built without errors this

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

On 9/9/18 9:40 PM, Ilia Mirkin wrote: On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote: Tests showed Intel on windows does always clamp RCP, RSQ and LOG (thus preventing inf/nan generation), for all shader versions (some vendor behaviours vary with shader versions). By the way, this happens

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

On 9/9/18 9:35 PM, Ilia Mirkin wrote: On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote: For now clamp for all drivers. An ulterior optimization would be to avoid clamping for drivers with MUL_ZERO_WINS for the specific shader versions where NV or AMD don't clamp. Too bad. The whole point of

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote: > Tests showed Intel on windows does always clamp > RCP, RSQ and LOG (thus preventing inf/nan generation), > for all shader versions (some vendor behaviours vary > with shader versions). By the way, this happens because on Intel, the ALU is put

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote: > For now clamp for all drivers. An ulterior optimization > would be to avoid clamping for drivers with MUL_ZERO_WINS > for the specific shader versions where NV or AMD don't > clamp. Too bad. The whole point of this feature was for nine to use

[Mesa-dev] [PATCH 4/5] st/nine: Add new helper for object creation with bind

Add a new helper to create objects starting with a bind count instead of a ref count. Signed-off-by: Axel Davy --- .../state_trackers/nine/nine_helpers.h| 26 +++ 1 file changed, 26 insertions(+) diff --git a/src/gallium/state_trackers/nine/nine_helpers.h

[Mesa-dev] [PATCH 5/5] st/nine: Avoid RefToBind calls in ff

When using csmt, ff shader creation happens on the csmt thread. Creating the shaders, then calling RefToBind causes the device ref to be increased then decreased. However the device dtor assumes than no work pending on the csmt thread could increase the device ref, leading to hang. The issue is

[Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

Tests done on several devices of all 3 vendors and of different generations showed that there are several ways of handling infs and NaN for d3d9. Tests showed Intel on windows does always clamp RCP, RSQ and LOG (thus preventing inf/nan generation), for all shader versions (some vendor behaviours

[Mesa-dev] [PATCH 3/5] st/nine: Add parameter to start with bind

Add a parameter to start new object with a bind instead of a refcount. Signed-off-by: Axel Davy --- src/gallium/state_trackers/nine/iunknown.c | 18 +++--- src/gallium/state_trackers/nine/iunknown.h | 1 + src/gallium/state_trackers/nine/nine_helpers.h | 2 ++ 3 files

[Mesa-dev] [PATCH 2/5] st/nine: Use perspective correction for ps depth fog

Emulate perspective interpolation of depth for programmable ps fog ff ps fog uses position z, or 1/w depending on the ff projection matrix set. This is according to public documents found describing the algorithm and tests we made. In the case of programmable ps, we used position's z, which was

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

https://bugs.freedesktop.org/show_bug.cgi?id=107873 --- Comment #2 from Bas Nieuwenhuizen --- So just to check, you enabled Vulkan instead of GL rendering? Doom is using GL by default. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

Am 09.09.2018 um 12:49 schrieb Naveen Naidu: On Sun 9 Sep, 2018, 4:06 PM Christian König, > wrote: Am 09.09.2018 um 09:55 schrieb Naveen Naidu: Thank you for the information. Yes I have a AMD GPU, It is a Radeon r5 m430. But unfortunately

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

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

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

https://bugs.freedesktop.org/show_bug.cgi?id=107873 --- Comment #1 from Ahmed Elsayed --- System information: Operating system: Manjaro KDE (the latest version). GPU: AMD HD 8750M Driver: 18.2.0-1 Wine version: 3.15 staging -- You are receiving this mail because: You are the assignee for

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

https://bugs.freedesktop.org/show_bug.cgi?id=107873 Bug ID: 107873 Summary: Doom 2016 - Rendering issues Product: Mesa Version: 18.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal

[Mesa-dev] [Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false

https://bugs.freedesktop.org/show_bug.cgi?id=105333 --- Comment #6 from Axel Davy --- Given the regression bisect found the issue came with a radeonsi patch, I reassign to radeonsi. Maybe the patch introduces a small difference in the driver behaviour that regresses nine ? -- You are receiving

[Mesa-dev] [Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false

https://bugs.freedesktop.org/show_bug.cgi?id=105333 Axel Davy changed: What|Removed |Added Component|Gallium/StateTracker/galliu |Drivers/Gallium/radeonsi

[Mesa-dev] [Bug 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled

https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #5 from Axel Davy --- Could you try to launch the game in a wine virtual desktop (see winecfg) see if the issue is unaffected ? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

On Sun 9 Sep, 2018, 4:06 PM Christian König, < ckoenig.leichtzumer...@gmail.com> wrote: > Am 09.09.2018 um 09:55 schrieb Naveen Naidu: > > > Thank you for the information. Yes I have a AMD GPU, It is a Radeon r5 > m430. But unfortunately it does not have a video decoder. But I also have > an

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

Am 09.09.2018 um 09:55 schrieb Naveen Naidu: Thank you for the information. Yes I have a AMD GPU, It is a Radeon r5 m430. But unfortunately it does not have a video decoder. But I also have an integrated Intel HD 620 GPU, it's a kabylake and It had a video encoder and video decoder. I have

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/3] android: broadcom/genxml: fix collision with intel/genxml header-gen macro

Hi, Il giorno gio 6 set 2018 alle ore 18:20 Dylan Baker ha scritto: > > Quoting Rob Herring (2018-09-06 07:16:07) > > On Mon, Sep 3, 2018 at 4:27 PM Eric Anholt wrote: > > > > > > Mauro Rossi writes: > > > > > > > Fixes the following building error, happening when building both intel > > > >

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

//lists.freedesktop.org/mailman/listinfo/mesa-dev > > Tested-by: Vinson Lee > > > -- > > Message: 3 > Date: Sun, 09 Sep 2018 05:34:28 + > From: bugzilla-dae...@freedesktop.org > To: mesa-dev@lists.freedesktop.org > Subject: [Mesa-

Re: [Mesa-dev] [PATCH] utils/u_math: break dependency on gallium/utils

I think this will break non-GL gallium state trackers. src/mesa is only for GL, which is why common gallium code and gallium drivers can't use code from src/mesa. Marek On Sun, Sep 9, 2018 at 2:39 AM, Dylan Baker wrote: > Currently u_math needs gallium utils for cpu detection. Most of what >

Re: [Mesa-dev] mesa-dev Digest, Vol 102, Issue 134

o/mesa-dev > > Tested-by: Vinson Lee > > > -- > > Message: 3 > Date: Sun, 09 Sep 2018 05:34:28 + > From: bugzilla-dae...@freedesktop.org > To: mesa-dev@lists.freedesktop.org > Subject: [Mesa-

[Mesa-dev] [Bug 107870] Undefined symbols for architecture x86_64: "_util_cpu_caps"

https://bugs.freedesktop.org/show_bug.cgi?id=107870 --- Comment #1 from Dylan Baker --- I've sent a patch to the list that hopefully fixes this. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the

[Mesa-dev] [Bug 107870] Undefined symbols for architecture x86_64: "_util_cpu_caps"

https://bugs.freedesktop.org/show_bug.cgi?id=107870 Dylan Baker changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |baker.dyla...@gmail.com

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

Welcome! From the page: https://www.x.org/wiki/SummerOfCodeIdeas/ Might try and ping Christian König. Do you have an AMD GPU? Benson On 09/09/2018 09:41 AM, Naveen Naidu wrote: Hello Everyone, I am Naveen a Junior year computer science undergrad from India. I really apologize for

[Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

Hello Everyone, I am Naveen a Junior year computer science undergrad from India. I really apologize for disturbing you all again. But I have been going through the available projects for the XorgEVoC program and the project *Piglit for VA-API *caught my attention. I have mailed last week looking

[Mesa-dev] [PATCH] utils/u_math: break dependency on gallium/utils

Currently u_math needs gallium utils for cpu detection. Most of what u_math uses out of u_cpu_detection is duplicated in src/mesa/x86 (surprise!), so I've just reworked it as much as possible to use the x86/common_x86_features macros instead of the gallium ones. There is one small function that