On Sat, Nov 29, 2025 at 06:27:08PM -0500, [email protected] wrote:
> Quoth Noam Preil <[email protected]>:
> >
> > I'm going to respectfully disagree without having ever done any non trivial
> > graphics work: there's multiple examples of drivers that were done by a
> > small group independently over a long period of time.
> >
> > See e.g. asahi working against a hostile vendor.
>
> They're also building on a huge amount of work, often
> commercially sponsored, around the whole linux graphics
> stack.
>
> It's possible to get there, but given that we've got a
> fraction of the people hacking on things... it'll take
> years of incremental work and some real simplifications
> to the design.
FWIW, I concur. On NetBSD, things started to go weird after they had
imported linux kernel related GPU support, the alien code weighting...
50%! of the previous existing code (kernel for all flavors + userland).
And once imported, it was already obsolete because it is a fast moving
target. And it is hugely memory related, and memory is at the core of an
OS, so importing an alien code with an alien memory interface was
doomed.
After fighting to find a way (starting at the KMS or DRM end; then
reverting to the user interface to try to reach the kernel articulation),
I personnally concluded that whether one has to stick to Linux for this
(not try to follow; it is hopeless), or find a totally different way to
do things (I mean the interface between the kernel and the GPUs; what
are the GPUs today can not be changed). And, IMHO, the design has
to start thinking about the kernel---after having found a thread
to what should be done, look at what is existing to sort the pieces
and implement the missing glue.
But, on the other hand, when it comes to 2D, it used to work without
much ado and with not full modern GPUs but in fact VGA (meaning Video
Graphics Array): an image, a clock to master when to send an image to
a display, and a circuitry to feed at the proper time these images to
a display (in fact, there were at some time "vectorial" displays, that
didn't take raster data but vectorial instructions: the
plotters, that took a pen and drew lines; since they were sequential,
they were not limited in the size and complexity of what had to be
drawn---I personnally loved watching the execution, step by step, of the
graphical program).
This is also why, in the mean time, I want to focus on rasterizing
capabilities (taken from METAFONT) and to see how far (and with what
efficiency) one can draw 2D images, including glyphes, with CPU like
cores---and I want to get rid of a PostScript interpreter and even
of other graphics libraries. So if I want to use Plan9 for programming,
TeX writing and rendering or even rendering GIS data (KerGIS), I will
depend on strictly nothing. I'm not doing 3D realtime motion stuff;
neither cryptocurrency mining nor A.I., so...
As usual (but as a French, it is a habit), I'm not trying to obtain
something claimed mandatory, I'm trying to do without.
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mf555ed76295b66bdea37e1a1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
