https://bugs.freedesktop.org/show_bug.cgi?id=109183
--- Comment #2 from Samuel Pitoiset ---
Can you explain why it's actually invalid?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
On 1/25/19 8:25 AM, Stéphane Marchesin wrote:
On Thu, Jan 24, 2019 at 10:17 PM Tapani Pälli wrote:
Hi;
On 1/25/19 4:57 AM, Stéphane Marchesin wrote:
Hi,
We'd like to expose fp64 functionality on Chrome OS where we only have
GLES. It seems like a simple approach is to enable this
On Thu, Jan 24, 2019 at 10:17 PM Tapani Pälli wrote:
>
> Hi;
>
> On 1/25/19 4:57 AM, Stéphane Marchesin wrote:
> > Hi,
> >
> > We'd like to expose fp64 functionality on Chrome OS where we only have
> > GLES. It seems like a simple approach is to enable this extension for
> > GLES:
> >
Hi;
On 1/25/19 4:57 AM, Stéphane Marchesin wrote:
Hi,
We'd like to expose fp64 functionality on Chrome OS where we only have
GLES. It seems like a simple approach is to enable this extension for
GLES:
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt
Anyone knows
Eric Anholt writes:
> [ Unknown signature status ]
> Rob Herring writes:
>
>> If we can't find a driver matching by name, then use the kmsro driver.
>> This removes the need for needing a driver descriptor for every possible
>> KMS driver.
>>
>> Signed-off-by: Rob Herring
>
> Oh, very nice.
>
Hi,
We'd like to expose fp64 functionality on Chrome OS where we only have
GLES. It seems like a simple approach is to enable this extension for
GLES:
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt
Anyone knows if what's the right thing to do? It seems to me that
Rob Herring writes:
> Enable using etnaviv for KMS renderonly. This still needs KMS driver
> name mapping to kmsro to be used automatically.
>
> Signed-off-by: Rob Herring
> diff --git a/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
> b/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
>
Rob Herring writes:
> If we can't find a driver matching by name, then use the kmsro driver.
> This removes the need for needing a driver descriptor for every possible
> KMS driver.
>
> Signed-off-by: Rob Herring
Oh, very nice.
There's some risk here -- for example, vkms (with prime enabled,
Rob Herring writes:
> From: 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:
> various sorts of KMS displays
Reviewed-by: Alyssa Rosenzweig
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
If we can't find a driver matching by name, then use the kmsro driver.
This removes the need for needing a driver descriptor for every possible
KMS driver.
Signed-off-by: Rob Herring
---
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 13 -
1 file changed, 8 insertions(+), 5
Enable using etnaviv for KMS renderonly. This still needs KMS driver
name mapping to kmsro to be used automatically.
Signed-off-by: Rob Herring
---
meson.build | 4 +--
src/gallium/meson.build | 12 +++
This series aims to make supporting new platforms containing
renderonly GPUs easier with less copy-n-paste. This hasn't been a big
issue so far as the current renderonly drivers (vc4 and etnaviv) only
exists on a few platforms. This is changing with i.MX+freedreno,
armada+etnaviv and a slew of
The kmsro winsys is equivalent to the imx winsys, so we can switch
to it and remove the imx one.
Signed-off-by: Rob Herring
---
Android.mk| 5 +-
Makefile.am | 2 +-
configure.ac | 14 +-
From: 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:
various sorts of KMS displays with the renderonly layer used
On Thu, Jan 24, 2019 at 12:16 PM Francisco Jerez wrote:
>
> Matt Turner writes:
>
> > ---
> > src/intel/compiler/brw_eu_validate.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/compiler/brw_eu_validate.c
> >
https://bugs.freedesktop.org/show_bug.cgi?id=109201
--- Comment #12 from Alexander ---
Created attachment 143229
--> https://bugs.freedesktop.org/attachment.cgi?id=143229=edit
Fireball works in Dense Biozone (Video)
I noticed that the gpu hang doesn't happen in the location "Dense Biozone".
https://bugs.freedesktop.org/show_bug.cgi?id=109183
Alexander changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Matt Turner writes:
> ---
> src/intel/compiler/brw_eu_validate.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_eu_validate.c
> b/src/intel/compiler/brw_eu_validate.c
> index a25010b225c..7f1580a5bb3 100644
> ---
---
src/intel/compiler/brw_eu_validate.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index a25010b225c..7f1580a5bb3 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++
Iago Toral writes:
> On Wed, 2019-01-23 at 06:03 -0800, Francisco Jerez wrote:
>> Iago Toral Quiroga writes:
>>
>> > Commit c84ec70b3a72 implemented execution type promotion to 32-bit
>> > for
>> > conversions involving half-float registers, which empirical testing
>> > suggested
>> > was
Build mesa 9842 failed
Commit c1efa240c9 by Dylan Baker on 1/14/2019 11:23 PM:
meson: Add warnings and errors when using ICC\n\nICC tries to be helpful by not erroring when it sees something that it\ndoesn't understand, which is completely the opposite of
On Wed, Jan 23, 2019 at 6:03 AM Francisco Jerez wrote:
>
> 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
Build mesa 9839 failed
Commit 281421e1bc by Emil Velikov on 11/14/2018 2:18 PM:
mapi: remove machinery handling CSV files\n\nWe haven't have one in years, so just drop the code.\n\nSigned-off-by: Emil Velikov \nReviewed-by: Erik Faye-Lund
Configure
On Wed, Jan 23, 2019 at 4:18 AM Iago Toral Quiroga wrote:
>
> 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
>
Matt Turner writes:
> 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
On Thu, 24 Jan 2019 at 16:22, Rob Herring wrote:
>
> On Thu, Jan 24, 2019 at 9:14 AM Emil Velikov wrote:
> >
> > Hi all,
> >
> > Fwiw I'm ok with the idea, as pointed out in 2/2 as-is this is a
> > partial solution.
> > Never the less is some solution for the problem we have.
> >
> > With that
There have been a bunch of sign-ups without names which makes for a confusing
list on https://members.x.org/members
If you get chance please update your name and affiliation in your profile
(username > Your Profile).
Harry
On 2019-01-24 9:42 a.m., Wentland, Harry wrote:
> Note that you will
> I don't think we have any cases of 2 different embedded GPUs in one
> system (but SoC vendors have done crazier things) and the number of
> GPUs is not a huge set.
>
> Also, if we require some config file to tell us what GPU, then we
> still have to update that config file for each and every
On Thu, Jan 24, 2019 at 9:14 AM Emil Velikov wrote:
>
> Hi all,
>
> Fwiw I'm ok with the idea, as pointed out in 2/2 as-is this is a
> partial solution.
> Never the less is some solution for the problem we have.
>
> With that said the series is:
> Acked-by: Emil Velikov
>
> On Wed, 23 Jan 2019
Hi all,
Fwiw I'm ok with the idea, as pointed out in 2/2 as-is this is a
partial solution.
Never the less is some solution for the problem we have.
With that said the series is:
Acked-by: Emil Velikov
On Wed, 23 Jan 2019 at 23:42, Alyssa Rosenzweig wrote:
>
> > I've started looking at the
Note that you will have to re-register in the new system. Your previous
credentials won't work.
Harry
On 2019-01-24 8:42 a.m., Wentland, Harry wrote:
> The 2019 X.Org Foundation elections are rapidly approaching. We will be
> forwarding the nominating process to the membership shortly. Please
The 2019 X.Org Foundation elections are rapidly approaching. We will be
forwarding the nominating process to the membership shortly. Please find the
election schedule below.
Please note that only current members can vote in the upcoming election, and
that the deadline for new memberships or
On Wed, 2019-01-23 at 14:47 +, Eric Engestrom wrote:
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=109201
Evan Goers changed:
What|Removed |Added
CC||megatog...@gmail.com
--
You are
Am Donnerstag, den 24.01.2019, 07:46 +0100 schrieb Christian Gmeiner:
> 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
Am Donnerstag, den 24.01.2019, 07:31 +0100 schrieb 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,
On Wed, 2019-01-23 at 06:03 -0800, Francisco Jerez wrote:
> 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
38 matches
Mail list logo
