time for amber2 branch?

Adam Jackson ajax at redhat.com
Thu Jun 20 17:30:15 UTC 2024


On Thu, Jun 20, 2024 at 10:20 AM Erik Faye-Lund <
erik.faye-lund at collabora.com> wrote:

> When we did Amber, we had a lot better reason to do so than "these
> drivers cause pain when doing big tree updates". The maintenance burden
> imposed by the drivers proposed for removal here is much, much smaller,
> and doesn't really let us massively clean up things in a way comparable
> to last time.
>

Yeah, amber was primarily about mothballing src/mesa/drivers/ in my
opinion. It happened to correlate well with the GL 1.x vs 2.0 generational
divide, but that was largely because we had slowly migrated all the GL2
hardware to gallium drivers (iris and crocus and i915g and r300g were a lot
of work, let's do remember), so the remaining "classic" drivers were only
the best choice for fixed function hardware. Nice bright line in the sand,
there, between the register bank of an overgrown SGI Indy as your state
vector, and the threat of a Turing-complete shader engine.

I have a harder time finding that line in the sand today. ES3? Compute
shaders? Vulkan 1.0? I'm not sure any of these so fundamentally change the
device programming model, or the baseline API assumptions, that we would
benefit by requiring it of the hardware. I'm happy to be wrong about that!
We're using compute shaders internally in more and more ways, for example,
maybe being able to assume them would be a win. If there's a better design
to be had past some feature level, then by all means let's have that
discussion.

But if the issue is we don't like how many drivers there are then I am
sorry but at some level that is simply the dimension of the problem. Mesa's
breadth of hardware coverage is at the core of its success. You'd be
hard-pressed to find a GLES1 part anymore, but there are brand-new systems
with Mali-400 MP GPUs, and there's no reason the world's finest GLES2
implementation should stop working there.

- ajax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20240620/df52e537/attachment.htm>


More information about the mesa-dev mailing list