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

Eric Anholt eric at anholt.net
Wed Dec 4 17:37:58 UTC 2019


On Tue, Dec 3, 2019 at 10:48 PM Marek Olšák <maraeo at gmail.com> 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.

So just go do that!  Seriously, just stuff the state structs in the
Mesa context and maintain them as we go, the overhead for classic will
be low enough.  We're going to want to track the raw-style state
anyway for glGet() and all our validation, so it's not like we're
going to be garbage collecting a ton of stuff by forking out classic
drivers.

> 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.

I would love to see someone pick up my nir-to-tgsi branch (now 5 years
old?) and run with it.


More information about the mesa-dev mailing list