Am Dienstag, dem 25.06.2024 um 09:56 +0200 schrieb Michel Dänzer:
> On 2024-06-24 21:08, James Jones wrote:
> > FWIW, the NVIDIA binary driver's implementation of gbm_bo_map/unmap()
> >
> > 1) Don't do any synchronization against in-flight work. The assumption is
> > that if the content is going
On 2024-06-24 21:08, James Jones wrote:
> FWIW, the NVIDIA binary driver's implementation of gbm_bo_map/unmap()
>
> 1) Don't do any synchronization against in-flight work. The assumption is
> that if the content is going to be read, the API writing the data has
> established that coherence. Like
Am 24.06.24 um 21:08 schrieb James Jones:
FWIW, the NVIDIA binary driver's implementation of gbm_bo_map/unmap()
1) Don't do any synchronization against in-flight work. The assumption
is that if the content is going to be read, the API writing the data
has established that coherence. Likewise,
FWIW, the NVIDIA binary driver's implementation of gbm_bo_map/unmap()
1) Don't do any synchronization against in-flight work. The assumption
is that if the content is going to be read, the API writing the data has
established that coherence. Likewise, if it's going to be written, the
API readi
On 6/20/24 15:59, Pierre Ossman wrote:
We recently identified that it has an issue[2] with synchronization on
the server side when after glFlush() in the client side the command
list takes too much (several seconds) to finish the rendering.
[2] https://gitlab.freedesktop.org/mesa/mesa/-/issues
On 6/20/24 11:04, Chema Casanova wrote:
You can have a look at the Open MR we created two years ago for Xserver
[1] "modesetting: Add DRI3 support to modesetting driver with glamor
disabled". We are using it downstream for Raspberry Pi OS to enable on
RPi1-3 GPU accelerated client application
El 17/6/24 a las 12:29, Pierre Ossman escribió:
So if you want to do some rendering with OpenGL and then see the
result in a buffer memory mapping the correct sequence would be the
following:
1. Issue OpenGL rendering commands.
2. Call glFlush() to make sure the hw actually starts working on
On 17/06/2024 19:18, Pierre Ossman wrote:
Hmm... The source of the blit is CopyWindow being called as a result of
the window moving. But I would have expected that to be inhibited by the
fact that a compositor is active. It's also surprising that this only
happens if DRI3 is involved.
I wou
On 2024-06-17 19:18, Pierre Ossman wrote:
> On 17/06/2024 18:09, Michel Dänzer wrote:
>>>
>>> Can I know whether it is needed or not? Or should I be cautious and always
>>> do it?
>>
>> Assuming GBM in the X server uses the GPU HW driver, I'd say it shouldn't be
>> needed.
Let me revise that sta
Am 18.06.24 um 07:01 schrieb Pierre Ossman:
On 17/06/2024 20:18, Christian König wrote:
Am 17.06.24 um 19:18 schrieb Pierre Ossman:
On 17/06/2024 18:09, Michel Dänzer wrote:
Can I know whether it is needed or not? Or should I be cautious
and always do it?
Assuming GBM in the X server uses
On 17/06/2024 20:18, Christian König wrote:
Am 17.06.24 um 19:18 schrieb Pierre Ossman:
On 17/06/2024 18:09, Michel Dänzer wrote:
Can I know whether it is needed or not? Or should I be cautious and
always do it?
Assuming GBM in the X server uses the GPU HW driver, I'd say it
shouldn't be n
Am 17.06.24 um 19:18 schrieb Pierre Ossman:
On 17/06/2024 18:09, Michel Dänzer wrote:
Can I know whether it is needed or not? Or should I be cautious and
always do it?
Assuming GBM in the X server uses the GPU HW driver, I'd say it
shouldn't be needed.
It does not (except the driver lib
On 17/06/2024 18:09, Michel Dänzer wrote:
Can I know whether it is needed or not? Or should I be cautious and always do
it?
Assuming GBM in the X server uses the GPU HW driver, I'd say it shouldn't be
needed.
It does not (except the driver libgbm loads). We're trying to use this
in Xvnc,
On 2024-06-17 17:27, Pierre Ossman wrote:
> On 17/06/2024 16:50, Michel Dänzer wrote:
>> On 2024-06-17 12:29, Pierre Ossman wrote:
>>>
>>> Just to avoid any uncertainty, are both of these things done implicitly by
>>> gbm_bo_map()/gbm_bo_unmap()?
>>>
>>> I did test adding those steps just in case,
On 17/06/2024 16:50, Michel Dänzer wrote:
On 2024-06-17 12:29, Pierre Ossman wrote:
Just to avoid any uncertainty, are both of these things done implicitly by
gbm_bo_map()/gbm_bo_unmap()?
I did test adding those steps just in case, but unfortunately did not see an
improvement. My order was:
On 2024-06-17 16:52, Christian König wrote:
> Am 17.06.24 um 16:50 schrieb Michel Dänzer:
>> On 2024-06-17 12:29, Pierre Ossman wrote:
>>> Just to avoid any uncertainty, are both of these things done implicitly by
>>> gbm_bo_map()/gbm_bo_unmap()?
>>>
>>> I did test adding those steps just in case,
Am 17.06.24 um 16:55 schrieb Michel Dänzer:
On 2024-06-17 16:52, Christian König wrote:
Am 17.06.24 um 16:50 schrieb Michel Dänzer:
On 2024-06-17 12:29, Pierre Ossman wrote:
Just to avoid any uncertainty, are both of these things done implicitly by
gbm_bo_map()/gbm_bo_unmap()?
I did test add
On 2024-06-17 12:29, Pierre Ossman wrote:
>
> Just to avoid any uncertainty, are both of these things done implicitly by
> gbm_bo_map()/gbm_bo_unmap()?
>
> I did test adding those steps just in case, but unfortunately did not see an
> improvement. My order was:
>
> 1. gbm_bo_import(GBM_BO_USE_R
Am 17.06.24 um 16:50 schrieb Michel Dänzer:
On 2024-06-17 12:29, Pierre Ossman wrote:
Just to avoid any uncertainty, are both of these things done implicitly by
gbm_bo_map()/gbm_bo_unmap()?
I did test adding those steps just in case, but unfortunately did not see an
improvement. My order was:
Am 17.06.24 um 12:29 schrieb Pierre Ossman:
On 17/06/2024 10:13, Christian König wrote:
Let me try to clarify a couple of things:
The DMA_BUF_IOCTL_SYNC function is to flush and invalidate caches so
that the GPU can see values written by the CPU and the CPU can see
values written by the GPU.
On 17/06/2024 10:13, Christian König wrote:
Let me try to clarify a couple of things:
The DMA_BUF_IOCTL_SYNC function is to flush and invalidate caches so
that the GPU can see values written by the CPU and the CPU can see
values written by the GPU. But that IOCTL does *not* wait for any async
Am 17.06.24 um 09:32 schrieb Pierre Ossman:
On 15/06/2024 13:35, Marek Olšák wrote:
It's probably driver-specific. Some drivers might need glFlush before
you use gbm_bo_map because gbm might only wait for work that has been
flushed.
That would be needed on the "writing" side, right? So if I'm
On 15/06/2024 13:35, Marek Olšák wrote:
It's probably driver-specific. Some drivers might need glFlush before
you use gbm_bo_map because gbm might only wait for work that has been
flushed.
That would be needed on the "writing" side, right? So if I'm seeing
issues when mapping for reading, the
It's probably driver-specific. Some drivers might need glFlush before
you use gbm_bo_map because gbm might only wait for work that has been
flushed.
Marek
On Sat, Jun 15, 2024 at 4:29 AM Pierre Ossman wrote:
>
> On 15/06/2024 07:54, Marek Olšák wrote:
> > gbm_bo_map synchronizes if it needs to m
On 15/06/2024 07:54, Marek Olšák wrote:
gbm_bo_map synchronizes if it needs to move memory to make the buffer
readable by the CPU or if the buffer is being used/written by the GPU.
Great, thanks! That means I need to look elsewhere for the source of my
issue.
I was concerned that since I wa
gbm_bo_map synchronizes if it needs to move memory to make the buffer
readable by the CPU or if the buffer is being used/written by the GPU.
Marek
On Sat, Jun 15, 2024 at 1:12 AM Pierre Ossman wrote:
>
> I'm experimenting with DRI3 and its use of GBM to share buffers. It
> mostly works fine, but
I'm experimenting with DRI3 and its use of GBM to share buffers. It
mostly works fine, but I'm seeing some issues that have me concerned
there might be a synchronisation issue.
The documentation isn't entirely clear, so my question is if
gbm_bo_map() handles all the implicit synchronisation fo
27 matches
Mail list logo
