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

[Ian Romanick]

On 12/3/19 10:48 PM, Marek Olšák wrote:
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli, <tapani.palli at intel.com
> <mailto: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 someone wants to start on this, I would be more than happy to help
with the work on the old, poorly maintained drivers.  I have almost all
of the necessary hardware installed in (mostly) functioning systems.
The "big CPU system" I have in my house has a PCI Radeon 9000 installed,
and I use it fairly regularly.

> 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. Although I
> guess a simpler option is not to touch anything.
> 
> Marek