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
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
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
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
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
>
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
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
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,
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
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:
> >
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
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
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
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
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
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
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
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.
---
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
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
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
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
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
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
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
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
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
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.
> >>
> >>
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,
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
>
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
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
>> ---
>>
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...
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
>
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
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
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
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(-)
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
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
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
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
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,
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
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
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: ,
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
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
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
53 matches
Mail list logo