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 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
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 Wed, 2024-06-19 at 10:33 -0400, Mike Blumenkrantz wrote:
> In looking at the gallium tree, I'm wondering if it isn't time for a
> second amber branch to prune some of the drivers that cause pain when
> doing big tree updates:
>
> * nv30
> * r300
> * r600
> * lima
> * virgl
> * tegra
> * ???
>
On 6/19/24 11:36, Pierre Ossman wrote:
Is there something special I need to pay attention to when doing cross
GPU stuff? I would have assumed that gbm_bo_import() would have
complained if this was an incompatible setup.
It does indeed look like some step is missing. If I examine
/proc//ma
On 6/20/24 16:29, Pierre Ossman wrote:
On 6/19/24 11:36, Pierre Ossman wrote:
Is there something special I need to pay attention to when doing cross
GPU stuff? I would have assumed that gbm_bo_import() would have
complained if this was an incompatible setup.
It does indeed look like some
On Thu, Jun 20, 2024 at 10:20 AM Erik Faye-Lund <
erik.faye-l...@collabora.com> wrote:
> When we did Amber, we had a lot better reason to do so than "these
> drivers cause pain when doing big tree updates". The maintenance burden
> imposed by the drivers proposed for removal here is much, much sma
On 19/06/2024 20:34, Mike Blumenkrantz wrote:
> Terakan is not a Mesa driver, and Mesa has no obligation to cater to
out-of-tree projects which use its internal API. For everything else,
see above.
I don't think, however, that it can simply be dismissed like it doesn't
exist when it's:
• str
On Thu, Jun 20, 2024 at 12:30 PM Adam Jackson wrote:
> On Thu, Jun 20, 2024 at 10:20 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
>
>> When we did Amber, we had a lot better reason to do so than "these
>> drivers cause pain when doing big tree updates". The maintenance burden
>> imp
