time for amber2 branch?

Faith Ekstrand faith at gfxstrand.net
Thu Jun 20 19:03:52 UTC 2024


On Thu, Jun 20, 2024 at 12:30 PM Adam Jackson <ajax at redhat.com> wrote:

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

Same. I kinda think the next major cut will be when we go Vulkan-only and
leave Zink and a bunch of legacy drivers in a GL branch. That's probably
not going to happen for another 5 years at least.

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


More information about the mesa-dev mailing list