If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Announcement
Collapse
No announcement yet.
Mesa Devs Discuss Potentially Dropping Non-Gallium Drivers Or Forking Code For Gallium
Right, and I'm sure that people use the graphics silicon on those CPUs.
To watch YouTube videos.
Which, let's admit, isn't exactly the pinnacle of performance-centric use-cases.
If it's become a maintenance burden, it probably needs to be split off.
Well, I'm using my Haswell in my HTPC and it serves me well to watch HD videos and Prime. I hope that they will support that APU for some time and don't just let it die.
How they're doing it is not mine to decide.
Dropping working drivers for old hardware that still works is fucking moronic.
What the hell is wrong with you people, this is not Windows.
The actual mailing list post is talking about "dropping" them from mainline mesa, and putting them in a separate branch. Given these devices don't really receive useful updates, it's not crazy to put them in a legacy/stable branch, to avoid breakage from improving drivers for newer hardware. So even if this change were to be implemented, it's not as if your device would stop working, I'd imagine distributions would auto-detect which mesa branch your hardware needs.
Dropping working drivers for old hardware that still works is fucking moronic.
What the hell is wrong with you people, this is not Windows.
I believe you misunderstood the proposal. These non-Gallium drivers will not be dropped and disappear, but will live on maintenance mode on a different branch of Mesa. They will be available on your preferred distro, just like today.
I think the title is not as clear as it could be, as they are not planning on dropping all non-gallium drivers, but only the classic ones. For instance radv and anv are non-gallium drivers too and I'm sure won't be dropped.
i965 are 2014 macbooks. Still used in production environments (I know because I'm in this case). Nowadays the hardware renewal is 5+ years.
And as a matter of fact a 10 year old desktop with an r600 GPU is still my main home dev machine... Hardware simply ages well these days.
I'm also using a Thinkpad Haswell notebook of that time which serves me astonishingly well.
I'd be very disappointed if it wouldn't work well on newer distributions anymore and I have to stick to some LTS one with an old Mesa version.
It's a complicated situation. Just droping i965 isn't a solution, but I think it doesn't need to be that performant or super actively developed, since it only applies to old Intel iGPUs. So either really create a non-performant Gallium replacement (still unrealistic) or just seperate i965 as an own driver and remove in that driver all the Gallium stuff.
Last edited by 9Strike; 04 December 2019, 11:15 AM.
Right, and I'm sure that people use the graphics silicon on those CPUs.
To watch YouTube videos.
Which, let's admit, isn't exactly the pinnacle of performance-centric use-cases.
If it's become a maintenance burden, it probably needs to be split off.
i965 are 2014 macbooks. Still used in production environments (I know because I'm in this case). Nowadays the hardware renewal is 5+ years.
And as a matter of fact a 10 year old desktop with an r600 GPU is still my main home dev machine... Hardware simply ages well these days.
Is Gallium3D still relevant with Vulkan and SPIR-V?
Now there is OpenGL over Vulkan, Direct3D over Vulkan, etc. Maybe OpenCL over Vulkan? There is now also Vulkan Compute.
There is generic mode setting, there is GLAMOR.
What use does Gallium3D serve?
Yes, it is until the Whatever to Vulkan layers are as fast as their native counterparts.
Gallium3D is a layer that eases the creation and maintenance of drivers for multiple graphics cards. From the official page:
Compared to existing Linux graphics drivers, Gallium3D will:
Make drivers smaller and simpler.
Current DRI drivers are rather complicated. They're large, contain duplicated code and are burdened with implementing many concepts tightly tied to the OpenGL 1.x/2.x API.
Model modern graphics hardware.
The new driver architecture is an abstraction of modern graphics hardware, rather than an OpenGL->hardware translator. The new driver interface will assume the presence of programmable vertex/fragment shaders and flexible memory objects.
Support multiple graphics APIs.
The reduced OpenGL 3.1+ APIs will be much smaller than OpenGL 1.x/2.x. We'd like a driver model that is API-neutral so that it's not tied to a specific graphics API.
Support multiple operating systems.
Gallium drivers have no OS-specific code (OS-specific code goes into the "winsys/screen" modules) so they're portable to Linux, Windows and other operating systems.
Leave a comment: