Hi Giuseppe,
I initially believed there would be no distinction in performing R/W
operations on DMA or SHM maps. However, in a previous email, David
mentioned:
*> The relevant kwin expert, Xaver Hugl, stated in a chat:> "While the
overhead on the compositor side would be lower, rendering>
Hi,
On 25/08/2023 12:34, Vlad Zahorodnii wrote:
I'm really curious here, and these aren't rhetorical questions: why
would anyone expect to be a difference in performance, as far as
QPainter is concerned? Isn't it ultimately just using a CPU-based
renderer onto a block of memory? Why should it
On 8/25/23 12:12, Giuseppe D'Angelo via Development wrote:
On 24/08/2023 21:37, Eduardo Hopperdietzel wrote:
The results show that there's no significant difference in the time
it takes for read and write operations using QPainter in SHM and DMA
maps.
I'm really curious here, and these
On 24/08/2023 21:37, Eduardo Hopperdietzel wrote:
The results show that there's no significant difference in the time it
takes for read and write operations using QPainter in SHM and DMA maps.
I'm really curious here, and these aren't rhetorical questions: why
would anyone expect to be a
On Thu, 24 Aug 2023 15:37:05 -0400
Eduardo Hopperdietzel wrote:
> Hi David,
>
> I've made a little Wayland app that uses both SHM and DMA, and I
> tested it on Weston, Sway, and my own compositor. I also tried it on
> three different machines: two with Intel i7 CPUs and one with a
> smaller ARM
Hi David,
I've made a little Wayland app that uses both SHM and DMA, and I tested it
on Weston, Sway, and my own compositor. I also tried it on three different
machines: two with Intel i7 CPUs and one with a smaller ARM CPU. These
machines had Intel Iris Pro, Nvidia GT525M, and Mali-400 GPUs,
On Fri, Aug 18, 2023 at 8:18 PM Eduardo Hopperdietzel
wrote:
>
> Hi David,
>
> That's a very good point I hadn't thought about. I will create a testing
> Wayland client benchmark and measure the time it takes for QPainer to perform
> different drawing operations using both SHM and DMA. I'll
Hi David,
That's a very good point I hadn't thought about. I will create a testing
Wayland client benchmark and measure the time it takes for QPainer to
perform different drawing operations using both SHM and DMA. I'll also test
buffer resizing and measure the overall (client/compositor)
>
> Do you foresee any potential issues with this approach? Please feel free to
> share your thoughts.
>
The relevant kwin expert, Xaver Hugl said in a chat about this topic:
"While the overhead on the compositor side would be lower, rendering
into a dmabuf with the CPU is pretty slow,
Hello Kai,
Thank you for your reply. After following the links you provided, I believe
that implementing the DMA feature should take place within the following
file:
https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandshmbackingstore.cpp
Here's my proposed plan for this
Hi,
Qt Wayland Client currently relies on EGL through wayland-egl
integration to do the right thing. On Mesa for instance Qt indeed
transparently uses zwp_linux_dmabuf_v1.
However, I agree that Qt itself should have an implementation of the
aforementioned protocol on the *client* side, too
Hello,
I've noticed that Qt currently uses shared memory for buffer sharing with
Wayland compositors in non-OpenGL rendering applications. However, a more
efficient approach would be to use the zwp_linux_dmabuf_v1 protocol. By
creating a DMA buffer, mapping it, and performing CPU rendering there,
12 matches
Mail list logo
