# Should graphics be a topic of rigor in FreeBSD?



## Beastie7 (Jul 3, 2021)

Just a questionnaire to gauge the audience here. Much like networking (TCP/IP) and storage (UFS|GEOM/ZFS) have been highly underlined historically. Some examples I have in mind would be display stuff (touch or kb/m), GPU compute, graphical applications (ie gaming), native BSD drivers (akin to iflib), etc. I think this would be a great opportunity for FreeBSD to be a more usable system. What do you think? thoughts?


----------



## Phishfry (Jul 3, 2021)

My opinion is you can't make open source developers do anything. They have to want it.
I am quite happy having a FreeBSD desktop. That's as far as my concern goes.
GPU Compute and Gaming don't interest me.
I do have a stack of tablets with no evdev working. So that might qualify.
Truth is if I cared I would be running Linux on them. I have no real need for a tablet or touch.
I grew up on digitizer tablet and pucks.

What worries me the most is having working browsers on FreeBSD. They are dropping like flies.


----------



## astyle (Jul 3, 2021)

Yeah, I think that graphics stack on FreeBSD is rather suffering from lack of attention. I am interested in getting GPU computing going under FreeBSD. Graphics acceleration for video players like VLC is one thing, and Blender renders would really benefit, too. Marazmista's radeon-profile and GPU benchmarking/overclocking are of interest to me.


----------



## Vull (Jul 3, 2021)

I'm happy enough with what we have already. I'm mainly here for the server capabilities of FreeBSD. I like the flexibility of being able to install a compact efficient OS in less than 2 GB of disk space, then configuring it in whatever way suits my needs.

The MATE desktop is more than enough for my purposes. That said, I've always enjoyed playing around with KDE, which has been an available option ever since I first installed FreeBSD from the 4 Walnut Creek CDs which came with the Complete FreeBSD book by Greg Lehey, which I bought at Staple's office supply store way back in the '90s. I think FreeBSD is doing a great job of being what, it seems, it was always intended to be.


----------



## Alain De Vos (Jul 3, 2021)

Intel, amd or nvidia ?


----------



## sidetone (Jul 3, 2021)

As for graphics, it's good enough. FreeBSD made great strides. It will be a while before Wayland parts replace parts of Xorg, then hopefully it gets better and less complicated. Cleaning up Gtk and Gnome related bloat would go a long way, but there's stubbornness around that.

It used to be, oh, harddisk space is cheap. But compiling time was still cut down by hours, just by removing bloat, and the programs ran faster, and be more reproducible. So, if harddisk space is cheap, I want that for storage, maybe sitting around, redundancy and for what's needed, not bloat, increased compile times, unnecessary install conflicts, inconsistent updates and crashing programs.

Graphics isn't a problem, unless you're playing the latest action PC game.


Phishfry said:


> What worries me the most is having working browsers on FreeBSD. They are dropping like flies.


Palemoon and the associated email client without Gecko. Firefox and Thunderbird need only gtk3, but they rely on gtk2 because of some mixed up code. For most, including I, gtk2 and gtk3 are needed anyway, but it shows that the code is a mess, when it pulls in a dependency in order to function that it doesn't need.


----------



## Phishfry (Jul 3, 2021)

We recently lost www/falkon and www/otter-browser to dependencies. They were nice lite browsers.
I recently had a requirement to use Chrome and I didn't realize we have no chromium.


----------



## Alain De Vos (Jul 3, 2021)

I think you lost them to python2 build. But ok firefox will do. It has no python2 dependencies or qt5-webengine.
Note : even Chromium has some weird dependencies ...


----------



## richardtoohey2 (Jul 4, 2021)

Vull said:


> I'm happy enough with what we have already. I'm mainly here for the server capabilities of FreeBSD. I like the flexibility of being able to install a compact efficient OS in less than 2 GB of disk space, then configuring it in whatever way suits my needs.


+1 here.  But yes, concerned about the narrowing choices generally in technology with hardware, browsers, walled gardens/DRM etc.  But at the same time guilty of lazy pleasures like iDevices and Netflix and Amazon etc.


----------



## Deleted member 30996 (Jul 4, 2021)

My newest machines are 2008 Thinkpad W520's that use Optimus and that's been working for me without any tinkering since 12.0 IIRC.

I voted yes because it should offer support for the graphics it's able to, all things considered. 

I just converted this one to FreeBSD from Win10Pro because it was my gaming box and stayed offline. I haven't played computer games in two years or have any interest in it anymore. 

I haven't even updated to the newest nvidia drivers, since everything is running like an atomic clock.


----------



## cptcrunch91 (Jul 4, 2021)

In my opinion, the complexity of graphics, software/gaming dependencies make it a tradeoff. The amount of time and code dependencies needed to support complex graphics ( and the software that requires complex graphics ) detracts from effort spent making a solid system.

I would prefer a secure and bulletproof system/networking stack and minimal graphics, rather than a mediocre/inconsistent system stack and high performance graphics.

I mainly am interested in FreeBSD as a server and hypervisor. So, as long as I can display a nice resolution XFCE or KDE desktop, I am pretty happy.


----------



## Geezer (Jul 4, 2021)

Graphics should not be mandatory, but definitely should be fully functional.

Now Freebsd has reached a stage where graphics is easily usable, and with a few quirks, as good as any other system.

I am glad I can use Freebsd as either or both;

purely as server where graphics is redundant or frivolous,
as a functional desktop and everyday environment.
Why should there be a question?


----------



## Alain De Vos (Jul 4, 2021)

It's not linux-mint ?


----------



## Beastie7 (Jul 4, 2021)

Alain De Vos said:


> Intel, amd or nvidia ?



Any. This could include ARM based GPUs, or any emerging GPUs. I envision a framework where one can just re-use code to create new drivers and omit features you don't need dynamically. See iflib and I/Okit.



Geezer said:


> Why should there be a question?



Because such functionality relies on chasing upstream that FreeBSD has no control over. DRM itself is bad design IMO too.

Case in point from this article. Imagine all the duplicate feature gunk from each vendor because of it.

Even some Linux users understand it's brokenness.








Phishfry said:


> What worries me the most is having working browsers on FreeBSD. They are dropping like flies.



Agreed. It's incredibly frustrating how rigid software is nowadays. Using Redhat a controlled toolkit to render it's UI is just a dumb decision.


----------



## Alain De Vos (Jul 4, 2021)

These decisions are basically lock-ins.


----------



## Beastie7 (Jul 4, 2021)

cptcrunch91 said:


> In my opinion, the complexity of graphics, software/gaming dependencies make it a tradeoff. The amount of time and code dependencies needed to support complex graphics ( and the software that requires complex graphics ) detracts from effort spent making a solid system.
> 
> I would prefer a secure and bulletproof system/networking stack and minimal graphics, rather than a mediocre/inconsistent system stack and high performance graphics.
> 
> I mainly am interested in FreeBSD as a server and hypervisor. So, as long as I can display a nice resolution XFCE or KDE desktop, I am pretty happy.


Fair enough. I think the same reasoning can be applied to file systems too. GEOM was created to solve a specific problem. With a native graphics ecosystem we can take our path on things. Maybe I’m thinking too intrinsically about it, but I like the idea of not to having to depend on Linux for our basic needs. Just research and build.


----------



## Alain De Vos (Jul 4, 2021)

Aren't the accelerated drivers just the linux packages ported to freebsd ?


----------



## Beastie7 (Jul 4, 2021)

It goes through the LinuxKPI, another support layer, like the Linuxulator. It's actually intelligent stuff, but DRM itself needs to die in a giant raging ball of fire.


----------



## Alain De Vos (Jul 4, 2021)

For that something else must raise from the ashes ?. Question what could it be ?


----------



## tingo (Jul 4, 2021)

Obligatory xkcd https://xkcd.com/927/


----------



## Beastie7 (Jul 4, 2021)

Luckily we just have one base system, and one community.


----------



## CuatroTorres (Jul 4, 2021)

Yes as long as the web says _FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms._ I think drm-kmod came to fix that.

_Off-topic:_ There is a lack of a community in the main languages, which may be a symptom of their moderate popularity.


----------



## mer (Jul 4, 2021)

Would it be nice if there was a comprehensive native graphics stack for the BSDs?  Yes.

But, writing device drivers is easiest with documentation.  Yes, you can reverse engineer, but it's not easy.
Documentation for current hardware is difficult to obtain legally.  Most companies want you to sign NDAs with onerous penalties and will cost you big bucks. 

The manufacturer could write drivers, some do as sample, some are actually trying to be nicer to OpenSource (Linux, BSDs, etc), but I'd bet a coffee that the latest Linux driver for Intel/Nvidia/AMD lags behind the latest Windows/Mac, simply because of money.

Then there is the issue of License.  Will Nvidia provide documentation so someone could write a full featured up to date driver under BSD-3Clause?  I'd say "not likely".
The Linux drivers that make up drm-kmod and the linuxkpi are about the best documentation we can get but they will still lag.


----------



## Alain De Vos (Jul 4, 2021)

I don't mind loading a blob for my video or audio card.
It is bizar companies like Nvidia are difficult to convince of an open standard/library.


----------



## emko (Jul 4, 2021)

I said "meh I don't care" because yes, on one hand that would be awesome. FreeBSD has a bit limited use for me in its present form. On the other hand it could become a bloated behemoth.

I need a good support of my GPU for my graphical desktop use case:
- When I connect a flash disk, I expect it to automount
- I expect a 3D game to work
- When I connect even a rare piece of hardware (e.g. musical hardware) I expect it to work out-of-the-box
- I expect my bluetooth headphones to work out of the box with some easy graphical application to connect to it
- When I connect old-style wired headphones to a front panel of my PC, I expect the sound output to be automagically switched there
etc.

This, unfortunately, drags a lot of bloat with it. FreeBSD would became what Ubuntu or Windows/MacOS are nowadays. Hm, not sure I want that.

I praise FreeBSD to be a very coherent and minimalistic system which works for me as a server and as a workstation for programming / data analysis. For the latter use case I really need just Openbox, Firefox, Python, C, Lisp ... and a good IDE (vscode does the job, PyCharm worked for me in the past on FreeBSD, others are probably available too ... and there is Emacs if there are not).

Great graphical support is not a priority for FreeBSD for me.


----------



## Beastie7 (Jul 4, 2021)

mer said:


> Would it be nice if there was a comprehensive native graphics stack for the BSDs?  Yes.
> 
> But, writing device drivers is easiest with documentation.  Yes, you can reverse engineer, but it's not easy.
> Documentation for current hardware is difficult to obtain legally.  Most companies want you to sign NDAs with onerous penalties and will cost you big bucks.
> ...



I believe AMD provides Arch/ISA documentation for their various GPUs. Nvidia.. a pipe dream.


----------



## Phishfry (Jul 4, 2021)

Alain De Vos said:


> It's not linux-mint ?


But their whole existence is because Gnome3 sucked so bad users fled (to Cinnamon).
Plus they dumbed it down to look like Windows. So easy for migrating users.



Beastie7 said:


> DRM itself needs to die in a giant raging ball of fire.


I agree. My reasoning is due to them dropping 32-bit architecture support.
This is a Windows jerk move. Just EOL shit because you need more $$$$.
They could afford to continue 32 bit support but chose not to.
Look at Nvidia legacy drivers. They work with very old cards. 32 bit support is gone their too though.

That is what I dislike. We are being controlled by the manufacturers support window.


----------



## astyle (Jul 4, 2021)

Beastie7 said:


> I believe AMD provides Arch/ISA documentation for their various GPUs. Nvidia.. a pipe dream.


This is partly why I'm an AMD fanboi... GPU prices are coming down, though, and right now, team green is on par with team red in terms of flagship pricing. FreeBSD, however, is famous for being able to play well with NVidia...


----------



## sidetone (Jul 4, 2021)

Less hardware capability would be needed to achieve more, if code/ports are more efficient.


mer said:


> Would it be nice if there was a comprehensive native graphics stack for the BSDs? Yes.


AMD has an opensource graphics stack for its cards.

https://gpuopen.com/ is by AMD.


mer said:


> But, writing device drivers is easiest with documentation. Yes, you can reverse engineer, but it's not easy.
> Documentation for current hardware is difficult to obtain legally.


I can do an good job with documenting, as in some How-to posts and Wikis. However, I'm unsure what someone who doesn't know C can do in regards to that. I would have to know prerequisites to understand something in order to write about it. Another topic to document suits my abilities and fascinations better.

For what I'm able to set up myself, I try different file settings to see what works, and what doesn't, to document based on logic. For a few topics, I barely scratch the surface and tell about them to clear up confusions and misunderstandings, while I'm unable to set them up myself, after reading about them and trying. The topics that I understand the surface, but don't understand the details, are the ones I'll write short entries on in the forums. The only purpose for this would be if there's a lack of understanding and misconceptions about that topic.


Alain De Vos said:


> It's not linux-mint ?





Phishfry said:


> But their whole existence is because Gnome3 sucked so bad users fled.


I wish BSD and Apache code would be underlying everything, then trimmed down GNU code can be on top, without duplications. We could take a model from efficient Linux distributions for ports.


astyle said:


> I am interested in getting GPU computing going under FreeBSD.


That would be cool, but it sounds like too much to ask. If I needed that, I'll use a dedicated operating system for it, even if it's Windows or Linux. The way I see that happening, is if a company has a good reason to do that and release it under Apache. Even porting GPL code would be great for those purposes.


----------



## CuatroTorres (Jul 5, 2021)

sidetone said:


> I'm unsure what someone who doesn't know C can do in regards to that. I would have to know prerequisites to understand something in order to write about it.


Naming a small part of computer fundaments. Trivially typing a scanner or wi-fi driver seems far from reality even to someone who knows C. Exactly.


----------



## SirDice (Jul 5, 2021)

Beastie7 said:


> It's actually intelligent stuff, but DRM itself needs to die in a giant raging ball of fire.


Don't confuse DRM (Digital Rights Management) with DRM (Direct Rendering Management). Yeah, they could have named it better, it's utterly confusing. 






						Direct Rendering Manager - Wikipedia
					






					en.wikipedia.org
				








						Digital rights management - Wikipedia
					






					en.wikipedia.org


----------



## jardows (Jul 5, 2021)

With its solid fundamentals, FreeBSD can be very good for a workstation system.  I feel that some serious graphics support for workloads (Blender, Photo/Video editing, CAD, etc.,) is where FreeBSD graphical support could really shine.  This would require good vendor support (come on AMD - Nvidia can provide decent drivers for us, why can't you?), or a dedicated team to make the open source drivers function well in this way.  Not Linux DRM stuff, but the actual open source drivers available from Intel and AMD.  I don't need great gaming performance on FreeBSD - gamin performance would only be a side benefit, but to use the work part of my graphics cards would be right up where FreeBSD is suited for desktop workstation.


----------



## Alain De Vos (Jul 5, 2021)

And if you can't use nvidia you just use intel or amd.


----------



## Beastie7 (Jul 5, 2021)

SirDice said:


> Don't confuse DRM (Digital Rights Management) with DRM (Direct Rendering Management). Yeah, they could have named it better, it's utterly confusing.
> 
> 
> 
> ...



They're both bad in my book.  It (the linuxulator/LinuxKPI) is intelligence stuff, I meant. Grammar be damned.


----------



## astyle (Aug 12, 2021)

In all fairness, I do think we need a proper graphics section on these forums. I envision that section to be a place to go to for configuring the GPU's in our builds, talk about OpenCL / CUDA, and maybe de-clutter the Multimedia section a bit.


----------



## Deleted member 30996 (Aug 12, 2021)

Beastie7 said:


> Luckily we just have one base system, and one community.


I tried to school the Linux community on how it was at DW earlier today.


----------



## PMc (Aug 12, 2021)

Beastie7 said:


> Fair enough. I think the same reasoning can be applied to file systems too. GEOM was created to solve a specific problem. With a native graphics ecosystem we can take our path on things.


But there is an important difference. The core functions of an OS are

user management
task management
timekeeping & timesharing
file storage
Graphics is not among them, graphics does not belong to the OS. It neither is mandatory on all systems. nor does it fit very well into usual OS design principles. It is rather some special hardware to be managed by those applications that have need for it. And it belongs into ports.

So, anybody can write the port, mandate for putting it into the tree, and then the users can decide if it is useful.

And instead of discussing here, I feel you should actually work on it. Or, at least provide us some concept sheets about how you're going to design it.


----------



## PMc (Aug 12, 2021)

Beastie7 said:


> but DRM itself needs to die in a giant raging ball of fire.


Why? And what is going to replace it?


----------



## mer (Aug 12, 2021)

PMc said:


> Why? And what is going to replace it?


Interesting that if one goes and looks at definitions and such related to DRM/DRI, and you ignore the "Linux" aspect, it's really not any different than say "a VFS for Video Hardware".   Effectively a common interface to different video hardware and different functionality of that hardware.
In theory I could see say the X server really only needing a single "driver" that talks to the DRI/DRM interface to do it's thing.

I'm not taking a position on good or bad, but it is currently a path for support of more modern graphics hardware, given the limited pool of video device driver writers.

If someone tossed enough real money at Nvidia, AMD and others with the goal of "give us device drivers to support the same functionality and performance that you have on Windows 10" I'm sure they would.  But I don't have that kind of money laying around.


----------



## astyle (Aug 13, 2021)

PMc said:


> But there is an important difference. The core functions of an OS are
> 
> user management
> task management
> ...


Core functions of an OS do include management of hardware and user input like typing on a keyboard or touching the screen. USB subsystem is managed by the kernel. User input is also graphics-heavy recently. Based on that, I would conclude that GPU's and graphics in general do belong in the discussion.


----------



## Beastie7 (Aug 13, 2021)

PMc said:


> Graphics is not among them, graphics does not belong to the OS. It neither is mandatory on all systems. nor does it fit very well into usual OS design principles. It is rather some special hardware to be managed by those applications that have need for it. And it belongs into ports.



You could use the same reasoning for any part of base; file systems, ethernet, wifi, USB, whatever. FreeBSD can have it's own graphics stack. The committers just need a way to inherit all current drivers, and X apps against our own homegrown solution without breaking them. I'm not sure what part of X.org is crucial for all apps to function, but the rest of DRM and X.org (BSD/MIT licensed, et al.) could be rewritten for POLA or replaced with something else.



PMc said:


> Why? And what is going to replace it?



Graphics drivers don't belong in the kernel IMO. They should be in userspace as single packages; this eases vendor support and upgradability. Low level GPU management stuff is ok in the kernel as a stable ABI/API that doesn't get touched often. Why the f**k do I have to install ALL drivers as a kmod on my T480 for just one iGPU? It's doesn't make sense to me.

One option I mentioned in my profile posts is KGI.


----------



## PMc (Aug 13, 2021)

astyle said:


> Core functions of an OS do include management of hardware and user input like typing on a keyboard or touching the screen. USB subsystem is managed by the kernel. User input is also graphics-heavy recently. Based on that, I would conclude that GPU's and graphics in general do belong in the discussion.


There are at least two issues:
1. a generic description of such, that can apply to any hardware platform, which may or may not even have a GPU.
2. clusters and exportability. The four basic services of an OS can be exported, that is, an arbitrary cluster of machines can be created, and will appear to the outside as if it were a single system. (The original approach for this was DCE/DFS, which was subsequently hosed by the OpenGroup.)

The tendency here is clearly that the OS moves away from the hardware, in favour of generic rather than specific descriptions and interfaces. If you instead try to support and operate all the specific stuff that is coming up at a fast rate, then you will rater lean towards the hardware, and you will create something that is not much different from e.g the software running an automobile, i.e. not an OS, but a firmware for specific hardware.


----------



## mer (Aug 13, 2021)

Is KGI a viable alternative?  Not from a technical standpoint but from "is it actually alive"

Last update on kgi-project.org "latest news" is from 2009.
Phoronix article from 2011.





						The Kernel Graphics Interface (KGI) Is Effectively Dead - Phoronix
					






					www.phoronix.com


----------



## astyle (Aug 13, 2021)

PMc said:


> There are at least two issues:
> 1. a generic description of such, that can apply to any hardware platform, which may or may not even have a GPU.
> 2. clusters and exportability. The four basic services of an OS can be exported, that is, an arbitrary cluster of machines can be created, and will appear to the outside as if it were a single system. (The original approach for this was DCE/DFS, which was subsequently hosed by the OpenGroup.)
> 
> The tendency here is clearly that the OS moves away from the hardware, in favour of generic rather than specific descriptions and interfaces. If you instead try to support and operate all the specific stuff that is coming up at a fast rate, then you will rater lean towards the hardware, and you will create something that is not much different from e.g the software running an automobile, i.e. not an OS, but a firmware for specific hardware.


Any college-level textbook used for undergraduate courses that teach about OS concepts will mention hardware management as a a basic kernel service. Any GPU requires PCI-e, there's still USB and Bluetooth mice and keyboards - that is not going away any time soon. Hard disks - that's just another piece of hardware, the trend is towards SATA III/IV connections - the kernel needs to manage that, as well. 

Even cloud services have hardware underpinnings - those are merely abstracted away. What you are thinking of is a Chromebook.


----------



## PMc (Aug 13, 2021)

undergrad courses about OS concepts? Didn't exist in my time - you would have to study electrical engineering, and that was all there was.
Chromebook? Urgs. I gave to my mom a MacBook Air, and never regretted that. I'm currently typing on it - the keyboard is horror (I'm used to IBM rs6k keyboards), otherwise everything just works. If you want graphics smoothly integrated, get a MacBook, they already did the job. (They solve the issues by selling the hardware alongside.)
For FreeBSD on IBM GPUs I prefer to compile the drm and kms into the kernel (with loaded modules the version-tag of the kernel-build is useless because anything could be loaded into it, or missing, at a given time). I am not happy that this is no longer working on Rel.13. And, seriously, I do not have a really good idea about how all this should be solved best. I just don't like it. I would indeed prefer the machine to come up on a dumb text-mode terminal (and keep that open for the kernel messages) and then start graphics on a separate, dedicated hi-res screen&monitor. That is how the old CAD stations did it - and one could see the kernel crash messages simply by looking on the dumb terminal. But that's probably too old-fashioned and would not work with your laptop and tablet gadgets. Anyway I failed to do that when I tried: when one monitor outlet is doing graphics, the other follows in. I just hope all this doesnt get even worse in the future.


----------



## obsigna (Aug 14, 2021)

There is a quite old post on Slashdot in 2003, that seems to come from Mike Paquette, explaining "Why Apple didn't use X for the window system", and it seems that Mike Paquette designed/wrote a good part of Quartz, i.e. the X replacement on Mac OS X.

That could be the ToDo-list for a descent FreeBSD graphics engine as well.


----------



## astyle (Aug 14, 2021)

PMc said:


> undergrad courses about OS concepts? Didn't exist in my time - you would have to study electrical engineering, and that was all there was.
> Chromebook? Urgs. I gave to my mom a MacBook Air, and never regretted that. I'm currently typing on it - the keyboard is horror (I'm used to IBM rs6k keyboards), otherwise everything just works. If you want graphics smoothly integrated, get a MacBook, they already did the job. (They solve the issues by selling the hardware alongside.)
> For FreeBSD on IBM GPUs I prefer to compile the drm and kms into the kernel (with loaded modules the version-tag of the kernel-build is useless because anything could be loaded into it, or missing, at a given time). I am not happy that this is no longer working on Rel.13. And, seriously, I do not have a really good idea about how all this should be solved best. I just don't like it. I would indeed prefer the machine to come up on a dumb text-mode terminal (and keep that open for the kernel messages) and then start graphics on a separate, dedicated hi-res screen&monitor. That is how the old CAD stations did it - and one could see the kernel crash messages simply by looking on the dumb terminal. But that's probably too old-fashioned and would not work with your laptop and tablet gadgets. Anyway I failed to do that when I tried: when one monitor outlet is doing graphics, the other follows in. I just hope all this doesnt get even worse in the future.


IBM did not make GPU's. With FreeBSD, compiling graphics/drm-kmod will eventually give you the option to install the sources into /usr/src/ and work exactly the same. Too lazy to dig up the thread where I showed that.

FreeBSD does indeed boot up to a text terminal, and you can see crash messages along the way - all you have to do is NOT start X windows. But even if you do, you can still type `# dmesg` to see the bootup messages and crashes.  Everything you like is still there, and accessible. (You're the one who showed me the shell globbing solution to `# zfs rollback`, after all )

Oh, and Macs are descended from FreeBSD 4.4, BTW... Duh.


----------



## sidetone (Aug 14, 2021)

astyle said:


> I do think we need a proper graphics section on these forums. I envision that section to be a place to go to for configuring the GPU's in our builds, talk about OpenCL / CUDA, and maybe de-clutter the Multimedia section a bit.


There's already "System Hardware" and "Multimedia/Gaming" sections. "System Hardware" for graphics already ties into its intended use for making applications or desktops work in Multimedia or Desktop.

Gaming needs a new section, perhaps they will decide when there's enough threads on it. Graphics as for desktop graphics belongs in Multimedia or maybe System Hardware. It could make sense to have a graphics subsection as long as there's another subsection for audio. Doing so, when there's two sections that cover it, may be too complicated. Using tags is useful for it, as I can treat them like a small category.


----------



## mer (Aug 15, 2021)

astyle said:


> IBM did not make GPU's.


Does the i915 not indicate Intel graphics?
pciconf -lv tells me I've got a "HaswellULT Integrated Graphics Controller" with a vendor of "Intel Corporation".

I'll grant that Intel may have purchased the intellectual property from someone to embedd/integrate into their SoC devices, 
but that still sounds to me like "Intel mages GPUs".  Doesn't some of the Linux work come from folks actually in the employ 
of Intel?

Now "Did Intel make standalone GPUs that third party vendors could use to build a graphics card like Nvidia?"  is a different 
question and I don't know the answer to that off the top of my head.


----------



## astyle (Aug 15, 2021)

mer said:


> Does the i915 not indicate Intel graphics?
> pciconf -lv tells me I've got a "HaswellULT Integrated Graphics Controller" with a vendor of "Intel Corporation".
> 
> I'll grant that Intel may have purchased the intellectual property from someone to embedd/integrate into their SoC devices,
> ...


Don't confuse Intel with IBM.  It is true that 'IBM-compatible PC' back in 1980s meant that it had an Intel 8088, but that's because IBM approached Intel for its 16-bit CPU (which was cheaper than the 32-bit Motorola CPU that was running Apple's computers).

Intel has been making integrated graphics for awhile now, (my Celeron in 2000 already had integrated graphics) but they started making any real noise about their own discrete GPU only this year. And not only does Intel provide some Linux kernel drivers, they even have their own distro (Clear Linux).


----------



## PMc (Aug 18, 2021)

astyle said:


> IBM did not make GPU's.


Sorry, mistake. Should read Intel.



astyle said:


> With FreeBSD, compiling graphics/drm-kmod will eventually give you the option to install the sources into /usr/src/ and work exactly the same. Too lazy to dig up the thread where I showed that.
> FreeBSD does indeed boot up to a text terminal, and you can see crash messages along the way - all you have to do is NOT start X windows.


Yes, because it is the same device that is used as the primary console as well as the graphics screen. I still believe that the most simple and robust approach is to have two entirely different devices for these two things. But then only a few workstation owners would probably like that, while the vast majority of PC users, and even more the laptop and tablet users, have only one screen.


astyle said:


> But even if you do, you can still type `# dmesg` to see the bootup messages and crashes.  Everything you like is still there, and accessible.


They are accessible only as long as the system is still healthy enough to send kernel messages into userland. The fault behaviour that I have often seen is that the graphics screen becomes frozen, then for a while nothing happens, and then reboot. This will happen when e.g. the disk (swap space!) fails to read, and for a bunch of other reasons (mostly related to hardware failures). In these cases usually some printf() from the kernel would still appear on the console, and reading that could be helpful.



astyle said:


> Oh, and Macs are descended from FreeBSD 4.4, BTW... Duh.


Yes. They are mostly Berkeley, and so I can find my way in the console if there is need to (there rarely is). And for anybody who does not want to (or does not have the skill to) do serious maintenance I still don't know anything better to suggest. Obviousely, when you do not or can not DIY, you have to find somebody whom you can pay for it. Is there a better option?


----------



## astyle (Aug 18, 2021)

PMc said:


> They are accessible only as long as the system is still healthy enough to send kernel messages into userland. The fault behaviour that I have often seen is that the graphics screen becomes frozen, then for a while nothing happens, and then reboot. This will happen when e.g. the disk (swap space!) fails to read, and for a bunch of other reasons (mostly related to hardware failures). In these cases usually some printf() from the kernel would still appear on the console, and reading that could be helpful.


/var/crash is where you go read error messages from boot failures. Of course, to make that possible, remove the hard drive that failed to boot, and use a healthy, working computer to mount that drive as read-only.



PMc said:


> I still believe that the most simple and robust approach is to have two entirely different devices for these two things. But then only a few workstation owners would probably like that, while the vast majority of PC users, and even more the laptop and tablet users, have only one screen.


An educated guess on my part is that it's not impossible to pull off with Xorg or even Wayland - if you see your dmesg on Screen0, tell xorg.conf to launch everything on Screen1 (once it gets detected).


----------

