Hi Emil,
> As you pointed out, the CS of the driver is not included, so I wonder
> if we cannot add link to instructions in panfrost_create_screen()
> Reading the current fprintf is fairly discouraging.
The command stream portion is now included in a follow-up patch,
although for downstream kerne
This patch set includes the command stream driver, providing a complete
upstream driver absent some winsys bits. The first patch includes the
driver itself; the second patch includes glue for an out-of-tree overlay
for old kernels. With this patchset and a small amount of out-of-tree
glue, Panfrost
In addition to the DRM interface in active development, for legacy
kernels Panfrost has a small, optional, out-of-tree glue repository. For
various reasons, this legacy code should not be included in Mesa proper,
but this commit allows it to coexist peacefully with upstream Panfrost.
If the nondrm
NVIDIA hardware is weird. The fragment shader allows 124 varying
components (i.e. 31 varyings), but a total of 128 input components if
you could e.g. gl_FragCoord. There's no way to express this currently --
specifying a max of 32 varyings will cause failures in some tests.
This separates INPUT_CO
https://bugs.freedesktop.org/show_bug.cgi?id=109543
--- Comment #5 from mikhail.v.gavri...@gmail.com ---
Which gcc versiob do you use?(In reply to Sylvain BERTRAND from comment #4)
> Tested Rise of the Tomb Raider : I get a system hang (I am going to report a
> regression because I did clear the g
For the NO_WAIT variants, we would jump into the ALWAYS case for both
nested and inverted occlusion queries. However if the query had
previously completed, the application could reasonably expect that the
render condition would follow that result.
To resolve this, we remove the nesting distinction
As kmsro allows an essentially mix-and-match hodgepodge of display
drivers and renderonly GPUs, it doesn't make sense to couple the display
driver entrypoint definition with the driver. Instead, we move *all*
kmsro entrypoints to a shared kmsro block at the end (avoiding clutter
and distraction sin
> You could also add an environment variable that, when not set, will
> cause it to abort on screen setup.
Aborting on screen setup sounds like a surprise to me ;)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mai
Switching to the defaults function cleans up pan_screen.h markedly and
futureproofs for when new PIPE_CAPs are added.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_screen.c | 157 +-
1 file changed, 6 insertions(+), 151 deletions(-)
diff --git a/src/g
Seems like a good idea. You could also add an environment variable that,
when not set, will cause it to abort on screen setup.
On February 4, 2019 20:04:23 Alyssa Rosenzweig wrote:
Until the kernel side matures and the full driver is upstreamed, to
avoid end-user surprises, Panfrost should on
https://bugs.freedesktop.org/show_bug.cgi?id=109550
Sylvain BERTRAND changed:
What|Removed |Added
Summary|[regression][amd tahiti xt] |[regression][amd tahiti
IMHO this is done at the wrong level. You're effectively keeping track
of a per-variable "this variable belongs to a tcs output that's not a
patch" bit. Doesn't seem worthy of a whole separate bit.
Also, you use ->without_array() a lot, but what you really need to do
is remove *one* layer of array
https://bugs.freedesktop.org/show_bug.cgi?id=109550
Sylvain BERTRAND changed:
What|Removed |Added
Attachment #143295|0 |1
is obsolete|
Until the kernel side matures and the full driver is upstreamed, to
avoid end-user surprises, Panfrost should only be built for the
adventurous.
Signed-off-by: Alyssa Rosenzweig
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index b8
https://bugs.freedesktop.org/show_bug.cgi?id=109550
--- Comment #2 from Sylvain BERTRAND ---
Created attachment 143295
--> https://bugs.freedesktop.org/attachment.cgi?id=143295&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact f
https://bugs.freedesktop.org/show_bug.cgi?id=109550
--- Comment #1 from Sylvain BERTRAND ---
Created attachment 143294
--> https://bugs.freedesktop.org/attachment.cgi?id=143294&action=edit
xorg log
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=109550
Sylvain BERTRAND changed:
What|Removed |Added
Version|unspecified |git
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=109550
Bug ID: 109550
Summary: [regression][amd tahiti xt] Rise of the Tomb Raider
hangs the system
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS
https://bugs.freedesktop.org/show_bug.cgi?id=109543
--- Comment #4 from Sylvain BERTRAND ---
Tested Rise of the Tomb Raider : I get a system hang (I am going to report a
regression because I did clear the game on 04/2018).
No pb with dota2 vulkan, artifact (vulkan) or cs:go (opengl)
I use a gfx s
On Mon, Feb 4, 2019 at 6:43 PM Ilia Mirkin wrote:
> On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand
> wrote:
> >
> > On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig
> wrote:
> >>
> >> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
> >> > far as I understand) basically be
Thanks :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand wrote:
>
> On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig wrote:
>>
>> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
>> > far as I understand) basically be owning the panfrost bits in mesa,
>> > you should be able to commit
On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig
wrote:
> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
> > far as I understand) basically be owning the panfrost bits in mesa,
> > you should be able to commit to them.
>
> Oh, thank you! :)
>
> > 1. Don't break the build
Carsten Haitzler writes:
> On Fri, 1 Feb 2019 11:08:07 + Emil Velikov
> said:
>
>> Hi Carsten,
>>
>> On 2019/01/31, Carsten Haitzler wrote:
>> > On Wed, 30 Jan 2019 18:33:35 + Emil Velikov
>> > said:
>> >
>> > You might want to hold off on this. My bugfix was actually patched out by
> Actually, I just gave you (Alyssa) push access... Also, as you'll (as
> far as I understand) basically be owning the panfrost bits in mesa,
> you should be able to commit to them.
Oh, thank you! :)
> 1. Don't break the build
Acked-by: Alyssa Rosenzweig
> 2. No merge commits
Just to be cle
> Top of src/util/ralloc.h?
Ah-ha, thank you! Suddenly mesa makes so much more sense :)
> Counting uniforms/attributes is all a confusing mess. I can confirm
> that what I do in v3d works, I just can't explain how without going and
> re-studying it.
Alright, I'll look there, thank you :)
> Bas
On Mon, Feb 4, 2019 at 3:13 PM Rob Herring wrote:
> On Sun, Feb 3, 2019 at 9:33 PM Alyssa Rosenzweig
> wrote:
> >
> > > You should just land it and start doing in-tree development!
> >
> > I don't have push access, you know :P
>
> I can push it if you don't want to go the MR route. That goes for
On Mon, Nov 5, 2018 at 8:58 PM Timothy Arceri wrote:
> Once linking opts are done this pass recombines varying components.
>
> This patch is loosely based on Connor's vectorize alu pass.
>
> V2: skip fragment shaders
>
> V3:
> - dont accidentally vectorise local vars
> - pass correct component to
On Sun, Feb 3, 2019 at 9:33 PM Alyssa Rosenzweig wrote:
>
> > You should just land it and start doing in-tree development!
>
> I don't have push access, you know :P
I can push it if you don't want to go the MR route. That goes for
subsequent changes too.
Rob
_
From: Nicolai Hähnle
It is required for the draw module, and makes a difference when
linking statically or against LLVM built with BUILD_SHARED_LIBS=ON.
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index bfff862c3c8..e955bdedcc6 10
https://bugs.freedesktop.org/show_bug.cgi?id=109543
--- Comment #3 from mikhail.v.gavri...@gmail.com ---
(In reply to Samuel Pitoiset from comment #2)
> It seems like we can't reproduce the problem. Where your mesa comes from?
https://koji.fedoraproject.org/koji/buildinfo?buildID=1183327
--
You
On Mon, Nov 5, 2018 at 8:58 PM Timothy Arceri wrote:
> This creates a new glsl_type with the specified number on components.
>
> We will use this in the following patch when vectorising io.
> ---
> src/compiler/nir_types.cpp | 24
> src/compiler/nir_types.h | 2 ++
>
https://bugs.freedesktop.org/show_bug.cgi?id=109543
--- Comment #2 from Samuel Pitoiset ---
It seems like we can't reproduce the problem. Where your mesa comes from?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
Am 04.02.19 um 20:20 schrieb Zhu, James:
> On 2019-02-04 2:15 p.m., Christian König wrote:
>> Am 04.02.19 um 20:12 schrieb James Zhu:
>>> On 2019-02-04 1:47 p.m., Liu, Leo wrote:
On 2/1/19 11:28 AM, Zhu, James wrote:
> Add compute shader to support video compositor render.
>
> Sign
On 2019-02-04 2:15 p.m., Christian König wrote:
> Am 04.02.19 um 20:12 schrieb James Zhu:
>> On 2019-02-04 1:47 p.m., Liu, Leo wrote:
>>> On 2/1/19 11:28 AM, Zhu, James wrote:
Add compute shader to support video compositor render.
Signed-off-by: James Zhu
---
src/gall
Am 04.02.19 um 20:12 schrieb James Zhu:
On 2019-02-04 1:47 p.m., Liu, Leo wrote:
On 2/1/19 11:28 AM, Zhu, James wrote:
Add compute shader to support video compositor render.
Signed-off-by: James Zhu
---
src/gallium/auxiliary/Makefile.sources | 2 +
src/gallium/auxiliary/meson.bu
On 2019-02-04 1:47 p.m., Liu, Leo wrote:
> On 2/1/19 11:28 AM, Zhu, James wrote:
>> Add compute shader to support video compositor render.
>>
>> Signed-off-by: James Zhu
>> ---
>>src/gallium/auxiliary/Makefile.sources | 2 +
>>src/gallium/auxiliary/meson.build | 2 +
>>
Iago Toral writes:
> On Mon, 2019-02-04 at 08:50 +0100, Iago Toral wrote:
>> On Fri, 2019-02-01 at 11:23 -0800, Francisco Jerez wrote:
>> > Iago Toral writes:
>> >
>> > > On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote:
>> > > > Iago Toral writes:
>> > > >
>> > > > > On Thu, 2019-01-
On 2/1/19 11:38 AM, Christian König wrote:
> Am 01.02.19 um 17:28 schrieb Zhu, James:
>> Add video compute shader render. export CS_COMPOSITOR_RENDER=true
>> to enable video compute shader render.
>
> Ok that actually makes more sense, but I would either put everything
> into one file or cleanly
On 2/1/19 11:28 AM, Zhu, James wrote:
> Add compute shader to support video compositor render.
>
> Signed-off-by: James Zhu
> ---
> src/gallium/auxiliary/Makefile.sources | 2 +
> src/gallium/auxiliary/meson.build | 2 +
> src/gallium/auxiliary/vl/vl_compositor_cs.c | 414
https://bugs.freedesktop.org/show_bug.cgi?id=109543
Dylan Baker changed:
What|Removed |Added
Blocks||109535
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Dylan Baker changed:
What|Removed |Added
Depends on||109543
Referenced Bugs:
https://bugs.fr
Alyssa Rosenzweig writes:
>> Looks like you leak the constants? You could pass ctx->ssa_constants
>> instead of NULL and the allocation would be automatically freed.
>
> Hm, alright. Is there documentation anywhere on how memctx works in
> general?
Top of src/util/ralloc.h?
>> > +nir_f
On 02/02/2019 08:07, Rodrigo Vivi wrote:
Straight copy from the kernel file.
Add more PCI Device IDs for Coffee Lake, Ice Lake,
and Amber Lake. It also include a reorg on Whiskey Lake IDs.
Align with kernel commits:
5e0f5a58b167 ("drm/i915/cfl: Adding another PCI Device ID.")
03ca3cf8e9aa ("dr
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Emil Velikov
> Sent: Monday, February 4, 2019 3:21 AM
> To: mesa-dev@lists.freedesktop.org
> Cc: mesa-sta...@lists.freedesktop.org; emil.l.veli...@gmail.com; Hota, Alok
>
> Subject: [Mesa-d
https://bugs.freedesktop.org/show_bug.cgi?id=109532
--- Comment #6 from asimiklit ---
Created attachment 143288
--> https://bugs.freedesktop.org/attachment.cgi?id=143288&action=edit
this simple program helps me to reproduce this issue.
just share my simple reproducer)
Run it in this way:
On Mon, Feb 4, 2019 at 3:02 AM Juan A. Suarez Romero
wrote:
> On Fri, 2019-02-01 at 15:33 -0600, Jason Ekstrand wrote:
> > On Fri, Feb 1, 2019 at 10:14 AM Juan A. Suarez Romero <
> jasua...@igalia.com> wrote:
> > > This can happen when we record a VkCmdDraw in a secondary buffer that
> > > was cr
On 2019-02-03 2:15 a.m., Stuart Young wrote:
> Jean has logged 3 versions of the same bug in Debian, as he wasn't sure
> which package was causing the issues.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921114
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921145
> https://bugs.d
https://bugs.freedesktop.org/show_bug.cgi?id=109532
--- Comment #5 from asimiklit ---
Hi,
I managed to reproduce this issue using provided shader under KBL with latest
mesa from git.
This happens with 'BlockB' field:
ir->data.max_array_access is 1
and
ir->type->length is 1 too
I am going to con
Reviewed-by: Lionel Landwerlin
On 02/02/2019 08:07, Rodrigo Vivi wrote:
Align with kernel commits:
5e0f5a58b167 ("drm/i915/cfl: Adding another PCI Device ID.")
03ca3cf8e9aa ("drm/i915/icl: Adding few more device IDs for Ice Lake")
Cc: José Roberto de Souza
Cc: Kenneth Graunke
Cc: Anuj Phoga
On February 3, 2019 21:33:39 Alyssa Rosenzweig wrote:
You should just land it and start doing in-tree development!
I don't have push access, you know :P
Make a MR with all the acks on it and I'll click the button. I say MR
because the full patch would be huge.
--Jason
__
On Mon, Feb 4, 2019 at 7:43 AM Andres Gomez wrote:
>
> On Fri, 2019-02-01 at 13:17 -0500, Ilia Mirkin wrote:
> > On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez wrote:
> > > Current implementation uses a complicated calculation which relies in
> > > an implicit conversion to check the integral part o
On Fri, 2019-02-01 at 13:17 -0500, Ilia Mirkin wrote:
> On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez wrote:
> > Current implementation uses a complicated calculation which relies in
> > an implicit conversion to check the integral part of 2 division
> > results.
> >
> > However, the calculation ac
Hi,
On 2.2.2019 3.20, Mark Janes wrote:
Eero Tamminen writes:
On 31.1.2019 1.37, Dylan Baker wrote:
This email announces the mesa 19.0 release candidate 1. I'll keep this email
fairly brief since I'm already running a little late on getting this done :)
I've just had to resolve quite a few au
On 01.02.19 05:25, Timothy Arceri wrote:
On 26/1/19 11:56 am, Marek Olšák wrote:
Timothy, can you please test the attached fix?
I'm having trouble compiling 32bit mesa on my machine at the moment so
haven't been able to test Batman. But this commit also causes No Mans
Sky to lock up my machi
Patch looks good to me, for what it's worth.
si_query_buffer_alloc could be restructured to be slightly cleaner by
unifying the two calls to prepare_buffer, but it's not a huge deal.
Cheers,
Nicolai
On 26.01.19 01:56, Marek Olšák wrote:
Timothy, can you please test the attached fix?
Thanks,
I'm a bit confused by this patch
It's in a section called xlib_lease, for leases to work I think the
newer version is required, but I think the underlying code was changed
to build without the newer headers
Do leases work with the old code, or should this section be renamed?
On Sun, 3 Feb 2019 a
https://bugs.freedesktop.org/show_bug.cgi?id=109543
--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 143285
--> https://bugs.freedesktop.org/attachment.cgi?id=143285&action=edit
vulkan-cube backtrace
--
You are receiving this mail because:
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=109543
Bug ID: 109543
Summary: After upgrade mesa to 19.0.0~rc1 all vulkan based
application stop working ["vulkan-cube" received
SIGSEGV in radv_pipeline_init_blend_state at
We user only a fraction (approximatelly 1/4) of the API - generate only
those.
This way, we spend less time processing and generate smaller file. This
also removes the need for hacks needed for compiling files bootstrapped
with another LLVM version.
Cc: Alok Hota
Cc: Bruce Cherniak
Cc: mesa-sta
Previously one of the SWR python generators would create wrappers for
LLVM functions. Every Create* API would have one, even though we only
needed about a quarter of them.
Additionally this meant that we could not create create the file with
one LLVM version and compile with another.
Cc: Dylan B
On Fri, 2019-02-01 at 15:33 -0600, Jason Ekstrand wrote:
> On Fri, Feb 1, 2019 at 10:14 AM Juan A. Suarez Romero
> wrote:
> > This can happen when we record a VkCmdDraw in a secondary buffer that
> > was created inheriting from the primary buffer, but with the framebuffer
> > set to NULL in the V
On Mon, 2019-02-04 at 08:50 +0100, Iago Toral wrote:
> On Fri, 2019-02-01 at 11:23 -0800, Francisco Jerez wrote:
> > Iago Toral writes:
> >
> > > On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote:
> > > > Iago Toral writes:
> > > >
> > > > > On Thu, 2019-01-24 at 11:45 -0800, Francisco J
On Fri, 1 Feb 2019 11:08:07 + Emil Velikov said:
> Hi Carsten,
>
> On 2019/01/31, Carsten Haitzler wrote:
> > On Wed, 30 Jan 2019 18:33:35 + Emil Velikov
> > said:
> >
> > You might want to hold off on this. My bugfix was actually patched out by
> > partly removing some of it. The void
Hi,
I am not sure if this is related with regards to what is causing hardware
accelerated decoding on my Raven laptop not to work.
Fedora repos:
che-mesa, rpmfusion, fedora-rawhide-kernel-nodebug
Mesa-git installed is build from: sha 9279a28
chromium-vaapi package from rpmfusion repo, started wi
65 matches
Mail list logo
