NEON (now called ASIMD) is available on all aarch64 CPUs. Our code was
missing an aarch64 path, leading to util_cpu_caps.has_neon always being
false on aarch64.
---
Here's the simpler patch to just always enable NEON on aarch64. It suits
my purposes, but I can imagine that you may prefer the
Am Mo., 21. Jan. 2019 um 10:10 Uhr schrieb Lucas Stach :
>
> Am Montag, den 21.01.2019, 07:50 +0100 schrieb Christian Gmeiner:
> > If the GPU supports linear sampling, linear addressing mode
> > will be used as default.
> >
> > > Signed-off-by: Christian Gmeiner
> > ---
> >
Hi Lucas
Am Mo., 21. Jan. 2019 um 10:03 Uhr schrieb Lucas Stach :
>
> Hi Christian,
>
> first of all, thanks for figuring this out. This is really nice
> to finally know how it works.
>
> Am Montag, den 21.01.2019, 07:49 +0100 schrieb Christian Gmeiner:
> > Defines how sampler (and pixel pipes)
Hi Eric
Am Do., 25. Okt. 2018 um 18:39 Uhr schrieb Eric Anholt :
>
> The vc4 driver can do prime sharing to many different KMS-only devices,
> such as the various tinydrm drivers for SPI-attached displays. Rename the
> driver away from "pl111" to represent what it will actually support:
>
https://bugs.freedesktop.org/show_bug.cgi?id=109446
Bug ID: 109446
Summary: Shadow of the Tomb Raider Trial freezes the system at
startup
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Fixes: b722b29f10d4 ("radv: add support for 16bit input/output")
---
Compile tested only. Noticed when passing by.
src/amd/common/ac_nir_to_llvm.c | 2 +-
src/amd/vulkan/radv_nir_to_llvm.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c
Reviewed-by: Jason Ekstrand
On Wed, Jan 23, 2019 at 6:41 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> Accessing bo->map and then pool->center_bo_offset without a lock is
> racy. One way of avoiding such race condition is to store the bo->map +
> center_bo_offset into pool->map
https://bugs.freedesktop.org/show_bug.cgi?id=109361
Hai changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
The semantic was removed in e6d93893662d.
---
src/gallium/docs/source/tgsi.rst | 18 --
1 file changed, 18 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 277f25ca41b..59410cfd663 100644
--- a/src/gallium/docs/source/tgsi.rst
Accessing bo->map and then pool->center_bo_offset without a lock is
racy. One way of avoiding such race condition is to store the bo->map +
center_bo_offset into pool->map at the time the block pool is growing,
which happens within a lock.
v2: Only set pool->map if not using softpin (Jason).
v3:
On Wed, Jan 23, 2019 at 06:08:50PM -0600, Jason Ekstrand wrote:
> On Wed, Jan 23, 2019 at 5:26 PM Rafael Antognolli
>
> wrote:
>
> Accessing bo->map and then pool->center_bo_offset without a lock is
> racy. One way of avoiding such race condition is to store the bo->map +
>
I guess as discovered with
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/47 maybe we
should wait to turn on merging MRs via web until we have at least some
basic build-test CI wired up.. the downside is slower 'maintainer'
response (if I am working on some long running branch I tend to
On Wed, Jan 23, 2019 at 5:26 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> Accessing bo->map and then pool->center_bo_offset without a lock is
> racy. One way of avoiding such race condition is to store the bo->map +
> center_bo_offset into pool->map at the time the block pool is
> I've started looking at the lima and panfrost drivers. The many
> combinations of Mali GPUs and DC isn't going to scale. The lima and
> panfrost trees can't even co-exist as both define a rockchip winsys
> which load different GPU drivers. The same will be true for meson,
> hisilicon, allwinner,
On Wed, Jan 23, 2019 at 3:26 PM Eric Anholt wrote:
>
> Matt Turner writes:
>
> > NEON (now called ASIMD) is available on all aarch64 CPUs. It seems that
> > our code was missing an aarch64 path, leading to util_cpu_caps.has_neon
> > always being false on aarch64. I think that means that the NEON
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_clear.c| 3 ++-
src/gallium/drivers/radeonsi/si_compute_blit.c | 5 -
src/gallium/drivers/radeonsi/si_pipe.h | 3 ++-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_clear.c
From: Sonny Jiang
Signed-off-by: Sonny Jiang
Signed-off-by: Marek Olšák
---
src/gallium/drivers/radeonsi/si_clear.c | 6 ++
.../drivers/radeonsi/si_compute_blit.c| 96 +++
src/gallium/drivers/radeonsi/si_pipe.c| 4 +
Matt Turner writes:
> NEON (now called ASIMD) is available on all aarch64 CPUs. It seems that
> our code was missing an aarch64 path, leading to util_cpu_caps.has_neon
> always being false on aarch64. I think that means that the NEON tiling
> code in vc4 would not be enabled on aarch64
Accessing bo->map and then pool->center_bo_offset without a lock is
racy. One way of avoiding such race condition is to store the bo->map +
center_bo_offset into pool->map at the time the block pool is growing,
which happens within a lock.
v2: Only set pool->map if not using softpin (Jason).
Cc:
On Fri, Oct 12, 2018 at 01:46:37PM -0500, Jason Ekstrand wrote:
> The Yf and Ys tilings change a bit between gen9 and gen10 so we have to
> be able to distinguish between them.
> ---
> src/intel/isl/isl.c | 12 ++--
> src/intel/isl/isl.h | 16
>
On Wed, Jan 23, 2019 at 2:45 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> Accessing bo->map and then pool->center_bo_offset without a lock is
> racy. One way of avoiding such race condition is to store the bo->map +
> center_bo_offset into pool->map at the time the block pool is
On Wed, 23 Jan 2019 at 17:21, Erik Faye-Lund
wrote:
>
> On Wed, 2019-01-23 at 17:03 +, Emil Velikov wrote:
> > Hi all,
> >
> > In case the patch is still outstanding, feel free to add
> > Reviewed-by: Emil Velikov
> >
>
> Thanks, pushed.
>
> > On Wed, 23 Jan 2019 at 11:20, Erik Faye-Lund
> >
https://bugs.freedesktop.org/show_bug.cgi?id=104166
--- Comment #1 from Alex Granni ---
It looks this won't be done. Which means the only option for swr AVX512 windows
binaries is Meson build with Mingw. I don't know if this works in practice.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=106843
Alex Granni changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109443
Bug ID: 109443
Summary: Build failure with MSVC 2017 when using Scons >= 3.0.3
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Accessing bo->map and then pool->center_bo_offset without a lock is
racy. One way of avoiding such race condition is to store the bo->map +
center_bo_offset into pool->map at the time the block pool is growing,
which happens within a lock.
Cc: Jason Ekstrand
Reported-by: Ian Romanick
Bugzilla:
On Wed, Jan 23, 2019 at 7:33 AM Sergii Romantsov
wrote:
> Hello, Jason. Sorry for belated answer.
> Why length of 1 was selected: primary type SpvOpTypeBool is already using
> length 1 (and description "For Workgroup pointers, this is the size of the
> referenced type.").
>
> Additionally with
On Thu, Oct 25, 2018 at 11:39 AM Eric Anholt wrote:
>
> The vc4 driver can do prime sharing to many different KMS-only devices,
> such as the various tinydrm drivers for SPI-attached displays. Rename the
> driver away from "pl111" to represent what it will actually support:
> various sorts of
On Wed, 2019-01-23 at 17:03 +, Emil Velikov wrote:
> Hi all,
>
> In case the patch is still outstanding, feel free to add
> Reviewed-by: Emil Velikov
>
Thanks, pushed.
> On Wed, 23 Jan 2019 at 11:20, Erik Faye-Lund
> wrote:
> > On Wed, 2019-01-23 at 10:42 +, Eric Engestrom wrote:
> >
On Wed, Jan 23, 2019 at 11:01:46AM +, Eric Engestrom wrote:
> On Friday, 2019-01-11 09:50:25 -0800, Caio Marcelo de Oliveira Filho wrote:
> [snip]
> > - To find the discussion associated with a commit in master, I'd
> > search the title in the mailing list archives. With MRs, the usual
> >
Hi all,
In case the patch is still outstanding, feel free to add
Reviewed-by: Emil Velikov
On Wed, 23 Jan 2019 at 11:20, Erik Faye-Lund
wrote:
>
> On Wed, 2019-01-23 at 10:42 +, Eric Engestrom wrote:
> > On Wednesday, 2019-01-23 11:21:27 +0100, Erik Faye-Lund wrote:
> > > On Wed,
While doing a review of the current ARB_gl_spirv series, I found that
this one also applies to Vulkan, and fixes some Vulkan tests, so I
preferred to send it in advance, and keep any ARB_gl_spirv series to
review to only apply to OpenGL.
FWIW, this was sent a long time ago [1], but since then
On Thursday, 2019-01-17 15:55:44 +0100, Erik Faye-Lund wrote:
> It could have been made obvious for instance by showing the commit-
> graph next to the commit-list, decorating it with the branch head in
> one end and clear continuation in the other.
I'd love that, it would really help a lot!
El 23/1/19 a las 7:26, Matt Turner escribió:
> On Sun, Jul 8, 2018 at 5:27 PM, Jose Maria Casanova Crespo
> wrote:
>> When the destination is a BYTE type allow raw movs
>> even if the stride is not exact multiple of destination
>> type and exec type, execution type is Word and its size is 2.
>>
Iago Toral Quiroga writes:
> Commit c84ec70b3a72 implemented execution type promotion to 32-bit for
> conversions involving half-float registers, which empirical testing suggested
> was required, but it did not incorporate this change into the assembly
> validator
> logic. This commits adds
Hello, Jason. Sorry for belated answer.
Why length of 1 was selected: primary type SpvOpTypeBool is already using
length 1 (and description "For Workgroup pointers, this is the size of the
referenced type.").
Additionally with length of 4 CI gives 3 failed tests:
Commit c84ec70b3a72 implemented execution type promotion to 32-bit for
conversions involving half-float registers, which empirical testing suggested
was required, but it did not incorporate this change into the assembly validator
logic. This commits adds that, preventing validation errors like
On Wed, 2019-01-23 at 10:42 +, Eric Engestrom wrote:
> On Wednesday, 2019-01-23 11:21:27 +0100, Erik Faye-Lund wrote:
> > On Wed, 2019-01-23 at 10:14 +, Daniel Stone wrote:
> > > Hi,
> > >
> > > On Wed, 23 Jan 2019 at 10:09, Eric Engestrom <
> > > eric.engest...@intel.com> wrote:
> > > >
On Friday, 2019-01-11 09:50:25 -0800, Caio Marcelo de Oliveira Filho wrote:
[snip]
> - To find the discussion associated with a commit in master, I'd
> search the title in the mailing list archives. With MRs, the usual
> way that this connection is made would be the reference to the MR as
>
On Wednesday, January 23, 2019 1:26:25 AM PST Erik Faye-Lund wrote:
> On Fri, 2019-01-18 at 11:27 -0500, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > ---
> > src/mesa/state_tracker/st_cb_queryobj.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git
On Wednesday, 2019-01-23 11:28:14 +0100, Erik Faye-Lund wrote:
> On Wed, 2019-01-23 at 10:08 +, Eric Engestrom wrote:
> > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > > Sending MRs from the main Mesa repository increase clutter in the
> > > repository, and decrease
On Wednesday, 2019-01-23 11:21:27 +0100, Erik Faye-Lund wrote:
> On Wed, 2019-01-23 at 10:14 +, Daniel Stone wrote:
> > Hi,
> >
> > On Wed, 23 Jan 2019 at 10:09, Eric Engestrom <
> > eric.engest...@intel.com> wrote:
> > > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > > >
On Wed, 2019-01-23 at 10:08 +, Eric Engestrom wrote:
> On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > Sending MRs from the main Mesa repository increase clutter in the
> > repository, and decrease visibility of project-wide branches. So
> > it's
> > better if MRs are sent
On Wed, 2019-01-23 at 10:14 +, Daniel Stone wrote:
> Hi,
>
> On Wed, 23 Jan 2019 at 10:09, Eric Engestrom <
> eric.engest...@intel.com> wrote:
> > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > > Sending MRs from the main Mesa repository increase clutter in the
> > >
Hi,
On Wed, 23 Jan 2019 at 10:09, Eric Engestrom wrote:
> On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > Sending MRs from the main Mesa repository increase clutter in the
> > repository, and decrease visibility of project-wide branches. So it's
> > better if MRs are sent from
On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> Sending MRs from the main Mesa repository increase clutter in the
> repository, and decrease visibility of project-wide branches. So it's
> better if MRs are sent from forks instead.
>
> Let's add a note about this, in case its not
On Thu, 2019-01-17 at 08:38 +0100, Erik Faye-Lund wrote:
> On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
> > All,
> >
> > The mesa project has now hit 100 merge requests (36 are still
> > open).
> > I (and I'm sure others) would be curious to hear people's initial
> > thoughts on the
On Fri, Jan 18, 2019 at 01:26:30PM +0300, Artyom Bambalov wrote:
> Do you have some notes on how to reproduce your setup? I've been meaning
> to try this out but never found enough time to see it through. Having a
> set of simple instructions for getting this built and booted would
Sending MRs from the main Mesa repository increase clutter in the
repository, and decrease visibility of project-wide branches. So it's
better if MRs are sent from forks instead.
Let's add a note about this, in case its not obvious to everyone.
Signed-off-by: Erik Faye-Lund
---
Thanks for reviewing this Frank. I'd wait some more for any further comments
before uploading a v2.
Frank Binns writes:
> Hi Luigi,
>
> Luigi Santivetti writes:
>
>> Before this change, if bindContext() failed then dri2_make_current() would
>> rebind the old EGL context and surfaces and
Streamout buffers are emitted like push constants.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_nir_to_llvm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index 40812fa7ffb..7f1aa17b0d5 100644
---
On Fri, 2019-01-18 at 11:27 -0500, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_cb_queryobj.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
> b/src/mesa/state_tracker/st_cb_queryobj.c
> index
On Tue, 2019-01-22 at 15:46 -0800, Matt Turner wrote:
> On Tue, Jan 15, 2019 at 5:55 AM Iago Toral Quiroga > wrote:
> >
> > This is available since gen8.
> >
> > v2: restore previously existing assertion.
> >
> > Reviewed-by: Topi Pohjolainen (v1)
> > ---
> >
On Tue, 2019-01-22 at 16:36 -0800, Matt Turner wrote:
> On Tue, Jan 15, 2019 at 5:54 AM Iago Toral Quiroga > wrote:
> >
> > We use ALign16 mode for this, since it is more convenient, but the
> > PRM
> > for Broadwell states in Volume 3D Media GPGPU, Chapter 'Register
> > region
> >
On 1/22/19 10:50 PM, Bas Nieuwenhuizen wrote:
On Tue, Jan 22, 2019 at 4:32 PM Samuel Pitoiset
wrote:
For some R8 formats, it's useless to export two channels
when no alpha blending is used. I assume the CB should
automatically clamps its inputs.
29077 shaders in 15096 tests
Totals:
SGPRS:
On Tue, 2019-01-22 at 16:18 -0800, Matt Turner wrote:
> On Tue, Jan 15, 2019 at 5:54 AM Iago Toral Quiroga > wrote:
> >
> > 3-src instructions don't support immediates, but since
> > 36bc5f06dd22,
> > we allow them on MAD and LRP relying on the combine constants pass
> > to
> > fix it up later.
56 matches
Mail list logo
