Re: [Mesa-dev] [PATCH 07/34] gbm: Export a per plane getter for offset

On 17-01-31 11:40:04, Jason Ekstrand wrote: On Mon, Jan 23, 2017 at 10:19 PM, Ben Widawsky wrote: Unlike stride, there was no previous offset getter, so it can be right on the first try. v2: Return EINVAL when plane is greater than total planes to make it match the similar

Re: [Mesa-dev] [PATCH 06/34] gbm: Export a per plane getter for stride

On 17-01-31 11:33:39, Jason Ekstrand wrote: On Mon, Jan 23, 2017 at 10:19 PM, Ben Widawsky wrote: v2: Preserve legacy behavior when plane is 0 (Jason Ekstrand) EINVAL when input plane is greater than total planes (Jason Ekstrand) Don't leak the image after fromPlanar

[Mesa-dev] [Bug 99467] [radv] DOOM 2016 + wine. Green screen everywhere (but can be started)

https://bugs.freedesktop.org/show_bug.cgi?id=99467 --- Comment #12 from Grazvydas Ignotas --- No improvement here compared to radv-wip-doom-wine from Dec 23, still suffering random fog/glare. -- You are receiving this mail because: You are the QA Contact for the bug. You are

Re: [Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

On 02/04/2017 05:48 AM, Bas Nieuwenhuizen wrote: > > On Fri, Feb 3, 2017, at 19:24, Jason Ekstrand wrote: >> On Fri, Feb 3, 2017 at 9:23 AM, Samuel Pitoiset >> > wrote: >> >> This is similar to the MESA_GLSL_VERSION_OVERRIDE

Re: [Mesa-dev] [PATCH 1/3] main/framebuffer: refactor _mesa_get_color_read_format/type

On Thu, Feb 2, 2017 at 10:51 AM, Alejandro Piñeiro wrote: > Current implementation returns the value for the currently bound read > framebuffer. GetNamedFramebufferParameteriv allows to get it for any > given framebuffer. GetFramebufferParameteriv would be also interested >

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

https://bugs.freedesktop.org/show_bug.cgi?id=77449 Bug 77449 depends on bug 98263, which changed state. Bug 98263 Summary: [radv] The Talos Principle fails to launch with "Fatal error: Cannot set display mode." https://bugs.freedesktop.org/show_bug.cgi?id=98263 What|Removed

[Mesa-dev] [Bug 98263] [radv] The Talos Principle fails to launch with "Fatal error: Cannot set display mode."

https://bugs.freedesktop.org/show_bug.cgi?id=98263 Rene Lindsay changed: What|Removed |Added Status|RESOLVED|REOPENED

Re: [Mesa-dev] [RFC PATCH] gallium: add a common uploader to pipe_context

On Fri, Feb 3, 2017 at 9:45 PM, Brian Paul wrote: > On 02/01/2017 02:23 PM, Brian Paul wrote: >> >> On 01/27/2017 04:00 AM, Marek Olšák wrote: >>> >>> On Fri, Jan 27, 2017 at 10:05 AM, Nicolai Hähnle >>> wrote: On 27.01.2017 00:51, Marek Olšák

Re: [Mesa-dev] [PATCH 2/2] anv: Implement the Sky Lake stencil PMA optimization

On Fri, Feb 03, 2017 at 12:27:18PM -0800, Jason Ekstrand wrote: > On Thu, Feb 2, 2017 at 1:45 PM, Nanley Chery wrote: > > > On Thu, Feb 02, 2017 at 01:37:56PM -0800, Nanley Chery wrote: > > > On Thu, Feb 02, 2017 at 12:53:33PM -0800, Jason Ekstrand wrote: > > > > On Thu,

Re: [Mesa-dev] [RFC PATCH] gallium: add a common uploader to pipe_context

On 02/01/2017 02:23 PM, Brian Paul wrote: On 01/27/2017 04:00 AM, Marek Olšák wrote: On Fri, Jan 27, 2017 at 10:05 AM, Nicolai Hähnle wrote: On 27.01.2017 00:51, Marek Olšák wrote: From: Marek Olšák For lower memory usage and more efficient updates

Re: [Mesa-dev] [PATCH 2/2] anv: Implement the Sky Lake stencil PMA optimization

On Thu, Feb 2, 2017 at 1:45 PM, Nanley Chery wrote: > On Thu, Feb 02, 2017 at 01:37:56PM -0800, Nanley Chery wrote: > > On Thu, Feb 02, 2017 at 12:53:33PM -0800, Jason Ekstrand wrote: > > > On Thu, Feb 2, 2017 at 10:55 AM, Nanley Chery > wrote: > >

Re: [Mesa-dev] [PATCH 2/3] loader: Add an environment variable to override driver name choice.

Emil Velikov writes: > On 3 February 2017 at 19:13, Eric Anholt wrote: >> My vc4 simulator has been implemented so far by having an entrypoint >> claiming to be i965, which was a bit gross. The simulator would be a lot >> less special if we entered

Re: [Mesa-dev] [PATCH] radeon/ac: move common llvm build functions to a separate file.

Thanks! Reviewed-by: Marek Olšák Marek On Fri, Feb 3, 2017 at 1:05 AM, Dave Airlie wrote: > From: Dave Airlie > > Suggested by Marek. > > Signed-off-by: Dave Airlie > --- > src/amd/Makefile.sources

Re: [Mesa-dev] [PATCH] configure.ac: describe what all the LIBDRM_*REQUIRED macros mean

On 2 February 2017 at 17:26, Kenneth Graunke wrote: > On Thursday, February 2, 2017 9:15:47 AM PST Chad Versace wrote: >> On Thu 02 Feb 2017, Emil Velikov wrote: >> > From: Emil Velikov >> > >> > They are versions of the respective libdrm

Re: [Mesa-dev] [PATCH] glsl: correct compute shader checks for memoryBarrier functions

On Fri, Feb 3, 2017 at 7:25 AM, Marc Di Luzio wrote: > As per the spec - > "The functions memoryBarrierShared() and groupMemoryBarrier() are > available only in compute shaders; the other functions are available > in all shader types." > > Conform to this by adding

Re: [Mesa-dev] [PATCH 1/3] ilo: EOL unplumb unmaintained gallium drv from winsys

Hi Edward, On 2 February 2017 at 08:15, Edward O'Callaghan wrote: > This is no longer actively maintained and is just > accumulating bitrot. > > Signed-off-by: Edward O'Callaghan > --- > .../auxiliary/pipe-loader/pipe_loader_drm.c

Re: [Mesa-dev] [PATCH 2/3] loader: Add an environment variable to override driver name choice.

On 3 February 2017 at 19:13, Eric Anholt wrote: > My vc4 simulator has been implemented so far by having an entrypoint > claiming to be i965, which was a bit gross. The simulator would be a lot > less special if we entered through the vc4 entrypoint like normal, so add > a

[Mesa-dev] [PATCH 1/3] targets: Use a macro to reduce cut and paste in driver setup.

All the replicated prototypes/function bodies obfuscated the interesting logic of the file: the mapping from driver enable macros to entrypoints we expose, and the way that the swrast entrypoints are special compared to the DRM entrypoints. --- src/gallium/targets/dri/target.c | 133

[Mesa-dev] [PATCH 3/3] targets: Remove vc4 simulator hack.

Now that there's MESA_LOADER_DRIVER_OVERRIDE for choosing the driver name we load, we don't need this any more. --- src/gallium/targets/dri/target.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/src/gallium/targets/dri/target.c b/src/gallium/targets/dri/target.c index

[Mesa-dev] [PATCH 2/3] loader: Add an environment variable to override driver name choice.

My vc4 simulator has been implemented so far by having an entrypoint claiming to be i965, which was a bit gross. The simulator would be a lot less special if we entered through the vc4 entrypoint like normal, so add a loader environment variable to allow the i965 fd to probe as vc4. ---

Re: [Mesa-dev] [PATCH] docs: replace URL in features.txt

On Friday, February 3, 2017 11:48:50 AM PST Brian Paul wrote: > Replace unmaintained http://dri.freedesktop.org/wiki/MissingFunctionality > URL with http://mesamatrix.net/ > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95460 > --- > docs/features.txt | 5 +++-- > 1 file changed, 3

[Mesa-dev] [PATCH] docs: replace URL in features.txt

Replace unmaintained http://dri.freedesktop.org/wiki/MissingFunctionality URL with http://mesamatrix.net/ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95460 --- docs/features.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/features.txt

Re: [Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

On Fri, Feb 3, 2017, at 19:24, Jason Ekstrand wrote: > On Fri, Feb 3, 2017 at 9:23 AM, Samuel Pitoiset > wrote: >> This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly >> for developers). But this one has the advantage to be configured >> for specific

Re: [Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

On Fri, Feb 3, 2017 at 9:23 AM, Samuel Pitoiset wrote: > This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly > for developers). But this one has the advantage to be configured > for specific apps which require a context with an explicit version. > > For

Re: [Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

On 02/03/2017 06:29 PM, Ilia Mirkin wrote: On Fri, Feb 3, 2017 at 12:23 PM, Samuel Pitoiset wrote: This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly for developers). But this one has the advantage to be configured for specific apps which require a

[Mesa-dev] [PATCH] swr: [rasterizer core] Removed unused clip code.

Removed unused Clip() and FRUSTUM_CLIP_MASK define. --- src/gallium/drivers/swr/rasterizer/core/clip.cpp | 22 -- src/gallium/drivers/swr/rasterizer/core/clip.h | 4 2 files changed, 26 deletions(-) diff --git a/src/gallium/drivers/swr/rasterizer/core/clip.cpp

Re: [Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

On Fri, Feb 3, 2017 at 12:23 PM, Samuel Pitoiset wrote: > This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly > for developers). But this one has the advantage to be configured > for specific apps which require a context with an explicit version. > > For

[Mesa-dev] [RFC PATCH 0/1] New driconf option for ARK games

Hi, This patch adds a new driconf option override_glsl_version for launching ARK games without the MESA_GLSL_VERSION_OVERRIDE hack which should be only for developers. This sounds redundant with force_glsl_version but that one is only for shaders that lack an explicit #version line. while this

[Mesa-dev] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly for developers). But this one has the advantage to be configured for specific apps which require a context with an explicit version. For example, when an app requires a 3.2 core context, RadeonSI will return a 4.5 context but this

Re: [Mesa-dev] [PATCH 5/5] travis: use both cores for make/make check

On Thu 02 Feb 2017, Emil Velikov wrote: > On 2 February 2017 at 01:27, Eric Anholt wrote: > > Emil Velikov writes: > > > >> From: Emil Velikov > >> > >> The instance offers 2 cores, so use them to speed things up. > >> > >>

Re: [Mesa-dev] [PATCH v2 2/2] anv: Implement the Sky Lake stencil PMA optimization

On Fri, Feb 3, 2017 at 5:37 PM, Jason Ekstrand wrote: > On Thu, Feb 2, 2017 at 11:18 PM, Ben Widawsky wrote: >> s/Sky Lake/Skylake/g > > > I can never figure out which it's supposed to be. The PRM says "Skylake" > but I thought ARC said "Sky Lake" but,

Re: [Mesa-dev] [PATCH 1/5] configure.ac: list all the dri-drivers in the help string

On Thu 02 Feb 2017, Andres Gomez wrote: > On Wed, 2017-02-01 at 22:30 +, Emil Velikov wrote: > > From: Emil Velikov > > > > It's unlikely that any of the additions come as a suprise to anyone > > i915, nouveau, radeon, r200). Regardless, state clearly what's >

Re: [Mesa-dev] [PATCH] mesa: Don't crash when destroying contexts created with no visual.

On Fri 03 Feb 2017, Samuel Iglesias Gonsálvez wrote: > Reviewed-by: Samuel Iglesias Gonsálvez > > On Thu, 2017-02-02 at 13:14 -0800, Kenneth Graunke wrote: > > dEQP-EGL.functional.create_context.no_config tries to create a > > context > > with no config, then immediately

Re: [Mesa-dev] [PATCH v2 2/2] anv: Implement the Sky Lake stencil PMA optimization

On Thu, Feb 2, 2017 at 11:18 PM, Ben Widawsky wrote: > On 17-02-02 13:27:05, Jason Ekstrand wrote: > >> This improves the performance of Dota 2 on my Sky Lake Skull Canyon >> machine by about 2-3%. >> >> Reviewed-by: Lionel Landwerlin >> --- >>

Re: [Mesa-dev] [PATCH] anv/pipeline: set ThreadDispatchEnable conditionally

On Friday, February 3, 2017 1:19:16 PM PST Juan A. Suarez Romero wrote: > Set 3DSTATE_WM/ThreadDispatchEnable bit on/off based on the same > conditions as used in the GL version. > > Signed-off-by: Juan A. Suarez Romero > --- > src/intel/vulkan/genX_pipeline.c | 49 >

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

On Fri, Feb 3, 2017 at 11:06 AM, Wladimir wrote: > Yes, but it seems suboptimal, incurring overhead on every rendered pixel. Why would this incur overhead? Can't the etnaviv-hardware perform swizzles for free? I'd assume you could just remap writes to gl_FragColor-compoents...

Re: [Mesa-dev] [PATCH 2/3] ilo: EOL drop unmaintained gallium drv from buildsys

On 2 February 2017 at 08:15, Edward O'Callaghan wrote: > AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes) > AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes) > @@ -2616,7 +2607,6 @@ AC_CONFIG_FILES([Makefile >

[Mesa-dev] [PATCH] glsl: correct compute shader checks for memoryBarrier functions

As per the spec - "The functions memoryBarrierShared() and groupMemoryBarrier() are available only in compute shaders; the other functions are available in all shader types." Conform to this by adding another delegate to check for compute shader support instead of only whether the current stage

Re: [Mesa-dev] [Mesa-stable] [PATCH v2 4/4] dri/common: clear the loaderPrivate pointer in driDestroyDrawable

Rb for the series. Posting from phone. Marek On Feb 2, 2017 6:20 PM, "Nicolai Hähnle" wrote: > From: Nicolai Hähnle > > The GLX specification says about glXDestroyPixmap: > > "The storage for the GLX pixmap will be freed when it is not current

Re: [Mesa-dev] [Freedreno] WebProcess crash on DB410c

Hmm, could be that westeros is doing something wrong that causes the pbuffer path to be hit. I'm not entirely sure why pbuffer is not supported in wayland (other than just that these days there are better ways to do things than pbuffer), although I thought I remembered seeing a fallback to

[Mesa-dev] [PATCH] anv/pipeline: set ThreadDispatchEnable conditionally

Set 3DSTATE_WM/ThreadDispatchEnable bit on/off based on the same conditions as used in the GL version. Signed-off-by: Juan A. Suarez Romero --- src/intel/vulkan/genX_pipeline.c | 49 +--- 1 file changed, 26 insertions(+), 23 deletions(-)

Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: call DrawBuffer(s) driver hook in update_framebuffer for windows-system FB

2017-02-02 7:58 GMT+08:00 Brian Paul : > This makes three places in the code where we call ctx->Driver.DrawBuffers() > or ctx->Driver.DrawBuffer() like this. I think some refactoring would be > good. > > Perhaps these calls can go into _mesa_drawbuffers(). I'll try to look

Re: [Mesa-dev] [PATCH 1/2] configure: libdrm is a single package, no split different versions

On 3 February 2017 at 01:41, Ilia Mirkin wrote: > On Wed, Feb 1, 2017 at 9:36 PM, Emil Velikov wrote: >> On 2 February 2017 at 02:33, Ilia Mirkin wrote: >>> The intent of the libdrm_driver version limits has always been to

Re: [Mesa-dev] [PATCH] configure: Only require libdrm 2.4.75 for intel.

On 2 February 2017 at 03:22, Dave Airlie wrote: > On 2 February 2017 at 13:09, Emil Velikov wrote: >> On 2 February 2017 at 02:58, Michel Dänzer wrote: >>> On 02/02/17 09:10 AM, Emil Velikov wrote: On 1 February 2017 at

Re: [Mesa-dev] [PATCH] configure.ac: explicitly require libdrm for dri classic drivers.

On 2 February 2017 at 20:12, Dave Airlie wrote: > We need both to be sure. > We need this regardless of 1/2. Thanks Dave. Reviewed-by: Emil Velikov -Emil ___ mesa-dev mailing list

Re: [Mesa-dev] [Mesa-stable] [PATCH v2 1/4] glx/dri3: handle NULL pointers in loader-to-DRI3 drawable conversion

On 2 February 2017 at 17:19, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > With a subsequent patch, we might see NULL loaderPrivates, e.g. when > a DRIdrawable is flushed whose corresponding GLXDRIdrawable was destroyed. > This resulted in a crash,

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

Hi Wladimir, 2017-02-03 11:06 GMT+01:00 Wladimir : > Yes, but it seems suboptimal, incurring overhead on every rendered pixel. > > Another way that I just realized would be to convert a texture to BGRA the > first time it's rendered to. > > In contrast to the shader solution

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

Hi Wladimir, this is about the userspace component of the driver, so dri-devel isn't the correct list for this question, you should instead CC the MESA dev list, even if mostly the same people hang out on those lists. Done that for you now. Regards, Lucas Am Freitag, den 03.02.2017, 10:56

[Mesa-dev] Fwd: Question about handling RGBA/BGRA in etnaviv driver

Sorry for getting the list wrong again. Please reply to mesa-dev not dri-dev . -- Forwarded message -- From: "Wladimir J. van der Laan" Date: Feb 3, 2017 10:56 Subject: Question about handling RGBA/BGRA in etnaviv driver To: ,

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

Yes, but it seems suboptimal, incurring overhead on every rendered pixel. Another way that I just realized would be to convert a texture to BGRA the first time it's rendered to. In contrast to the shader solution that has only a one-time overhead. Is this a stupid idea for any reason? Wladimir

Re: [Mesa-dev] [PATCH] radv/ac: correctly size shared memory usage.

Reviewed-by: Bas Nieuwenhuizen On Fri, Feb 3, 2017, at 04:30, Dave Airlie wrote: > From: Dave Airlie > > We count the number of slots used, but slots are vec4 sized, > so we have to scale by 16 not 4. > > Signed-off-by: Dave Airlie

Re: [Mesa-dev] [PATCH] radv: fix shared memory load/stores.

On Fri, Feb 3, 2017, at 06:33, Dave Airlie wrote: > On 3 February 2017 at 13:35, Dave Airlie wrote: > > From: Dave Airlie > > > > If we have an indirect index here we need to scale it by attribute slots > > e.g. is this is vec2[256] then we get an

Re: [Mesa-dev] [PATCH] radv: fix compute shared memory stores since 64-bit.

Reviewed-by: Bas Nieuwenhuizen On Fri, Feb 3, 2017, at 02:04, Dave Airlie wrote: > From: Dave Airlie > > These regressed and caused doom to stop loading. > > Fixes: > 03724af26 radv/ac: Implement Float64 load/store var. > > Signed-off-by: Dave