On 4/12/19 3:45 pm, Jason Ekstrand wrote:
On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie <airl...@gmail.com
<mailto:airl...@gmail.com>> wrote:
On Wed, 4 Dec 2019 at 10:39, Marek Olšák <mar...@gmail.com
<mailto:mar...@gmail.com>> 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.
I'm usually the first person to tell people to stop mucking about with
old hardware and I fear even I think this would be a bit premature.
We've not turned iris on by default yet and I'd really like it to bake
as the default distro driver for a while (maybe a year) before we put
i965 on life-support. If we were having this discussion in another
year's time, I might be in favor of this but, as it currently stands,
I'm not sure this is a good idea.
> 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.
I really don't like this option. For one thing, this means two copies
of code that will get out-of-sync. If we had the classic drivers in
their own branch, we could at least cherry-pick bugfixes back to the
classic branch. However, if we have two copies of everything, our
version control tool can't help us.
The bigger problem is headers. Currently, the GLSL compiler includes
mtypes.h so we would need to somehow separate the GLSL compiler out from
src/mesa/main because we'll have two mtypes.h files. Unfortunately,
GLSL isn't the only thing that includes stuff from src/mesa/main. Our
header situation has been a disaster for years and I'm afraid it hasn't
gotten any better with the addition of src/util. Most people who move
stuff don't actually do due diligence to keep the includes clean and the
result is that I'm pretty sure even the Vulkan drivers are including
src/mesa/main/imports.h. If we have two copies of src/mesa/main and the
headers begin to diverge, it's going to be a total disaster. I would
love to see someone clean this all up properly and I think Mesa would be
better for it. However, it is a LOT of work.
If we did the above cleaning, would I be ok with this approach?
Possibly. However, I suspect it'd end up being the worst of both
worlds. We still have maintenance of effectively two branches and
bugfixes have to be ported. At the same time, we'd still have core
changes to things like the GLSL compiler breaking old drivers so we
wouldn't lighten any of the maintenance burden.
> Option 2 is more acceptable to people who want to keep classic
drivers in the tree and it can be done right now.
These both seem pretty horrible to me right now. Like i965 still
supports a lot of hardware that exists right now even if we move to
iris.
I'm less concerned about the support burden. When it comes to bugfixes,
I feel like most of the bugs on gen7 and earlier hardware at this point
are due to churn in the core and if it lives in a maintenance branch,
we'll stop breaking it. The biggest thing we'd loose would be
additional features that we might get thanks to core changes. The major
ones that come to mind are:
- GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we
haven't due to a lack of testing) > - GL_EXT_direct_state_access (still underway last I knew)
Is already done and enabled for compat profile.
- GL_EXT_gpu_shader4
Core mesa parts are done for this also.
- Compat context support
radeonsi, nouveau and iris all fully enable this. At this point its just
a driver/classic issue to add support. So as with the two other features
above options 1 or 2 will not change the fate of this support.
All four of those are more-or-less software-only features that older
intel drivers could pick up as the core advances. Compat support likely
requires a bit of driver work but it should be doable.
The real question is, "How much do we care?" I can't say I like the
idea of leaving Gen4-7 out in the cold. Again, in a year's time, we
might have most of the above implemented and then it'd be less of a concern.
As per above its only GL_ARB_gl_spirv that would maybe be impacted by
any fork, but that doesn't change between now and a year so delaying a
decision for a year based on this is doesn't seem necessary.
I sorta feel there should be a
3) make life harder for classic drivers and optimise things more for
gallium add more dd.h entrypoints, force the classic drivers to jump
through hoops to degallium.
I'd be interested to see what that would look like. I'm not actually
convinced that it would work if I'm honest. Part of gluing them
together in my mind is deleting dd.h entirely and making the GL state
tracker just call gallium stuff.
There may be a 4th option here: Write a gallium driver for Intel
Gen4-7. Unfortunately, it would be a really hard sell to convince
anyone (myself included) that this is worth anyone's time. Sure, it
might be a fun project, but the engineering effort required to get it to
be as good as i965 is very non-trivial. I think it's tractable and
someone who knows what they're doing would probably be able to get
something working in less than a year if they steal heavily from i965
and iris. However, getting it to the point where performance is no
worse may take longer. While it'd probably be a fun project for
someone, I can't in good conscience say that the mesa/main refactoring
possibilities are enough to justify the effort.
I'm not saying that's a good option. :-) I just thought we should
enumerate it so that it can be shot down.
--Jason
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
