On Sat, Aug 5, 2017 at 11:39 AM, Chris Wilson wrote:
> Map the user format of GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE to the
> internal format of MESA_FORMAT_S_UINT8.
> ---
> src/mesa/main/glformats.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/main/glformats.c b/src/mesa/m
On 08/10/2017 05:27 AM, Michel Dänzer wrote:
On 09/08/17 04:07 PM, Thomas Hellstrom wrote:
On 08/09/2017 08:36 AM, Michel Dänzer wrote:
On 08/08/17 03:48 PM, Thomas Hellstrom wrote:
Implement back-to-fake-front flips, Fix EGL_BUFFER_PRESERVED
path. Implement dri3 support for GLX_SWAP_EXCHANGE_
On 10/08/17 02:25 PM, Thomas Hellstrom wrote:
> On 08/10/2017 05:20 AM, Michel Dänzer wrote:
>> On 09/08/17 06:53 PM, Thomas Hellstrom wrote:
>>> The attribMap had two entries for this attribute, and
>>> driGetConfigAttribIndex didn't return a proper value for this attribute.
>>> Fix this, and also
On 06/22/2017 02:08 AM, Eric Anholt wrote:
Tapani Pälli writes:
On 06/14/2017 01:12 AM, Eric Anholt wrote:
Tapani Pälli writes:
On 06/12/2017 09:52 AM, Tapani Pälli wrote:
On 05/18/2017 09:39 PM, Eric Anholt wrote:
Eric Anholt writes:
This series came out of fixing dEQP failures on
On Wed, 2017-08-09 at 16:18 +0100, Lionel Landwerlin wrote:
> Acked-by: Lionel Landwerlin
>
> I can see that it fixes the tests and it makes sense, but I'm failing
> to
> see how gl_attrib_wa_flags ends up being set from anv :/
Sorry, I should've explained that. It is not really anv but the sha
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #80 from Paviluf ---
It seem that will be "fixed" soon in chromium. They will disable compositing
for tooltips on Linux. I still hope that the root of the bug will be fixed in
mesa.
https://bugs.chromium.org/p/chromium/issues/detail?
dri2_fallback_swap_interval() currently used to stub out swap interval
support in Android backend does nothing besides returning EGL_FALSE.
This causes at least one known application (Android Snapchat) to fail
due to an unexpected error and my loose interpretation of the EGL 1.5
specification justi
On 08/10/2017 05:20 AM, Michel Dänzer wrote:
On 09/08/17 06:53 PM, Thomas Hellstrom wrote:
We shouldn't be using GLX tokens in the dri subsystem, so define dri
SWAP_METHOD tokens and translate when necessary. Unfortunately the X server
uses the dri swap method value untranslated as the GLX fbcon
On 08/10/2017 05:20 AM, Michel Dänzer wrote:
On 09/08/17 06:53 PM, Thomas Hellstrom wrote:
The attribMap had two entries for this attribute, and
driGetConfigAttribIndex didn't return a proper value for this attribute.
Fix this, and also make sure we return SWAP_UNDEFINED for single-buffer
config
On Fri, Aug 4, 2017 at 1:43 PM, Jan Vesely wrote:
> On Sun, 2017-07-30 at 20:26 -0500, Aaron Watry wrote:
>> Signed-off-by: Aaron Watry
>> CC: Jan Vesely
>>
>> v2: base it on the device version
>> ---
>> src/gallium/state_trackers/clover/llvm/invocation.cpp | 3 ++-
>> 1 file changed, 2 inserti
On 09/08/17 04:07 PM, Thomas Hellstrom wrote:
> On 08/09/2017 08:36 AM, Michel Dänzer wrote:
>> On 08/08/17 03:48 PM, Thomas Hellstrom wrote:
>>> Implement back-to-fake-front flips, Fix EGL_BUFFER_PRESERVED
>>> path. Implement dri3 support for GLX_SWAP_EXCHANGE_OML and
>>> GLX_SWAP_COPY_OML.
>>>
>
On 09/08/17 06:53 PM, Thomas Hellstrom wrote:
> We shouldn't be using GLX tokens in the dri subsystem, so define dri
> SWAP_METHOD tokens and translate when necessary. Unfortunately the X server
> uses the dri swap method value untranslated as the GLX fbconfig swapMethod,
> so we can't enumerate th
On 09/08/17 06:53 PM, Thomas Hellstrom wrote:
> The attribMap had two entries for this attribute, and
> driGetConfigAttribIndex didn't return a proper value for this attribute.
> Fix this, and also make sure we return SWAP_UNDEFINED for single-buffer
> configs as required by the GLX_OML_swap_method
On 10/08/17 05:34 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> UE4Editor has this issue.
>
> This commit prevents hangs (release build) or assertion failures (debug
> build).
>
> Cc: 17.2
Can't this go to 17.1, assuming there will be another 17.1 release? Anyway,
Reviewed-by: Michel Dänzer
On Tuesday, August 8, 2017 8:34:06 PM PDT Timothy Arceri wrote:
> f81ede469910d fixed a problem with shaders including IR that was
> owned by builtins. However the approach of cloning the whole
> function each time we referenced it lead to a significant
> reduction in the GLSL IR compiler performan
oof... Have you run this through Jenkins? It should be ok, but it will be
a functional change. It's a good change, but it is a change. Also, this
should probably get CCd to stable.
--Jason
On Wed, Aug 9, 2017 at 3:52 PM, Scott D Phillips wrote:
> intel_miptree_texture_aux_usage() takes an i
intel_miptree_texture_aux_usage() takes an isl_format, but we are
passing a mesa_format. clang warns:
brw_blorp.c:305:52: warning: implicit conversion from enumeration
type 'mesa_format' to different enumeration type
'enum isl_format' [-Wenum-conversion]
intel_miptree_texture_aux_u
CID: 1416243, 1416244, 1416255
CC: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/swr/rasterizer/core/api.cpp | 2 +-
src/gallium/drivers/swr/rasterizer/core/context.h | 8
src/gallium/drivers/swr/rasterizer/core/threads.cpp | 4 ++--
3 files changed, 7 insertions(+), 7 d
On Wed, Aug 9, 2017 at 3:19 PM, Marek Olšák wrote:
> You already know I can't accept the amdgpu part.
You don't agree with my explanation in the other patch?
> Anyway, I don't know if it's possible to keep the radeon part of the
> patch, because there is some shared code you would need to keep a
From: Marek Olšák
UE4Editor has this issue.
This commit prevents hangs (release build) or assertion failures (debug
build).
Cc: 17.2
---
src/amd/common/ac_binary.c | 12 ++--
src/amd/common/ac_binary.h | 2 +-
src/gallium/drivers/rade
On Tue, Aug 8, 2017 at 3:19 PM, Eric Anholt wrote:
> I've been trying to get away without these conditionals in vc4, but it
> meant compiling extra unused code on x86, and build failing on ARMv6.
> ---
> Android.common.mk | 8
> configure.ac | 24
> 2 files
On Tue, Aug 8, 2017 at 3:19 PM, Eric Anholt wrote:
> If you don't pass this, the compiler refuses to compile the assembly for
> pre-v7 CPUs. This also keeps us from building identical, non-NEON code on
> aarch64 and x86.
>
> Fixes: a373f77662c5 ("vc4: Use a wrapper file to set VC4_BUILD_NEON inst
On Wed, Aug 9, 2017 at 1:09 PM, Kenneth Graunke
wrote:
> Also, silence an obnoxious finishme that started occurring for all
> GL applications which use stencil after the i965 ISL conversion.
> ---
> src/intel/isl/isl.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git
You already know I can't accept the amdgpu part.
Anyway, I don't know if it's possible to keep the radeon part of the
patch, because there is some shared code you would need to keep as
well.
Marek
On Tue, Aug 8, 2017 at 12:58 AM, Rob Herring wrote:
> Use the common pipe_screen ref counting.
>
>
On Tue, Aug 8, 2017 at 12:58 AM, Rob Herring wrote:
> In order to prevent multiple pipe_screens being created in the same
> process, lookup of the DRM FD and reference counting of the pipe_screen
> are needed. Several implementations of this exist in various gallium
> drivers/winsys already. This
Reviewed-by: Marek Olšák
Marek
On Tue, Aug 8, 2017 at 12:58 AM, Rob Herring wrote:
> Use pipe_screen_unreference as it will call pipe_screen->destroy() when
> the pipe_screen is no longer referenced.
>
> Signed-off-by: Rob Herring
> ---
> src/gallium/drivers/ddebug/dd_screen.c | 3 ++-
> src/
OK. This patch is:
Reviewed-by: Marek Olšák
Marek
On Wed, Aug 9, 2017 at 9:53 PM, Rob Herring wrote:
> On Wed, Aug 9, 2017 at 2:18 PM, Marek Olšák wrote:
>> Hi Rob,
>>
>> This is not enough to do screen reference counting. There are primary
>> FDs and render node FDs, and we want to have only
Also, silence an obnoxious finishme that started occurring for all
GL applications which use stencil after the i965 ISL conversion.
---
src/intel/isl/isl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 6b4203d79d2..c351162
On Wed, Aug 9, 2017 at 2:18 PM, Marek Olšák wrote:
> Hi Rob,
>
> This is not enough to do screen reference counting. There are primary
> FDs and render node FDs, and we want to have only one pipe_screen for
> all kinds of FDs pointing to the same device.
>
> Imagine someone creates a pipe_screen w
Hi Rob,
This is not enough to do screen reference counting. There are primary
FDs and render node FDs, and we want to have only one pipe_screen for
all kinds of FDs pointing to the same device.
Imagine someone creates a pipe_screen with a render node FD, and then
creates another pipe_screen with
With Nicolai's comment addressed, patches 1-2 are:
Reviewed-by: Marek Olšák
Marek
On Wed, Aug 9, 2017 at 6:47 PM, Nicolai Hähnle wrote:
> On 08.08.2017 00:58, Rob Herring wrote:
>>
>> In preparation to add reference counting of pipe_screen in the
>> pipe-loader,
>> pipe_loader_release needs to
Matt Turner writes:
> On Tue, Aug 8, 2017 at 4:25 PM, Scott D Phillips
> wrote:
>>> + [BRW_HW_IMM_TYPE_UV] = 2,
>>> + [BRW_HW_IMM_TYPE_VF] = 4,
>>> + [BRW_HW_IMM_TYPE_V] = 2,
>>
>> Is this right? I see it was there before, and perhaps I'm being dense,
>> but it seems
spirv_info.c existed as a static file until commit 2dd4e2ece32f began
generating it as part of the build process. autotools is incapable of
coping, and so a build-tree from before this commit would then fail with
it:
[4]: *** No rule to make target
'../../../mesa/src/compiler/spirv/spirv_info.c',
On Tue, Aug 8, 2017 at 4:25 PM, Scott D Phillips
wrote:
>> + [BRW_HW_IMM_TYPE_UV] = 2,
>> + [BRW_HW_IMM_TYPE_VF] = 4,
>> + [BRW_HW_IMM_TYPE_V] = 2,
>
> Is this right? I see it was there before, and perhaps I'm being dense,
> but it seems like V and UV should be size 4 f
We need to link librt for u_thread.h's clock_gettime() call.
Fixes: b822d9dd67b5 ("gallium/util: move u_queue.{c,h} to src/util")
---
src/util/Makefile.am | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index a8352a9053e3..4512dc9
I've been trying to get away without these conditionals in vc4, but it
meant compiling extra unused code on x86, and build failing on ARMv6.
---
Android.common.mk | 8
configure.ac | 24
2 files changed, 32 insertions(+)
diff --git a/Android.common.mk b/And
I was trying to build Mesa with NEON support for Raspbian wheezy
(gross), and found a couple of easy fixes. I'm hoping for an ack here
on configure.ac/DEFINES changes and an Android test.
Branch available at:
https://github.com/anholt/mesa/commits/vc4-neon
Eric Anholt (5):
broadcom: Add missi
---
src/broadcom/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/broadcom/.gitignore b/src/broadcom/.gitignore
index fcc603f0cf01..5442872127e1 100644
--- a/src/broadcom/.gitignore
+++ b/src/broadcom/.gitignore
@@ -1 +1,2 @@
+cle/v3d_xml.h
cle/*_pack.h
--
2.13.3
_
From: Maxim Maslov
Mesa vc4 drivers can be built for x86 in order to run hw accelerated
graphics inside virtual machines (QEMU, Exagear) on Raspberry Pi.
Improves playing intro videos on Diablo II inside Exagear to take 11% of
CPU instead of 20%.
v2: Runtime CPU detection by Maxim
v3: Fix up cr
If you don't pass this, the compiler refuses to compile the assembly for
pre-v7 CPUs. This also keeps us from building identical, non-NEON code on
aarch64 and x86.
Fixes: a373f77662c5 ("vc4: Use a wrapper file to set VC4_BUILD_NEON instead of
CFLAGS.")
---
src/gallium/drivers/vc4/Android.mk
From: Jonas Pfeil
Changed all register and instruction names, works the same.
v2: Rebase on build system changes (by anholt)
Signed-off-by: Jonas Pfeil
---
src/gallium/drivers/vc4/vc4_tiling_lt.c | 84 +
1 file changed, 84 insertions(+)
diff --git a/src/galliu
The Raspbian ARMv6 cross compiler wasn't picking up my (amd64) system copy
of the header the way that the system gcc and armhf cross-compile did.
---
src/broadcom/Makefile.am | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/broadcom/Makefile.am b/src/broadcom/Makefile.am
index cbcd970ecb
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #48 from Marko ---
It's working!
Today's pull + https://patchwork.freedesktop.org/series/28535/ + kernel
4.13-rc4.
Doom and Dota2 both work with no freezing. I'll test (read-play) some more
later but this finally seems to have fixe
On 08.08.2017 00:58, Rob Herring wrote:
In preparation to add reference counting of pipe_screen in the pipe-loader,
pipe_loader_release needs to destroy the pipe_screen instead of state
trackers.
Did you miss Nine?
Cheers,
Nicolai
Signed-off-by: Rob Herring
Cc: Emil Velikov
---
src/gall
On 08.08.2017 18:57, Samuel Pitoiset wrote:
Will be used for allocating bindless descriptor slots for
RadeonSI.
Signed-off-by: Samuel Pitoiset
---
src/gallium/auxiliary/Makefile.sources | 1 +
src/gallium/auxiliary/util/u_idalloc.h | 103 +
2 files changed,
https://bugs.freedesktop.org/show_bug.cgi?id=102123
--- Comment #1 from Roland Scheidegger ---
If that's only softpipe/llvmpipe regressing, it is most likely due to only
having fake msaa support.
I'm a bit surprised the test result changed, but I suppose the test previously
actually used a msaa t
On 08/09/2017 12:30 PM, Eric Engestrom wrote:
On Wednesday, 2017-08-09 08:35:04 +0300, Tapani Pälli wrote:
On 08/08/2017 08:07 PM, Emil Velikov wrote:
On 8 August 2017 at 16:10, Eric Engestrom wrote:
On Saturday, 2017-08-05 00:25:49 +0100, Emil Velikov wrote:
From: Emil Velikov
As mentione
Acked-by: Lionel Landwerlin
I can see that it fixes the tests and it makes sense, but I'm failing to
see how gl_attrib_wa_flags ends up being set from anv :/
Thanks a lot!
On 21/07/17 09:26, Iago Toral Quiroga wrote:
Mesa will map user defined vertex input attributes to slots
starting at VE
Hi Thomas,
The series looks good to me. One formatting nit: in one of the patches
there's unneeded space around the conditional in some the "if (" code.
Reviewed-by: Brian Paul
On Wed, Aug 9, 2017 at 3:53 AM, Thomas Hellstrom
wrote:
> The current implementation was suffering from the follow
https://bugs.freedesktop.org/show_bug.cgi?id=102030
Jan Vesely changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--
You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=102030
Janpieter Sollie changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
Only resident bindless descriptors are currently updated and
re-uploaded, this makes sure that the non-resident ones are
also updated.
Signed-off-by: Samuel Pitoiset
Cc: "17.2"
---
src/gallium/drivers/radeonsi/si_descriptors.c | 85 +--
1 file changed, 55 insertions(+),
On 08.08.2017 19:07, Rob Herring wrote:
On Tue, Aug 8, 2017 at 11:56 AM, Ilia Mirkin wrote:
On Tue, Aug 8, 2017 at 12:50 PM, Rob Herring wrote:
Commit e794f8bf8bdb ("gallium: move loading of drirc to pipe-loader")
moved the option cache to the pipe_loader_device. However, the
screen->dev poin
Thanks, Timothy. I'm going to make a respin that relaxes the rules only
in desktop GL for now, and I guess we should separately raise this with
the GLES WG.
Cheers,
Nicolai
On 09.08.2017 02:30, Timothy Arceri wrote:
Hi Nicolai,
I put this series through Intels CI system and it hit a couple
Hi Dave,
Thanks for the update, I prefer this.
Have you considered Marek's query about pipeline-wide atomic buffers?
The issue I'm thinking about is what happens when multiple shaders
access the same atomic counter. In a GDS/GWS-based implementation, those
accesses must map to the same hardwa
On 04.08.2017 09:25, Timothy Arceri wrote:
The cloning was introduced in f81ede469910d to fixed a problem with
*to fix
shaders including IR that was owned by builtins.
However the approach of cloning the whole function each time we
reference a builtin lead to a significant reduction in the G
On 04.08.2017 09:25, Timothy Arceri wrote:
f81ede469910d fixed a problem with shaders including IR that was
owned by builtins. However the approach of cloning the whole
function each time we referenced it lead to a significant
reduction in the GLSL IR compiler performance.
Everything was already
On 8 August 2017 at 09:48, Tapani Pälli wrote:
> On 08/08/2017 10:37 AM, Philipp Zabel wrote:
>> On Tue, 2017-08-08 at 07:29 +0300, Tapani Pälli wrote:
Since this increments plane_n, Should a check be added that the
corresponding DMABufPlanFds[i] is present?
>>>
>>> Check for the fd is r
When using dmabuf import, make sure that the modifier is actually
allowed to add planes to the base format, as implied by the comment.
Signed-off-by: Daniel Stone
---
src/egl/drivers/dri2/egl_dri2.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
d
Due to bugs in dri swap method reporting, neither the fbconfigs received from
the server nor the value reported from driconfigs were correct. Now that's been
fixed and we can enable config swapmethod matching again.
Signed-off-by: Thomas Hellstrom
---
src/glx/dri_common.c | 4 +---
1 file change
We shouldn't be using GLX tokens in the dri subsystem, so define dri
SWAP_METHOD tokens and translate when necessary. Unfortunately the X server
uses the dri swap method value untranslated as the GLX fbconfig swapMethod,
so we can't enumerate these tokens arbitrarily, but rather need to make them
h
The current implementation was suffering from the following problems:
1) The driGetConfigAttribIndex function was not returning any value for
the driconfig swapMethod.
2) The X server GLX code is using the value obtained from
the AIGLX dri driver driGetConfigAttribIndex to populate its GLX fbconfig
Due to the recently fixed bug where dri drivers didn't report a correct
__DRI_ATTRIB_SWAP_METHOD value, and the fact that X servers just forward this
incorrect value (from the AIGLX dri driver) untranslated as
GLX_SWAP_METHOD_OML, the latter value might be undefined when old dri AIGLX
values are us
The attribMap had two entries for this attribute, and
driGetConfigAttribIndex didn't return a proper value for this attribute.
Fix this, and also make sure we return SWAP_UNDEFINED for single-buffer
configs as required by the GLX_OML_swap_method spec.
Finally bump the dri core extension version to
This is a nice stopgap until I get the time to finish the
stringbuffer tests and get that stuff merged. I think it should
get us most of the way there, which your numbers suggest.
Patch 7 and patch 8 are:
Reviewed-by: Thomas Helland
2017-08-09 5:34 GMT+02:00 Timothy Arceri :
> The Deus Ex: Mankin
On Wednesday, 2017-08-09 08:35:04 +0300, Tapani Pälli wrote:
> On 08/08/2017 08:07 PM, Emil Velikov wrote:
> > On 8 August 2017 at 16:10, Eric Engestrom wrote:
> > > On Saturday, 2017-08-05 00:25:49 +0100, Emil Velikov wrote:
> > > > From: Emil Velikov
> > > >
> > > > As mentioned in previous co
We treat out free list as a rough LRU, at the tail we have active
buffers to be allocated for rendering, and at the head we have the
older, inactive buffers that we can allocate for use by the CPU.
At the time of freeing, we can inspect the busyness of the buffer to
decide if we should place it at
Yeah, _eglLookupDisplay seems to return NULL indeed in this case;
Reviewed-by: Tapani Pälli
On 08/08/2017 05:55 PM, Emil Velikov wrote:
From: Emil Velikov
If we have an invalid display fed into the functions, the display lookup
will return NULL. Thus as we attempt to get the platform type,
On Tuesday, 2017-08-08 15:55:36 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> If we have an invalid display fed into the functions, the display lookup
> will return NULL. Thus as we attempt to get the platform type, we'll
> deref. it leading to a crash.
>
> Keep in mind that this will not
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #47 from Marko ---
That's great news then!
I'm compiling as we speak on Suse OBS, but will able to try it out only this
afternoon after I get home from work.
Cheers,
Marko
--
You are receiving this mail because:
You are the QA Co
On Tue, 2017-08-08 at 12:12 -0700, Jordan Justen wrote:
> On 2017-08-06 21:18:23, Iago Toral Quiroga wrote:
> > The OpenGL 4.6 specs have been updated so that GetTextureParameter*
> > with a texture object with an incompatible TEXTURE_TARGET should
> > now
> > report INVALID_OPERATION instead of IN
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #46 from John ---
This patch only on master worked!
Congratulations Dave, this is the first time I've passed the whole benchmark!
I'll try a few other applications and wait on Marko's test before closing this,
but so far it looks g
I thought I sent out a reply to this yesterday. Apparently I was too
tired to remember... I was thinking a helper function to acquire the
name would be nice, but there is not that many uses, so we probably
should not bother. This patch is:
Reviewed-by: Thomas Helland
2017-08-09 5:34 GMT+02:00 Tim
Hi, Michel,
On 08/09/2017 08:36 AM, Michel Dänzer wrote:
Hi Thomas,
first of all, would it be possible to split these patches up a bit
further? At least patch 1 seems to contain several logical changes,
which makes it a bit difficult to review.
OK. I'll try to do that.
On 08/08/17 03:48
74 matches
Mail list logo
