On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote:
> On Mon, Jun 10, 2019 at 6:53 AM Rob Clark wrote:
> >
> > On Sat, Jun 8, 2019 at 6:08 PM Brian Masney wrote:
> > >
> > > Hi,
> > >
> > > I'm trying to get the GPU working using the Freedreno driver (A330) on
> > > the Nexus 5 phone. I'm
https://bugs.freedesktop.org/show_bug.cgi?id=110697
--- Comment #9 from Michel Dänzer ---
(In reply to QwertyChouskie from comment #8)
> I think this was worked around in the current release of kwin-lowlatency in
> this commit:
> https://github.com/tildearrow/kwin-lowlatency/commit/
>
On Tue, Jun 11, 2019 at 11:57 AM Samuel Iglesias Gonsálvez
wrote:
>
> According to the Vulkan spec, uniform blocks are not allowed to be
> updated through vkCmdPushDescriptorSetKHR().
>
> There are these spec quotes from "13.2.1. Descriptor Set Layout"
> that are relevant for this case:
>
>
According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().
There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:
"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
that descriptor
On 6/11/19 12:05 PM, Józef Kucia wrote:
> On Tue, Jun 11, 2019 at 11:57 AM Samuel Iglesias Gonsálvez
> wrote:
>> According to the Vulkan spec, uniform blocks are not allowed to be
>> updated through vkCmdPushDescriptorSetKHR().
>>
>> There are these spec quotes from "13.2.1. Descriptor Set
On Tue, Jun 11, 2019 at 12:19 PM Samuel Iglesias Gonsálvez
wrote:
> Right, it should be detected by the Validation Layers. However it is
> arguable what to do in the driver's side. We can just keep it as it is
> now, ignore inline uniform block updates (this patch) or even add an
> assert if it
While looking into dead-links on our website, I noticed that the OpenGL
Sample Implementation that SGI open sourced lacks a proper public
mirror. So I'm looking to fix this.
The tarballs are currently available from here:
According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().
There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:
"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
that descriptor
On 6/11/19 12:19 PM, Samuel Iglesias Gonsálvez wrote:
On 6/11/19 12:05 PM, Józef Kucia wrote:
On Tue, Jun 11, 2019 at 11:57 AM Samuel Iglesias Gonsálvez
wrote:
According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().
There are these
On 6/11/19 4:56 PM, Alex Deucher wrote:
On Tue, Jun 11, 2019 at 10:43 AM Samuel Pitoiset
wrote:
On VegaM, the visible VRAM size is equal to the VRAM size, which
means only two heaps are exposed.
FWIW, this is not VegaM specific. The vram size could be equal to the
visible vram size on any
According to the Vulkan spec, inline uniform blocks are not allowed
to be updated through vkCmdPushDescriptorSetKHR().
There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:
"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
that
For constant LODs/biases, we can use an immediate embedded in the
texture (already decoded); for non-constant, we have to use a register
squeezed into the usual immediate field, which is decoded here.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 22
Alright then.
Reviewed-by: Jason Ekstrand
On June 11, 2019 04:57:27 Samuel Iglesias Gonsálvez
wrote:
According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().
There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are
On Tue, Jun 11, 2019 at 10:43 AM Samuel Pitoiset
wrote:
>
> On VegaM, the visible VRAM size is equal to the VRAM size, which
> means only two heaps are exposed.
FWIW, this is not VegaM specific. The vram size could be equal to the
visible vram size on any asic depending on whether the platform
Am 10.06.19 um 15:56 schrieb Bas Nieuwenhuizen:
On Sat, Jun 8, 2019 at 3:36 PM Alex Smith wrote:
On Mon, 3 Jun 2019 at 13:27, Koenig, Christian wrote:
Am 03.06.19 um 14:21 schrieb Alex Smith:
On Mon, 3 Jun 2019 at 11:57, Koenig, Christian wrote:
Am 02.06.19 um 12:32 schrieb Alex Smith:
Looks reasonable.
Reviewed-by: Samuel Pitoiset
On 6/11/19 4:03 PM, Samuel Iglesias Gonsálvez wrote:
According to the Vulkan spec, inline uniform blocks are not allowed
to be updated through vkCmdPushDescriptorSetKHR().
There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are
The number of render backends is 16 but the enabled mask is 0x.
This fixes dEQP-VK.query_pool.* and dEQP-VK.multiview.*.
Cc: 19.0 19.1
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_query.c | 48 +
1 file changed, 27 insertions(+), 21
On VegaM, the visible VRAM size is equal to the VRAM size, which
means only two heaps are exposed.
This fixes dEQP-VK.api.info.device.memory_budget.
Cc: 19.0 19.1
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 17 +++--
1 file changed, 11 insertions(+), 6
Hi,
This series contains two fixes for VegaM, the first one is quite important
while the second one is only useful if VK_EXT_memory_budget is used.
There is still some TC-compat failures that I need to figure out.
With these two patches, we only have ~40 CTS failures.
Please review,
Thanks!
https://bugs.freedesktop.org/show_bug.cgi?id=109929
--- Comment #20 from Juan A. Suarez ---
Autotools has been removed in Mesa 19.1.0.
Should we close this?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110655
Juan A. Suarez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110655
--- Comment #5 from Juan A. Suarez ---
Mesa 19.1.0 has been released, which includes the fixes for this issue.
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=110662
--- Comment #10 from tempel.jul...@gmail.com ---
A screenshot with amdvlk without the artifacts:
https://abload.de/img/screenshot_20190611_2elj3e.png
The issue is most prominent with radv when the sun is shining.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=110761
--- Comment #2 from Juan A. Suarez ---
Could you check if this issue is now fixed in Mesa 19.1.0?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
On Mon, Jun 10, 2019 at 6:21 AM Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Modern DXVK requires event support [1], but looks like it only
> uses vkCmdSetEvent() + vkGetEventStatus(). So we can just
> borrow the relevant code from gen8, leaving CmdWaitEvents still
> unimplemented.
>
> [1]
>
https://bugs.freedesktop.org/show_bug.cgi?id=110625
Juan A. Suarez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Feel free to call it a bugfix and CC stable if you'd like.
On Tue, Jun 11, 2019 at 10:54 AM Jason Ekstrand
wrote:
>
>
> On Mon, Jun 10, 2019 at 6:21 AM Ville Syrjala <
> ville.syrj...@linux.intel.com> wrote:
>
>> From: Ville Syrjälä
>>
>> Modern DXVK requires event support [1], but looks like
Mesa 19.1.0 is now available.
This release consists of approximately 3700 commits from 158
developers.
Huge thanks to all the developers, testers and users for their
ongoing work and support shaping up the 19.1.0 release.
The top highlights include:
- GL_ARB_parallel_shader_compile for all
On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote:
> So here's the question: How does people feel about hosting this under
> https://gitlab.freedesktop.org/mesa/ogl-sample/? If people are OK with
> this, I will make that happen, and send out a patch to update the link
> we have in our FAQ
https://bugs.freedesktop.org/show_bug.cgi?id=110662
--- Comment #8 from Samuel Pitoiset ---
How does it look with AMDVLK?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=109929
--- Comment #21 from Timur Kristóf ---
The issue is not really autotools specific. Even though meson is able to build
it, ideally TTN shouldn't need to use GL(SL), as Michel said above.
--
You are receiving this mail because:
You are the QA
Using the knowledge of texture instructions gained in the previous
series, we can now implement the remaining texturing functions required
in GLES (including texturing in a vertex shader, which is neat).
Doesn't do much for conformance yet; mipmaps are a prerequisite for most
of the affected
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 2 ++
src/gallium/drivers/panfrost/midgard/midgard_emit.c | 8 +---
src/gallium/drivers/panfrost/midgard/midgard_schedule.c | 9 -
3 files changed, 15 insertions(+), 4 deletions(-)
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index
This follows the txb implementation, but requires an adjustment to how
the cont/last flags are set.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 10 +-
src/gallium/drivers/panfrost/midgard/midgard_emit.c| 9 ++---
2 files
We refactor the main tex handling to fit a bias argument in as well.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 65 ---
1 file changed, 55 insertions(+), 10 deletions(-)
diff --git
We do have native support for perspective division on the load/store
unit, but this is for the future, something ideally we would select
generally, not just for textures. Meanwhile, flipping on projector
lowering works now.
Signed-off-by: Alyssa Rosenzweig
---
https://bugs.freedesktop.org/show_bug.cgi?id=110662
--- Comment #9 from tempel.jul...@gmail.com ---
With amdvlk, the shadows look correct (no weird bright spots that wander with
the camera).
There is an issue with amdvlk though related to the game's effect of the
level's borders, but that seems
https://bugs.freedesktop.org/show_bug.cgi?id=110662
--- Comment #15 from Samuel Pitoiset ---
Oh okay, I see :-)
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=110884
--- Comment #4 from Marcos Simental ---
(In reply to Thiago Macieira from comment #3)
> This patch appears to fix the problem:
>
> From 49607f0524539cb836065b626bb3d3946061c486 Mon Sep 17 00:00:00 2001
> From: Thiago Macieira
> Date: Mon, 10
History lesson! In the early days of a Panfrost, we had a library
independent of the driver called `panwrap` which would be LD_PRELOAD'ed
into a driver to decode its cmdstream in real-time. When upstreaming
Panfrost, we realized that we would much rather have this decode
functionality maintained
https://bugs.freedesktop.org/show_bug.cgi?id=110662
--- Comment #11 from Samuel Pitoiset ---
The artifacts with RADV are only with the minimap right?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110662
--- Comment #14 from tempel.jul...@gmail.com ---
I've highlighted the artifacts:
https://abload.de/img/screenshot_20190611_2jqkx1.png
It looks quite worse in motion, as these bright spots shift their shape, wander
etc.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=110761
--- Comment #3 from Jakub Okoński ---
I can confirm that 19.0.6 is fixed, and I had these problems before on 19.0.5.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110662
--- Comment #12 from tempel.jul...@gmail.com ---
After turning off the minimap in the game's options, the "shadowmap holes" are
still there with radv (look a bit like drops in this screenshot):
https://bugs.freedesktop.org/show_bug.cgi?id=110662
--- Comment #13 from Samuel Pitoiset ---
I don't see what's wrong?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing
https://bugs.freedesktop.org/show_bug.cgi?id=110810
--- Comment #4 from Samuel Pitoiset ---
Yeah, I will fix.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
So allowing disabled render backends without pre-setting them in the
reset procedure will break the OCCLUSION_QUERY packet. Luckily we
don't seem to use it for radv (yet?). Maybe find a way to comment that
somewhere?
Otherwise, r-b
On Tue, Jun 11, 2019 at 4:43 PM Samuel Pitoiset
wrote:
>
> The
So can we rephrase this entire thing based on
physical_devices->mem_type_indices, instead of opencoding ordering &
detection?
On Tue, Jun 11, 2019 at 4:43 PM Samuel Pitoiset
wrote:
>
> On VegaM, the visible VRAM size is equal to the VRAM size, which
> means only two heaps are exposed.
>
> This
clude/GL/glext.h b/include/GL/glext.h
index 181df28d3bb..1743aae86d0 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -51,7 +51,9 @@ extern "C" {
#define GLAPI extern
#endif
-#define GL_GLEXT_VERSION 20180725
+#define GL_GLEXT_VERSION 20190611
+
+#include
/* Generated C h
https://bugs.freedesktop.org/show_bug.cgi?id=110761
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Pushed, thanks!
Marek
On Fri, Jun 7, 2019 at 7:19 AM wrote:
> From: Rui Salvaterra
>
> This implements GLSL disk shader caching for the R300-R500 series of AMD
> GPUs.
>
> Signed-off-by: Rui Salvaterra
> ---
> src/gallium/drivers/r300/r300_screen.c | 38 +-
>
53 matches
Mail list logo
