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 APIs.
Avoid leak af
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 (Daniel)
Move bo->image ch
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 the assignee for th
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
>> mailto:samuel.pitoi...@gmail.com>> wrote:
>>
>> This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly
>> for develope
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
> on that method
>
> It w
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
https://bugs.freedesktop.org/show_bug.cgi?id=98263
Rene Lindsay changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
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 wrote:
>
>
> From: Marek Olšák
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, Feb 2, 2017 at 10:55 AM,
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 of the buffer
residency
list. (e.g. if dr
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:
> > >
> > > > On Wed, Feb 01, 2017 at 10:11:42PM -0
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 through the vc4 entrypoint like normal, so add
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 | 2 +
> src/amd/common/ac_llvm_build.c| 752
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 package. They are _not_ the
>> > version of libdrm[.so] re
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 another delegate to check for co
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| 5 ---
> src/gallium/auxiliary/target-helpers/drm_help
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 loader environment vari
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 +++---
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 df93c94ea832
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.
---
src/loade
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 ins
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 b/docs/features.t
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 apps which require a context
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 example, when an app requires
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 context with an explicit versi
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
b/src/g
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 example, when an app requires
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 on
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 mi
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.
> >>
> >> Signed-off-by: Emil Velikov
> >
> > They don't just set MAKEFLAGS in th
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, now that I look, it says "Skylake"
> too.
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
> Opening parenthesis? ^
>
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 destroys it. The drawbu
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
>> ---
>> src/intel/vulkan/anv_private.h | 1 +
>> src/i
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
> +--
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...
>
> Another way th
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
> src/gallium/drivers/freedreno/Makefile
>
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 is
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
> to any client."
>
> We're not really fo
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 surface
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(-)
diff --git a/src/inte
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 into
> that in a few da
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 not
>>> burden the "other" drivers with updating their libdrm unless real
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 23:28, Vinson Lee wrote:
> Fixes: b8acb6b17981 ("configure: Requir
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
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/li
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, since the loader vs. DRI3 drawable structures
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 that has only a one-ti
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 +01
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: ,
Cc: "Chris Healy"
Hello,
With the Etnaviv driver w
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
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
> ---
> src/amd/common/ac_nir_to_llvm.c | 2 +-
> 1 file cha
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 indir_index in the 0.255 range
> > but the vec2
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 Airlie
> ---
> src/amd/common/ac_nir_to_llvm.c
53 matches
Mail list logo
