r-b
On Tue, Jul 2, 2019 at 2:47 PM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_image.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
> index
I really like just always filling the struct completely. Provides a
better abstraction and less surprises.
On Tue, Jul 2, 2019 at 2:47 PM Samuel Pitoiset
wrote:
>
> The decompress/resummarize pass always use the depth aspect.
>
> Signed-off-by: Samuel Pitoiset
> ---
>
r-b
On Tue, Jul 2, 2019 at 2:47 PM Samuel Pitoiset
wrote:
>
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 322e705621f..a89d804aa65 100644
> ---
r-b
On Tue, Jul 2, 2019 at 2:47 PM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_decompress.c | 66 +--
> 1 file changed, 41 insertions(+), 25 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_decompress.c
>
Wouldn't it be much better if we do all the layers in a single draw instead?
On Tue, Jul 2, 2019 at 2:47 PM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_decompress.c | 137 ++
> 1 file changed, 74 insertions(+), 63
https://bugs.freedesktop.org/show_bug.cgi?id=111043
Bug ID: 111043
Summary: PBO unpacking is not accelerated
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
On Tue, 2 Jul 2019 13:21:31 -0400
Marek Olšák wrote:
> On Tue., Jul. 2, 2019, 09:50 Boris Brezillon,
> wrote:
>
> > From: Daniel Stone
> >
> > Add a pipe_screen->set_damage_region() hook to propagate
> > set-damage-region requests to the driver, it's then up to the
> > driver to decide what
If you don't wanna see the messages, don't use debugoptimized.
Marek
On Tue., Jul. 2, 2019, 10:15 Michel Dänzer, wrote:
> On 2019-07-02 2:09 p.m., Mathias Fröhlich wrote:
> > On Tuesday, 2 July 2019 10:25:41 CEST Michel Dänzer wrote:
> >> On 2019-07-02 3:44 a.m., Dieter Nützel wrote:
> >>>
>
On Tue., Jul. 2, 2019, 09:50 Boris Brezillon,
wrote:
> From: Daniel Stone
>
> Add a pipe_screen->set_damage_region() hook to propagate
> set-damage-region requests to the driver, it's then up to the driver to
> decide what to do with this piece of information.
>
> If the hook is left
Eric Engestrom writes:
> On Saturday, 2019-06-29 22:59:21 +0200, apinheiro wrote:
>>
>> On 29/6/19 2:30, Rob Clark wrote:
>> > I had interpreted it as literally the "block the gitlab merge button"
>> > option, ie. "I want to get feedback but it is not ready to merge and
>> > I'll drop the WIP
Very nice work!
Reviewed-by: Alyssa Rosenzweig
On Tue, Jul 02, 2019 at 03:50:02PM +0200, Boris Brezillon wrote:
> Implement ->set_damage_region() region to support partial updates.
>
> This is a dummy implementation in that it does not try to merge
> damage rects. It also does not deal with
On Tue, Jul 2, 2019 at 12:04 PM Karol Herbst wrote:
>
> On Tue, Jul 2, 2019 at 5:54 PM Ilia Mirkin wrote:
> >
> > Can you check on PIPE_CAP_COMPUTE_SHADER_DERIVATIVES ? I think we
> > should be able to just flip that on for nvc0. Also the
> > CS_DERIVED_SYSTEM_VALUES thing might be useful -- I
On Tue, Jul 2, 2019 at 5:54 PM Ilia Mirkin wrote:
>
> Can you check on PIPE_CAP_COMPUTE_SHADER_DERIVATIVES ? I think we
> should be able to just flip that on for nvc0. Also the
> CS_DERIVED_SYSTEM_VALUES thing might be useful -- I had wanted to do
> that a while ago but laziness defeated me. Now
> We need a wrapper that contains a BO plus a pb_slab object for
> SLAB-based allocations (allocation of sub-page-size objects), that's
> exactly what panfrost_memory is right now. We can rename it if you
> like, but I don't think we can get rid of it.
Eventually I do think we'll want to toss
Can you check on PIPE_CAP_COMPUTE_SHADER_DERIVATIVES ? I think we
should be able to just flip that on for nvc0. Also the
CS_DERIVED_SYSTEM_VALUES thing might be useful -- I had wanted to do
that a while ago but laziness defeated me. Now that it's there though
... we have sysvals for many of those
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 13 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 13 +
2 files changed, 26 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
On Tue, 2 Jul 2019 at 17:02, Boris Brezillon
wrote:
>
> On Tue, 2 Jul 2019 16:54:22 +0200
> Tomeu Vizoso wrote:
>
> > On Tue, 2 Jul 2019 at 15:24, Boris Brezillon
> > wrote:
> > >
> > > There's no point duplicating the code, and it will help us simplify
> > > the bo_handles[] filling logic in
On Tue, 2 Jul 2019 16:54:22 +0200
Tomeu Vizoso wrote:
> On Tue, 2 Jul 2019 at 15:24, Boris Brezillon
> wrote:
> >
> > There's no point duplicating the code, and it will help us simplify
> > the bo_handles[] filling logic in panfrost_drm_submit_job().
>
> Looks good but, could we drop
:+1:, A-b
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, 2 Jul 2019 06:53:56 -0700
Alyssa Rosenzweig wrote:
> Oh, not controversial at all, I'm quite happy with this!
> Just a question -- I remember some panfrost_resources didn't have a bo
> but had a winsys thingy instead. How does that interact?
Didn't notice any specific test for the
On Tue, 2 Jul 2019 at 15:24, Boris Brezillon
wrote:
>
> There's no point duplicating the code, and it will help us simplify
> the bo_handles[] filling logic in panfrost_drm_submit_job().
Looks good but, could we drop panfrost_memory completely? Other
drivers seem to do fine wthout such a thing.
On Tue, 2 Jul 2019 at 15:24, Boris Brezillon
wrote:
>
> Hello,
>
> This patch series is an attempt at making memory allocation more
> consistent by implementing SLAB pool allocation around the BO allocation
> logic.
> Note that my initial goal was to pass referenced BOs to the kernel
> driver,
> > Stuff with no relation to the winsys, just... arbitrary user
> > memory?
>
> Nope, I don't think so. That might work if you allocate things through
> udmabuf, but then you're better off allocating a BO directly.
Alright, no worries, I was just curious.
signature.asc
Description: PGP
On Tue, 2 Jul 2019 at 15:24, Boris Brezillon
wrote:
>
> Let's keep a clear split between ioctl wrappers and the rest of the
> driver. All the import BO function need is a dmabuf FD and the screen
> object, and the export one should only take care of generating a dmabuf
> FD out of a BO object.
On Tue, 2 Jul 2019 06:56:50 -0700
Alyssa Rosenzweig wrote:
> Question: Does this allow us to map arbitrary CPU buffers into GPU
> space?
Depends what you mean by arbitrary. You can map any dmabuf, that means
the buffer has to be created kernel side and exported as a DMAbuf.
> Stuff with no
https://bugs.freedesktop.org/show_bug.cgi?id=107986
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 2019-07-02 2:09 p.m., Mathias Fröhlich wrote:
> On Tuesday, 2 July 2019 10:25:41 CEST Michel Dänzer wrote:
>> On 2019-07-02 3:44 a.m., Dieter Nützel wrote:
>>>
>>> /opt/mesa> git bisect good
>>> b5697c311b6f29dee40b96c48bad3279e3667c1e is the first bad commit
>>> commit
On Tue, 2 Jul 2019 15:49:58 +0200
Boris Brezillon wrote:
> From: Harish Krupo
Crap, forgot to update your email address here
>
> The intension of the KHR_partial_update was not to send the damage back
> to the platform but to send the damage to the driver to ensure that the
> following
R-b with pleasure! I'm not sure why we didn't get around to this
earlier, but this is awesome. Thank you! :)
On Tue, Jul 02, 2019 at 03:23:53PM +0200, Boris Brezillon wrote:
> Instead of manually adding the BOs from the various SLAB pools plus
> the one backing the color FB, we insert them in the
R-b, thank you!
On Tue, Jul 02, 2019 at 03:23:52PM +0200, Boris Brezillon wrote:
> There's no point duplicating the code, and it will help us simplify
> the bo_handles[] filling logic in panfrost_drm_submit_job().
>
> Signed-off-by: Boris Brezillon
> ---
>
A-b
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
A-b, let's wait for Tomeu on these few
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Besides the leak, I think I preferred the open-coded version, which is
incidentally what all other drivers I've seen do. The modifiers work
is going to massively change this code anyway.
But I'm not against it, so
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
On Tue, 2 Jul 2019 at 15:24, Boris
Question: Does this allow us to map arbitrary CPU buffers into GPU
space? Stuff with no relation to the winsys, just... arbitrary user
memory? That might be useful for index/vertex buffers (which we
currently are forced to memcpy() into a BO we create if given a user
pointer rather than a
I haven't checked the logic extensively, but provided CI/Tomeu is happy,
oatches 1-4 are:
Reviewed-by: Alyssa Rosenzweig
On Tue, Jul 02, 2019 at 03:23:43PM +0200, Boris Brezillon wrote:
> Hello,
>
> This patch series is an attempt at making memory allocation more
> consistent by
Implement ->set_damage_region() region to support partial updates.
This is a dummy implementation in that it does not try to merge
damage rects. It also does not deal with distinct regions and instead
pick the largest quad as the only damage rect and generate up to 4
reload rects out of it (the
From: Harish Krupo
The intension of the KHR_partial_update was not to send the damage back
to the platform but to send the damage to the driver to ensure that the
following rendering could be restricted to those regions.
This patch removes the set_damage_region from the egl_dri vtbl and all
the
This is an attempt at resurrecting Daniel's MR [1] which was already
resurrecting Harish's EGL_KHR_partial_update series [2]. This version
implements Marek's suggestion to pass the set_damage_region() directly
to the gallium driver and let it decide how to handle the request. Some
drivers might
From: Daniel Stone
Add a new DRI2_BufferDamage interface to support the
EGL_KHR_partial_update extension, informing the driver of an overriding
scissor region for a particular drawable.
Based on a commit originally authored by:
Harish Krupo
renamed extension, retargeted at DRI drawable instead
From: Daniel Stone
Add a pipe_screen->set_damage_region() hook to propagate
set-damage-region requests to the driver, it's then up to the driver to
decide what to do with this piece of information.
If the hook is left unassigned, the buffer-damage extension is
considered unsupported.
From: Harish Krupo
Use the DRI2 interface callback to pass the damage rects to
the driver.
Signed-off-by: Harish Krupo
Signed-off-by: Boris Brezillon
Acked-by: Alyssa Rosenzweig
---
Changes in v5:
* Add Alyssa's a-b
* Update Arish email address
* s/__DRI2_DAMAGE/__DRI2_BUFFER_DAMAGE/
---
Oh, not controversial at all, I'm quite happy with this!
Just a question -- I remember some panfrost_resources didn't have a bo
but had a winsys thingy instead. How does that interact?
On Tue, Jul 02, 2019 at 03:23:48PM +0200, Boris Brezillon wrote:
> That's what most (all?) implementation seem
Instead of manually adding the BOs from the various SLAB pools plus
the one backing the color FB, we insert them in the BO set attached
to the job and let panfrost_drm_submit_job() pass all BOs from this set
to the SUBMIT ioctl.
This means we are now passing all referenced BOs and let the
Let's keep a clear split between ioctl wrappers and the rest of the
driver. All the import BO function need is a dmabuf FD and the screen
object, and the export one should only take care of generating a dmabuf
FD out of a BO object. Winsys handle manipulation should stay in the
resource.c file.
To avoid the panfrost_memory <-> panfrost_bo dance done in
panfrost_resource_create_bo() and panfrost_bo_unreference().
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_drm.c | 62 +
src/gallium/drivers/panfrost/pan_resource.c | 32 +--
panfrost_drm_submit_job() and panfrost_fence_create() are not used
outside of pan_drm.c.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_drm.c| 4 ++--
src/gallium/drivers/panfrost/pan_screen.h | 5 -
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git
Hello,
This patch series is an attempt at making memory allocation more
consistent by implementing SLAB pool allocation around the BO allocation
logic.
Note that my initial goal was to pass referenced BOs to the kernel
driver, but I've decided to clean things up along the way (just let me
know if
Commit 5f81669d880b ("panfrost: Remove the panfrost_driver abstraction")
left a few things behind, remove them now.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_drm.c| 1 -
src/gallium/drivers/panfrost/pan_drm.h| 32 ---
Which improves readability and help us avoid a memory leak.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_resource.c | 79 -
1 file changed, 44 insertions(+), 35 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
That's what most (all?) implementation seem to do, and my understanding
is that a BO is just a bunch of memory that can be used for anything GPU
related, not only texture/FB resources.
Let's move those meta data in panfrost_resource so we can use
panfrost_bo for all kind of memory allocation and
So we can re-use it for the panfrost_drm_create_bo() function we are
about to introduce.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_drm.c | 51 +++---
1 file changed, 30 insertions(+), 21 deletions(-)
diff --git
bo->imported was never set to true which means this path was never taken.
Moreover, panfrost_drm_free_imported_bo() is doing missing the munmap()
call which seems wrong because the import BO function calls mmap().
Let's just kill this function along with the ->imported field.
Signed-off-by:
There's no point duplicating the code, and it will help us simplify
the bo_handles[] filling logic in panfrost_drm_submit_job().
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 21 +++---
src/gallium/drivers/panfrost/pan_allocate.h | 22 --
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_decompress.c | 66 +--
1 file changed, 41 insertions(+), 25 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_decompress.c
b/src/amd/vulkan/radv_meta_decompress.c
index 578a287d07b..fa5de24314a 100644
---
The decompress/resummarize pass always use the depth aspect.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index fc8184200fc..322e705621f 100644
---
---
src/amd/vulkan/radv_cmd_buffer.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 322e705621f..a89d804aa65 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1534,8 +1534,6 @@
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_image.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index eeccce0d82f..dc598d9eecf 100644
--- a/src/amd/vulkan/radv_image.c
+++
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_decompress.c | 137 ++
1 file changed, 74 insertions(+), 63 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_decompress.c
b/src/amd/vulkan/radv_meta_decompress.c
index fa5de24314a..5bb850a0797 100644
---
On Tue, 25 Jun 2019 at 11:08, Chih-Wei Huang wrote:
>
> There are several issues in the current Android makefiles. Though they
> may not affect the functionalities, it's ugly and unprofessional.
>
> * Add unnecessary LOCAL_EXPORT_C_INCLUDE_DIRS
> * Not export necessary include paths
> * Add dummy
Hi,
On Tuesday, 2 July 2019 10:25:41 CEST Michel Dänzer wrote:
> On 2019-07-02 3:44 a.m., Dieter Nützel wrote:
> >
> > /opt/mesa> git bisect good
> > b5697c311b6f29dee40b96c48bad3279e3667c1e is the first bad commit
> > commit b5697c311b6f29dee40b96c48bad3279e3667c1e
> > Author: Marek Olšák
> >
https://bugs.freedesktop.org/show_bug.cgi?id=109258
--- Comment #16 from Brendan King ---
I've been able to run Weston with the software rasteriser, using the recipe
given in comment 11 (including the code removal), since Mesa 18.1.0, and Weston
4.0. I've only tried this with the Gallium
On 2019-07-02 3:44 a.m., Dieter Nützel wrote:
>
> /opt/mesa> git bisect good
> b5697c311b6f29dee40b96c48bad3279e3667c1e is the first bad commit
> commit b5697c311b6f29dee40b96c48bad3279e3667c1e
> Author: Marek Olšák
> Date: Thu May 9 21:04:23 2019 -0400
>
> Change a few frequented uses of
Hi!
It's the final week to submit your talks, workshops or demos for
#XDC2019!!
CfP ends this coming Sunday, July 7!
Have some new developments to share? Facing some challenges with you
projects? If it's related to open source graphics, please send it in!
http://xdc2019.x.org
Best,
Mark
63 matches
Mail list logo
