Re: time for amber2 branch?

2024-06-19 Thread Erico Nunes
On Thu, Jun 20, 2024 at 12:02 AM Mike Blumenkrantz wrote: > * lima We do maintain this, with reliable coverage in CI, and I haven't seen feedback of it particularly causing big pain for tree wide changes before. So I'd rather keep it in the main tree. At least for this round and as long as we kee

Re: time for amber2 branch?

2024-06-19 Thread Marek Olšák
i915? tegra isn't really a driver. It just calls the gallium interface like trace, but without the tracing. crocus is in the same boat as r600. Marek On Wed, Jun 19, 2024, 10:34 Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > In looking at the gallium tree, I'm wondering if it isn

Re: time for amber2 branch?

2024-06-19 Thread Gert Wollny
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: virgl is actively maintained and covered by the CI. Apart from the

Re: time for amber2 branch?

2024-06-19 Thread Karol Herbst
On Wed, Jun 19, 2024 at 4:34 PM 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 ack for nv30 > * r300 > * r600 > * lima > * virgl > * t

Re: time for amber2 branch?

2024-06-19 Thread Karol Herbst
On Wed, Jun 19, 2024 at 5:32 PM Thomas Debesse wrote: > > Le mer. 19 juin 2024 à 16:33, Mike Blumenkrantz > a écrit : > > 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 > >

Re: time for amber2 branch?

2024-06-19 Thread Mike Blumenkrantz
On Wed, Jun 19, 2024 at 1:22 PM Triang3l wrote: > The shader compiler in R600g is actively developed (and I think OpenGL 4.6 > support is among the main goals), I don't see why it needs to be moved to a > low-priority branch or to stop getting new NIR infrastructure updates > with the > current a

Re: time for amber2 branch?

2024-06-19 Thread Triang3l
The shader compiler in R600g is actively developed (and I think OpenGL 4.6 support is among the main goals), I don't see why it needs to be moved to a low-priority branch or to stop getting new NIR infrastructure updates with the current amount of maintenance it receives. On 19/06/2024 18:26, T

[ANNOUNCE] mesa 24.1.2

2024-06-19 Thread Eric Engestrom
Hello everyone, The bugfix release 24.1.2 is now available. If you find any issues, please report them here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/new The next bugfix release is due in two weeks, on July 3rd. Cheers, Eric --- Amol Surati (1): nine: avoid using post-compact

Re: time for amber2 branch?

2024-06-19 Thread Thomas Debesse
Le mer. 19 juin 2024 à 16:33, Mike Blumenkrantz a écrit : > 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 It's probably fine for nv30 and r300 that are very unlikely to receiv

time for amber2 branch?

2024-06-19 Thread Mike Blumenkrantz
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 * ??? There's nothing stopping these drivers from continuing to develop in an amber branch

Re: SIGBUS with gbm_bo_map() and Intel ARC

2024-06-19 Thread Pierre Ossman
On 19/06/2024 11:36, Pierre Ossman wrote: Hi, More gbm_bo_map() issues from me that could use some expert insight. When I mix GPU access in my GBM adventures, one combination results in a SIGBUS when reading the memory given from gbm_bo_map(). I'm unsure if this is a bug in the driver, or in

SIGBUS with gbm_bo_map() and Intel ARC

2024-06-19 Thread Pierre Ossman
Hi, More gbm_bo_map() issues from me that could use some expert insight. When I mix GPU access in my GBM adventures, one combination results in a SIGBUS when reading the memory given from gbm_bo_map(). I'm unsure if this is a bug in the driver, or in my access? What I do is: 1. X server doe