Hi, On Fri, 28 Jun 2024 at 10:43, Tomeu Vizoso <tomeu@xxxxxxxxxxxxxxx> wrote: > On Wed, Jun 26, 2024 at 9:26 PM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > It's not just etnaviv, it's literally every Mesa driver which works > > with decoupled render/display. So that would be etnaviv-v2, > > panfrost-v2, panthor-v2, v3d-v2, powervr-v2, ... albeit those don't > > tend to have multiple instances. > > TBH, I think VeriSilicon is the only IP vendor that has recycled a > render-only IP into a compute-only IP. > > That is why I liked the approach of conditionally creating an accel > node, as it neatly reflects that reality. > > > Anyway, I'm still leaning towards the answer being: this is not an > > etnaviv regression caused by NPU, it's a longstanding generic Mesa > > issue for which the answer is to fix the known fragility. > > My understanding of the consensus so far is that Mesa should be fixed > so that Gallium drivers can fail at screen init if the device doesn't > support some new usage flags that we would be adding. > > If for some reason that doesn't work, we would be looking at having > etnaviv use a different kind of driver name, such as etnaviv-npu or > etnaviv-compute. > > Did I get it right? Yep, wfm. :) Cheers, Daniel
