<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2024 at 12:30 PM Adam Jackson <<a href="mailto:ajax@redhat.com">ajax@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2024 at 10:20 AM Erik Faye-Lund <<a href="mailto:erik.faye-lund@collabora.com" target="_blank">erik.faye-lund@collabora.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When we did Amber, we had a lot better reason to do so than "these<br>
drivers cause pain when doing big tree updates". The maintenance burden<br>
imposed by the drivers proposed for removal here is much, much smaller,<br>
and doesn't really let us massively clean up things in a way comparable<br>
to last time.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>~Faith <br></div></div></div>