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

Marek Olšák maraeo at gmail.com
Wed Dec 4 06:48:17 UTC 2019


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

Marek

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20191204/43cda306/attachment-0001.html>


More information about the mesa-dev mailing list