https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #28 from John ---
That seems to work indeed!
Thank you!
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing
On Monday, March 20, 2017 9:23:55 PM PDT Jonathan Gray wrote:
> On Mon, Mar 20, 2017 at 04:05:04PM -0700, Kenneth Graunke wrote:
> > Recent glibc generates this warning:
> >
> > brw_performance_query.c:1648:13: warning: In the GNU C Library, "minor" is
> > defined
> > by . For historical compati
Recent glibc generates this warning:
brw_performance_query.c:1648:13: warning: In the GNU C Library, "minor" is
defined
by . For historical compatibility, it is
currently defined by as well, but we plan to
remove this soon. To use "minor", include
directly. If you did not intend to use a sy
Yes, this can be removed;
Reviewed-by: Tapani Pälli
On 03/20/2017 05:18 PM, Emil Velikov wrote:
From: Emil Velikov
Spotted while skimming through similar hunks for the Autotools build.
Cc: Tapani Pälli
Signed-off-by: Emil Velikov
---
Tapani, can you throw this on the back-burner - I'm 99%
Original naming was following Vulkan HAL naming scheme for no good
purpose and we need same binary name for build-id code.
Signed-off-by: Tapani Pälli
---
src/intel/Android.vulkan.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/Android.vulkan.mk b/src/intel/A
On Sun, 2017-03-12 at 16:34 +1100, Timothy Arceri wrote:
>
> On 12/03/17 12:17, Andres Gomez wrote:
> > On Sun, 2017-03-12 at 10:07 +1100, Timothy Arceri wrote:
> > >
> > > On 12/03/17 00:29, Andres Gomez wrote:
> > > > On Sat, 2017-03-11 at 23:24 +1100, Timothy Arceri wrote:
> > > > >
> > > > >
we anyway allow for multiple slices
v2: do not remove assert to check for buf->size
Signed-off-by: Nayan Deshmukh
Reviewed-by: Christian König
---
src/gallium/state_trackers/va/picture_mpeg12.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/va/pi
On 21.03.2017 06:14, Timothy Arceri wrote:
From: Grazvydas Ignotas
Instead of using a directory, hash the timestamps into the cache keys
themselves. Since there is no more timestamp directory, there is no more
need for deleting the cache of other mesa versions and we rely on
eviction to clean u
On 21.03.2017 06:14, Timothy Arceri wrote:
From: Grazvydas Ignotas
This allows to get rid of the arch and gpu name directories.
v2: (Timothy Arceri) don't use an opaque data type to store
pointer size and gpu name.
Signed-off-by: Grazvydas Ignotas
---
src/compiler/glsl/tests/cache_test.
On 21.03.2017 06:14, Timothy Arceri wrote:
This can be used to deal with key hash collisions from different
versions (should we find that to actually happen) and to find
which mesa version produced the cache entry.
---
I considered creating the cache key blob at cache creation time but since
w
On 20.03.2017 23:43, Marek Olšák wrote:
From: Marek Olšák
Both GFX6 and GFX9 fields are printed next to each other in parsed IBs.
The Python script parses both headers like one stream and tries to merge
all definitions.
---
src/amd/Makefile.common.am | 4 +--
src/amd/common/ac_d
Otherwise for apps that don't seed the regular rand() we will always
remove old cache entries from the same dirs.
---
src/util/disk_cache.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index f2d67c9..f6ecf0b 100644
--- a
---
src/gallium/drivers/radeon/r600_test_dma.c | 20 +
src/util/Makefile.sources | 2 ++
src/util/rand_xor.c| 21 ++
src/util/rand_xor.h| 35 ++
4 files changed, 59 inserti
---
src/gallium/drivers/radeon/r600_test_dma.c | 3 +-
src/util/rand_xor.c| 62 --
src/util/rand_xor.h| 6 ++-
3 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_test_dma.c
b
On 20.03.2017 23:43, Marek Olšák wrote:
From: Marek Olšák
Add _GFX6 and _GFX9 suffixes to conflicting definitions.
sid.h and gfx9d.h can now be included in the same file.
Are you compile-testing radv? I suspect that this breaks the build
there. Similarly for patches #64 and #66. Best to fix
Recent change to use drmGetDevices2() made me realize that
build configured using
PKG_CONFIG_PATH=my_drm_lib_path/pkgconfig ./autogen.sh
considers the libdrm path gotten from pkgconfig only during
make. When invoking "make install" the relink command puts
system library ahead of the path gotten f
On 20.03.2017 23:48, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/winsys/amdgpu/drm/amdgpu_surface.c | 47 --
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_surface.c
b/src/gallium/winsys/amdgpu/drm/amdgpu_s
On 21/03/17 19:25, Nicolai Hähnle wrote:
On 21.03.2017 06:14, Timothy Arceri wrote:
From: Grazvydas Ignotas
This allows to get rid of the arch and gpu name directories.
v2: (Timothy Arceri) don't use an opaque data type to store
pointer size and gpu name.
Signed-off-by: Grazvydas Ignot
On Mon, Mar 20, 2017 at 11:03:48PM +0200, Grazvydas Ignotas wrote:
> On Mon, Mar 20, 2017 at 9:43 PM, Pohjolainen, Topi
> wrote:
> > On Mon, Mar 20, 2017 at 04:45:22PM +, Emil Velikov wrote:
> >> On 20 March 2017 at 10:27, Grazvydas Ignotas wrote:
> >> > On Mon, Mar 20, 2017 at 11:28 AM, Topi
On 20.03.2017 23:42, Marek Olšák wrote:
Hi,
This is initial Vega10 support for radeonsi. It supports everything
except geometry shaders and tessellation, so it's limited to GL 3.1.
The missing features are under way.
There is also UVD and VCE support.
The first 57 patches only update addrlib.
On 21.03.2017 10:22, Timothy Arceri wrote:
On 21/03/17 19:25, Nicolai Hähnle wrote:
On 21.03.2017 06:14, Timothy Arceri wrote:
From: Grazvydas Ignotas
This allows to get rid of the arch and gpu name directories.
v2: (Timothy Arceri) don't use an opaque data type to store
pointer size a
Thanks, but this is now not thread-safe. I'm not sure how much we should
care about that, but anyway, as I see it there are three options:
1) Add some kind of locking.
2) Make the caller provide a struct for the state (similar to rand_r).
3) Ignore the issue and add a fat warning comment about i
On 21.03.2017 09:57, Timothy Arceri wrote:
Otherwise for apps that don't seed the regular rand() we will always
remove old cache entries from the same dirs.
---
src/util/disk_cache.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/util/disk_cache.c b/src/util/dis
On 21/03/17 21:01, Nicolai Hähnle wrote:
On 21.03.2017 10:22, Timothy Arceri wrote:
On 21/03/17 19:25, Nicolai Hähnle wrote:
On 21.03.2017 06:14, Timothy Arceri wrote:
From: Grazvydas Ignotas
This allows to get rid of the arch and gpu name directories.
v2: (Timothy Arceri) don't use an
On 21/03/17 21:07, Nicolai Hähnle wrote:
Thanks, but this is now not thread-safe. I'm not sure how much we should
care about that, but anyway, as I see it there are three options:
1) Add some kind of locking.
2) Make the caller provide a struct for the state (similar to rand_r).
3) Ignore the
On 21 March 2017 at 09:09, Topi Pohjolainen wrote:
> Recent change to use drmGetDevices2() made me realize that
> build configured using
>
> PKG_CONFIG_PATH=my_drm_lib_path/pkgconfig ./autogen.sh
>
> considers the libdrm path gotten from pkgconfig only during
> make. When invoking "make install" t
On 21 March 2017 at 07:20, Kenneth Graunke wrote:
> Recent glibc generates this warning:
>
> brw_performance_query.c:1648:13: warning: In the GNU C Library, "minor" is
> defined
> by . For historical compatibility, it is
> currently defined by as well, but we plan to
> remove this soon. To us
On 21/03/17 21:10, Nicolai Hähnle wrote:
On 21.03.2017 09:57, Timothy Arceri wrote:
Otherwise for apps that don't seed the regular rand() we will always
remove old cache entries from the same dirs.
---
src/util/disk_cache.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff
On 20 March 2017 at 22:36, Rob Herring wrote:
> On Mon, Mar 20, 2017 at 11:03 AM, Emil Velikov
> wrote:
>> On 20 March 2017 at 01:33, Rob Herring wrote:
>>> Any users of KitKat are likely using an older version of Mesa and
>>> KitKat support adds complexity to the make files. Dropping support
>
On 21.03.2017 11:23, Timothy Arceri wrote:
On 21/03/17 21:01, Nicolai Hähnle wrote:
On 21.03.2017 10:22, Timothy Arceri wrote:
On 21/03/17 19:25, Nicolai Hähnle wrote:
On 21.03.2017 06:14, Timothy Arceri wrote:
void
disk_cache_compute_key(struct disk_cache *cache, const void *data,
size
On 20 March 2017 at 22:04, Kenneth Graunke wrote:
> This way they become part of libintel_common.la so I can use them in
> the i965 driver.
> ---
> src/intel/Makefile.sources | 2 ++
> src/intel/Makefile.tools.am | 2 --
> src/intel/{tools/decoder.
On 21/03/17 21:50, Timothy Arceri wrote:
On 21/03/17 21:10, Nicolai Hähnle wrote:
On 21.03.2017 09:57, Timothy Arceri wrote:
Otherwise for apps that don't seed the regular rand() we will always
remove old cache entries from the same dirs.
---
src/util/disk_cache.c | 9 +++--
1 file cha
On 21.03.2017 11:50, Timothy Arceri wrote:
On 21/03/17 21:10, Nicolai Hähnle wrote:
On 21.03.2017 09:57, Timothy Arceri wrote:
Otherwise for apps that don't seed the regular rand() we will always
remove old cache entries from the same dirs.
---
src/util/disk_cache.c | 9 +++--
1 file cha
On 21.03.2017 12:16, Timothy Arceri wrote:
On 21/03/17 21:50, Timothy Arceri wrote:
On 21/03/17 21:10, Nicolai Hähnle wrote:
On 21.03.2017 09:57, Timothy Arceri wrote:
Otherwise for apps that don't seed the regular rand() we will always
remove old cache entries from the same dirs.
---
src
On 21/03/17 22:16, Timothy Arceri wrote:
On 21/03/17 21:50, Timothy Arceri wrote:
On 21/03/17 21:10, Nicolai Hähnle wrote:
On 21.03.2017 09:57, Timothy Arceri wrote:
Otherwise for apps that don't seed the regular rand() we will always
remove old cache entries from the same dirs.
---
src
On Mon, Mar 20, 2017 at 02:13:09AM -0700, Kenneth Graunke wrote:
> Hello,
>
> This series makes INTEL_DEBUG=bat use the aubinator/genxml infrastructure
> for decoding batches (both commands and states). It's not perfect, but
> it should be significantly more usable than the old code. Our public
On 21 March 2017 at 11:14, Emil Velikov wrote:
> On 20 March 2017 at 22:04, Kenneth Graunke wrote:
>> This way they become part of libintel_common.la so I can use them in
>> the i965 driver.
>> ---
>> src/intel/Makefile.sources | 2 ++
>> src/intel/Makefile.tools.am
On Monday, 2017-03-20 09:33:50 -0300, Fabio Estevam wrote:
> Do not declare counter inside 'for' loop to fix the following build errors
> on mips64el:
>
> cube-tex.c: In function 'get_fd_rgba':
> cube-tex.c:230:2: error: 'for' loop initial declarations are only allowed in
> C99 mode
> for (uint
On Monday, 2017-03-20 12:49:07 -0300, Fabio Estevam wrote:
> Include to fix the following build error seen on mips64el:
>
> drm-legacy.c: In function 'legacy_run':
> drm-legacy.c:45:2: error: unknown type name 'fd_set'
> fd_set fds;
> ^
> drm-legacy.c:55:2: warning: implicit declaration of fu
On 20 March 2017 at 21:51, Jason Ekstrand wrote:
> On Mon, Mar 20, 2017 at 8:18 AM, Emil Velikov
> wrote:
>>
>> From: Emil Velikov
>>
>> At the moment, we would honour any system headers - vulkan_intel.h in
>> particular over the ones in-tree.
>>
>> Thus, if one does inclemental build of mesa, w
On Tue, Mar 21, 2017 at 12:33 PM, Emil Velikov wrote:
> On 21 March 2017 at 09:09, Topi Pohjolainen
> wrote:
>> Recent change to use drmGetDevices2() made me realize that
>> build configured using
>>
>> PKG_CONFIG_PATH=my_drm_lib_path/pkgconfig ./autogen.sh
>>
>> considers the libdrm path gotten
On 03/21/2017 01:40 PM, Emil Velikov wrote:
On 21 March 2017 at 11:14, Emil Velikov wrote:
On 20 March 2017 at 22:04, Kenneth Graunke wrote:
This way they become part of libintel_common.la so I can use them in
the i965 driver.
---
src/intel/Makefile.sources | 2 ++
Hi Eric,
On Tue, Mar 21, 2017 at 9:01 AM, Eric Engestrom
wrote:
> I think I'd prefer not going backwards. Does your compiler support C99?
> If so, I'd suggest using it explicitly by adding -std=c99 to the CFLAGS
> in Makefile.am.
Yes, that works too. Just sent a patch adding -std=c99.
Thanks
_
On Tue, Mar 21, 2017 at 9:57 AM, Timothy Arceri wrote:
> ---
> src/gallium/drivers/radeon/r600_test_dma.c | 20 +
> src/util/Makefile.sources | 2 ++
> src/util/rand_xor.c| 21 ++
> src/util/rand_xor.h
This was found by accident, and looks like it slipped in when the whole
file was added.
---
src/intel/compiler/brw_eu_validate.c | 12
1 file changed, 12 deletions(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index 64615af44ac..3655dde5
BTW, These patches didn't make it to the list, and they are not going
to make it:
[PATCH 011/140] amdgpu/addrlib: rearrange code in preparation of refactoring
[PATCH 032/140] amdgpu/addrlib: Adjust 99 "*" to 100 "*" alignment
[PATCH 033/140] amdgpu/addrlib: Use namespaces
[PATCH 058/140] amd/addrl
On 03/20/2017 05:12 PM, Emil Velikov wrote:
> Hi all,
>
> We have a strange mix of pragma once vs ifndef guards in-tree.
>
> Since the former is less common, and concluded as the 'wrong' way,
> I've went ahead and purged them. As a since side effect I also fixed
> all the headers in the respectiv
On Tue, Mar 21, 2017 at 7:49 AM, Christian König
wrote:
> Am 20.03.2017 um 23:49 schrieb Marek Olšák:
>>
>> From: Leo Liu
>>
>> Signed-off-by: Leo Liu
>> Acked-by: Alex Deucher
>
>
> Did we ever released 53.14.4? My last status was the firmware on release
> should be 53.17 or something like tha
On Tuesday, 2017-03-21 10:04:13 -0300, Fabio Estevam wrote:
> Currently the following build errors are seen on mips64el:
>
> cube-tex.c: In function 'get_fd_rgba':
> cube-tex.c:230:2: error: 'for' loop initial declarations are only allowed in
> C99 mode
> for (uint32_t i = 0; i < texh; i++) {
>
On Tue, Mar 21, 2017 at 9:46 AM, Marek Olšák wrote:
> On Tue, Mar 21, 2017 at 7:49 AM, Christian König
> wrote:
>> Am 20.03.2017 um 23:49 schrieb Marek Olšák:
>>>
>>> From: Leo Liu
>>>
>>> Signed-off-by: Leo Liu
>>> Acked-by: Alex Deucher
>>
>>
>> Did we ever released 53.14.4? My last status w
On Tue, Mar 21, 2017 at 10:11 AM, Nicolai Hähnle wrote:
> On 20.03.2017 23:48, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> ---
>> src/gallium/winsys/amdgpu/drm/amdgpu_surface.c | 47
>> --
>> 1 file changed, 30 insertions(+), 17 deletions(-)
>>
>> diff --git a/src/ga
On Thu, 16 Mar 2017, Dylan Baker wrote:
> First it's written in python, [...]
How does meson handle python 2 vs. 3? How do you avoid issues in the
build files wrt this? On Debian meson seems to depend on python 3, so
are they fully python 3?
How does meson handle build file backwards compatibili
On Mon, Mar 20, 2017 at 4:03 PM, Grazvydas Ignotas
wrote:
> On Mon, Mar 20, 2017 at 9:43 PM, Pohjolainen, Topi
> wrote:
> > On Mon, Mar 20, 2017 at 04:45:22PM +, Emil Velikov wrote:
> >> On 20 March 2017 at 10:27, Grazvydas Ignotas wrote:
> >> > On Mon, Mar 20, 2017 at 11:28 AM, Topi Pohjol
On Mon, Mar 20, 2017 at 8:35 PM, Ben Widawsky wrote:
> This patch begins introducing how we'll actually handle the potentially
> many modifiers coming in from the API, how we'll store them, and the
> structure in the code to support it.
>
> Prior to this patch, the Y-tiled modifier would be entir
Input attachments are clear-color aware on Sky Lake, so we
can frequently sample from them with no resolves at all. However
on Broadwell we still need to do a a resolve between the subpass
that writes and the subpass that reads.
Fixes 16 tests on BDW:
dEQP-VK.renderpass.formats.*.input.clear.stor
On Tue, Mar 21, 2017 at 8:04 AM, Jason Ekstrand
wrote:
> On Mon, Mar 20, 2017 at 8:35 PM, Ben Widawsky wrote:
>
>> This patch begins introducing how we'll actually handle the potentially
>> many modifiers coming in from the API, how we'll store them, and the
>> structure in the code to support i
It might make sense to give more attention to cmake just because many
mesa-related projects are already using it: llvm, piglit, vulkan
loader and demos, mesa-demos, etc. Not sure how well it supports BSDs
and windows, but everyone building graphics stacks or contributing to
mesa should already be c
On Tue, Mar 21, 2017 at 7:23 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> Input attachments are clear-color aware on Sky Lake, so we
> can frequently sample from them with no resolves at all. However
> on Broadwell we still need to do a a resolve between the subpass
> that writes
On Tue, Mar 21, 2017 at 11:13 AM, Grazvydas Ignotas wrote:
> everyone building graphics stacks or contributing to
> mesa should already be comfortable with cmake thanks to piglit and
> llvm, which might not be the case for meson.
Or they could be contributing to mesa because it's the last project
On Tue, Mar 21, 2017 at 10:33:12AM +, Emil Velikov wrote:
> On 21 March 2017 at 09:09, Topi Pohjolainen
> wrote:
> > Recent change to use drmGetDevices2() made me realize that
> > build configured using
> >
> > PKG_CONFIG_PATH=my_drm_lib_path/pkgconfig ./autogen.sh
> >
> > considers the libdr
On 17-03-21 08:07:22, Jason Ekstrand wrote:
On Tue, Mar 21, 2017 at 8:04 AM, Jason Ekstrand
wrote:
On Mon, Mar 20, 2017 at 8:35 PM, Ben Widawsky wrote:
This patch begins introducing how we'll actually handle the potentially
many modifiers coming in from the API, how we'll store them, and th
On 21/03/17 16:14, Jason Ekstrand wrote:
> On Tue, Mar 21, 2017 at 7:23 AM, Samuel Iglesias Gonsálvez
> mailto:sigles...@igalia.com>> wrote:
>
> Input attachments are clear-color aware on Sky Lake, so we
> can frequently sample from them with no resolves at all. However
> on Broadwel
On Tue, Mar 21, 2017 at 8:33 AM, Ben Widawsky wrote:
> On 17-03-21 08:07:22, Jason Ekstrand wrote:
>
>> On Tue, Mar 21, 2017 at 8:04 AM, Jason Ekstrand
>> wrote:
>>
>> On Mon, Mar 20, 2017 at 8:35 PM, Ben Widawsky wrote:
>>>
>>> This patch begins introducing how we'll actually handle the potent
On Tue, Mar 21, 2017 at 10:03 AM, Nicolai Hähnle wrote:
> On 20.03.2017 23:43, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> Add _GFX6 and _GFX9 suffixes to conflicting definitions.
>>
>> sid.h and gfx9d.h can now be included in the same file.
>
>
> Are you compile-testing radv? I suspect that
On Tue, Mar 21, 2017 at 4:49 PM, Leo Liu wrote:
>
>
> On 03/21/2017 02:51 AM, Christian König wrote:
>>
>> Am 20.03.2017 um 23:49 schrieb Marek Olšák:
>>>
>>> From: Leo Liu
>>>
>>> Signed-off-by: Leo Liu
>>
>>
>> Ah, here it is. This one and the change to version 53.17 should be
>> squashed with
On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov wrote:
> On 20 March 2017 at 18:30, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
>> wrote:
>>> Seems like we ended up all over the place, so let me try afresh.
>>>
>>> Above all:
>>> - Saying "I don't care" about your users
On 03/21/2017 02:51 AM, Christian König wrote:
Am 20.03.2017 um 23:49 schrieb Marek Olšák:
From: Leo Liu
Signed-off-by: Leo Liu
Ah, here it is. This one and the change to version 53.17 should be
squashed with the change to 53.14.
With that done the patch is Reviewed-by: Christian König
On Mon, Mar 20, 2017 at 10:00 PM, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
>> > > wrote:
>> > > >
On Mon, Mar 20, 2017 at 10:10 PM, Jonathan Gray wrote:
> On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
>> wrote:
>> > Seems like we ended up all over the place, so let me try afresh.
>> >
>> > Above all:
>> > - Saying "I don't care
I would personally rather have scons and autotools than cmake. I've had the
misfortune of using all three, and cmake is not an improvement in my opinion.
Quoting Grazvydas Ignotas (2017-03-21 08:13:31)
> It might make sense to give more attention to cmake just because many
> mesa-related projects
Quoting Jani Nikula (2017-03-21 07:44:55)
> On Thu, 16 Mar 2017, Dylan Baker wrote:
> > First it's written in python, [...]
>
> How does meson handle python 2 vs. 3? How do you avoid issues in the
> build files wrt this? On Debian meson seems to depend on python 3, so
> are they fully python 3?
On 03/21/2017 09:54 AM, Alex Deucher wrote:
On Tue, Mar 21, 2017 at 9:46 AM, Marek Olšák wrote:
On Tue, Mar 21, 2017 at 7:49 AM, Christian König
wrote:
Am 20.03.2017 um 23:49 schrieb Marek Olšák:
From: Leo Liu
Signed-off-by: Leo Liu
Acked-by: Alex Deucher
Did we ever released 53.14.4
On Tue, Mar 21, 2017 at 4:50 PM, Marek Olšák wrote:
> On Tue, Mar 21, 2017 at 10:03 AM, Nicolai Hähnle wrote:
>> On 20.03.2017 23:43, Marek Olšák wrote:
>>>
>>> From: Marek Olšák
>>>
>>> Add _GFX6 and _GFX9 suffixes to conflicting definitions.
>>>
>>> sid.h and gfx9d.h can now be included in the
Hey Dylan,
I've just a few points, since I'm not too enthused by the prospect of having to
deal with yet another build system with yet another slightly different syntax.
But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
involved with Mesa and their opinion is what matte
Stop trying to specify texture or renderbuffer objects for unsupported
EGL images. Generate the error codes specified in the OES_EGL_image
extension.
Signed-off-by: Philipp Zabel
---
EGLImageTargetTexture2D and EGLImageTargetRenderbuffer would call
the pipe driver's create_surface callback withou
Function::getArgumentList() doesn't exist anymore, switch to using
arg_begin() (existed back to at least llvm-3.6.0).
CC:
---
src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp | 2 +-
src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp | 2 +-
src/gallium/drivers/swr/rasterizer
CP DMA and PKT3_WRITE_DATA (in CmdUpdateBuffer) don't (currently) write
through L2. Therefore, to make these writes visible to later accesses
we must invalidate L2 rather than just writing it back, to avoid the
possibility that stale data is read through L2.
Cc: "17.0"
Signed-off-by: Alex Smith
On 21 March 2017 at 15:57, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov
> wrote:
>> On 20 March 2017 at 18:30, Matt Turner wrote:
>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
>>> wrote:
Seems like we ended up all over the place, so let me try afresh.
On 03/21/2017 05:50 PM, Tim Rowley wrote:
> Function::getArgumentList() doesn't exist anymore, switch to using
> arg_begin() (existed back to at least llvm-3.6.0).
>
> CC:
> ---
> src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp | 2 +-
> src/gallium/drivers/swr/rasterizer/jitter/fetc
Hi Kai,
Quoting Kai Wasserbäch (2017-03-21 09:50:52)
> Hey Dylan,
> I've just a few points, since I'm not too enthused by the prospect of having
> to
> deal with yet another build system with yet another slightly different syntax.
> But ultimately this is only a "my 2 cents" e-mail, since others
Helps mainly Feral-ported games, due to their use of fma()
shader-db changes:
total instructions in shared programs : 3941587 -> 3940749 (-0.02%)
total gprs used in shared programs: 481511 -> 481460 (-0.01%)
total local used in shared programs : 27469 -> 27481 (0.04%)
total bytes used in sha
I hit an assert in the emiter while toying around with optimizations, because
ConstantFolding immediated a big int into a mad.
There is special handling for FMA/MAD in insnCanLoad, which is broken. With
this patch the special path should be not hit anymore. Anyway, the constraints
for the LIMMS ca
On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov wrote:
> On 21 March 2017 at 15:57, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov
>> wrote:
>>> On 20 March 2017 at 18:30, Matt Turner wrote:
On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
wrote:
> Seems like
Hey Dylan,
Dylan Baker wrote on 21.03.2017 18:34:
> Quoting Kai Wasserbäch (2017-03-21 09:50:52)
>> I've just a few points, since I'm not too enthused by the prospect of having
>> to
>> deal with yet another build system with yet another slightly different
>> syntax.
>> But ultimately this is onl
This is a series of clean-ups and fixes to get Mesa master building on
AOSP master again. AOSP master recently changed from X.Y.Z versioning to
just the letter commonly used. Primarily, dropping KitKat and earlier
support removes most of the version number dependencies and fixes the
build.
I've dr
Fixed with the following command:
perl -pe 'BEGIN{undef $/;} s/ \\\n\n/\n\n/smg' $(find . -name 'Android.*')
Signed-off-by: Rob Herring
---
v2:
- new patch
Android.common.mk | 2 +-
src/compiler/Android.glsl.gen.mk | 4 ++--
src/compiler/Android.nir.mk
The Android version defines are only needed for versions less than 4.2
which aren't really supported or tested.
Signed-off-by: Rob Herring
Reviewed-by: Tapani Pälli
---
v2:
- Update subject
- drop trailing \ on make variables
Android.common.mk | 4 +---
Android.mk
Commit 6facb0c08fa1 ("android: fix libz dynamic library dependencies")
added libz as a dependency, but this breaks host targets as the host
dependency is libz-host. As no host lib needs libz, just remove the
dependency for them.
Fixes: 6facb0c08fa1 "android: fix libz dynamic library dependencies"
The host libmesa_util is never used for Android builds, so remove it.
Signed-off-by: Rob Herring
Reviewed-by: Tapani Pälli
---
v2:
- no change
src/util/Android.mk | 35 ---
1 file changed, 35 deletions(-)
diff --git a/src/util/Android.mk b/src/util/Android.mk
i
Any users of KitKat are likely using an older version of Mesa and
KitKat support adds complexity to the make files. Dropping support
allows removing the MESA_LOLLIPOP_BUILD make variable in various make
files.
Signed-off-by: Rob Herring
Reviewed-by: Tapani Pälli
---
v2:
- keep LOCAL_MODULE_RELAT
On Tue, Mar 21, 2017 at 10:57 AM, Timothy Arceri wrote:
> ---
> src/gallium/drivers/radeon/r600_test_dma.c | 3 +-
> src/util/rand_xor.c| 62
> --
> src/util/rand_xor.h| 6 ++-
> 3 files changed, 64 insertions(+), 7 de
On 21 March 2017 at 18:06, Matt Turner wrote:
> On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov
> wrote:
>> On 21 March 2017 at 15:57, Matt Turner wrote:
>>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov
>>> wrote:
On 20 March 2017 at 18:30, Matt Turner wrote:
> On Mon, Mar 20, 2017
On Tue, Mar 21, 2017 at 2:05 PM, Emil Velikov wrote:
> On 20 March 2017 at 21:51, Jason Ekstrand wrote:
>> On Mon, Mar 20, 2017 at 8:18 AM, Emil Velikov
>> wrote:
>>> diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
>>> index 185780246e2..7aacdf4e094 100644
>>> --- a/src/
This doesn't build for me:
make[4]: Entering directory
'/home/notaz/src/radeon/mesa/src/gallium/winsys/amdgpu/drm'
CC amdgpu_bo.lo
amdgpu_bo.c: In function ‘amdgpu_buffer_get_metadata’:
amdgpu_bo.c:615:53: error: ‘AMDGPU_TILING_SWIZZLE_MODE_SHIFT’
undeclared (first use in this function)
On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov
wrote:
> On 21 March 2017 at 18:06, Matt Turner wrote:
> > On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov
> wrote:
> >> On 21 March 2017 at 15:57, Matt Turner wrote:
> >>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <
> emil.l.veli...@gmail.com
On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov wrote:
> On 21 March 2017 at 18:06, Matt Turner wrote:
>> (1) Non-recursive automake is necessary for parallel build performance
> Fully agree
>
>> (2) Non-recursive automake is intractably unmaintainable for
>> sufficiently large projects
> Not sure
On Tue, Mar 21, 2017 at 8:07 PM, Grazvydas Ignotas wrote:
> This doesn't build for me:
>
> make[4]: Entering directory
> '/home/notaz/src/radeon/mesa/src/gallium/winsys/amdgpu/drm'
> CC amdgpu_bo.lo
> amdgpu_bo.c: In function ‘amdgpu_buffer_get_metadata’:
> amdgpu_bo.c:615:53: error: ‘AMDG
> On Mar 19, 2017, at 4:37 PM, Emil Velikov wrote:
>
> On 19 March 2017 at 22:16, Miklós Máté wrote:
>> On 19/03/17 22:13, Emil Velikov wrote:
>>>
>>> Hi Miklós,
>>>
>>> On 19 March 2017 at 12:28, Miklós Máté wrote:
After this series the build goes further, but eventually stops wi
Signed-off-by: Ben Widawsky
---
src/gbm/backends/dri/gbm_dri.c | 28
1 file changed, 28 insertions(+)
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index a7ac149365..283a73454e 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/b
v2 of the third chunk of Renderbuffer Decompression support. The big change over
the previous version is that now the INVALID modifier is explcitly disallowed in
the GBM layer (and the equivalent i965 functionality).
The other big change is the priority selection algorithm for modifiers.
As befor
1 - 100 of 165 matches
Mail list logo