[Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Erik Faye-Lund]

On Wed, 2019-12-04 at 01:48 -0500, Marek Olšák wrote:
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli, <tapani.palli at intel.com>
> wrote:
> > Hi;
> > 
> > On 12/4/19 2:39 AM, Marek Olšák wrote:
> > > Hi,
> > > 
> > > Here are 2 proposals to simplify and better optimize the GL-
> > >Gallium 
> > > translation.
> > > 
> > > 1) Move classic drivers to a fork of Mesa, and remove them from
> > master. 
> > > Classic drivers won't share any code with master. glvnd will load
> > them, 
> > > but glvnd is not ready for this yet.
> > > 
> > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
> > > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to
> > be 
> > > forked and mesa/state_tracker moved. src/gallium/state-
> > trackers/gl/ can 
> > > be the target location.
> > > 
> > > Option 2 is more acceptable to people who want to keep classic
> > drivers 
> > > in the tree and it can be done right now.
> > > 
> > > Opinions?
> > > 
> > 
> > I'm still quite newbie with gallium side of things and I'd like to
> > know 
> > more about the possible simplifications and optimizations that
> > could be 
> > done if this happened. Is this more about 'cleaning up the tree' or
> > are 
> > there also some performance opportunities we are missing right now
> > with 
> > current state?
> 
> It's possible to reduce CPU overhead even more by moving state
> translation from st_validate_state to GL functions. This is possible
> already, but at the cost of effectively adding dead code to classic
> drivers. In theory we could do slightly better without classic
> drivers, but we don't know for sure.
> 
> If we had nir_to_tgsi, we could remove TGSI support from st/mesa.
> Option 1 would leave st/mesa as the only consumer of Mesa IR and GLSL
> IR, so both IRs could be eliminated in favor of NIR more easily. 

Implementing nir_to_tgsi is something I've considered several times
while working on VirGL; there's a lot of useful lowering-code in NIR
that sometimes has to be re-implemented in TGSI, and writing new
lowering code targetting NIR is just so much nicer than when targetting
TGSI.

For both SVGA and VirGL, TGSI can't be completely eliminated without
breaking compatibility, because TGSI is part of their protocols. And I
believe in both cases, it's a slightly divergent variation of TGSI.

So yeah, just wanted to say: +1 on this part :)