Should graphics be a topic of rigor in FreeBSD?

Should graphics be a topic of rigor in FreeBSD?

  • Sure!

    Votes: 24 68.6%

  • No..

    Votes: 7 20.0%

  • Meh, I don't care.

    Votes: 4 11.4%
  • Total voters
    35
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.

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.
Click to expand...

I believe AMD provides Arch/ISA documentation for their various GPUs. Nvidia.. a pipe dream.
 
Alain De Vos said:
It's not linux-mint ?
Click to expand...
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.
Click to expand...
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.
 
Beastie7 said:
I believe AMD provides Arch/ISA documentation for their various GPUs. Nvidia.. a pipe dream.
Click to expand...
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...
 
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.
Click to expand...
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.
Click to expand...
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 ?
Click to expand...
Phishfry said:
But their whole existence is because Gnome3 sucked so bad users fled.
Click to expand...
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.
Click to expand...
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.
 
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.
Click to expand...
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.
 
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.
 
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.
 
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.
Click to expand...
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 said:
Why? And what is going to replace it?
Click to expand...
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.
 
PMc said:
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.
Click to expand...
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.
 
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.
Click to expand...

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?
Click to expand...

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.
 
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.
Click to expand...
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.
 
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.
Click to expand...
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.
 
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.
 
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.
Click to expand...
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 :p)

Oh, and Macs are descended from FreeBSD 4.4, BTW... Duh. :p
 
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.
Click to expand...
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.
 
astyle said:
IBM did not make GPU's.
Click to expand...
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.
 
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,
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.
Click to expand...
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).
 
You must log in or register to reply here.
Back
Top