Why has the Linux graphics stack historically been slower than Windows'? Is it because Linux' is "over-engineered" in comparison? How can Linux learn from Windows in this case?
I forgot to post images damn it this isn't a flood I deleted the other thread
Other urls found in this thread:
blenderartists.org
en.wikipedia.org
en.wikipedia.org
en.wikipedia.org
en.m.wikipedia.org
kernel.org
ummon.eu
stackoverflow.com
cubieforums.com
gist.github.com
gamedev.net
twitter.com
A combination of only entry level and hobbyist developers working on it for a portfolio. And also because as entry/hobbyist's they were not allowed access to design sheets and ISA manuals meaning they had to guess their way through creating drivers.
This just exemplifies how more performant *Nix drivers are compared to windows. Because guessing their way through the opengl to isa calls and guessing the isa calls themselves they are in comparable performance to windows drivers.
The only thing to learn from windows is that the corperations are greedy fuckfaces who don't want you to be in control of your own hardware.
That really doesn't explain why even proprietary drivers have historically been slower with Linux, however
Properiatary drivers are not expected to be used in a consumer setting on *nix. Nvidia and AMD, with their quadro and pro lines respectively, have targeted governments and coperations. (((Their))) usage of these laptops is as a video proccessor and editor, small map programs, proccessing huge amounts of data, and the usual LEO and accelerated cracking shenanagins.
Therefore they do not optimize for games as much as they do invest into the likes of openCL and CUDA.
This is yet another reason why it is so amazing to have even comparable performance on opengl applications on *nix.
I should clarify. Usually governments and coporations prefer laptops for mobility as they work. There are exceptions but at that point nvidia and AMD just optimize for the specific desktop GPU's being bought in mass.
but even GPGPU operations have been found to be faster under Windows, surely there must be something else to it.
Where is your proof faggot? I was always under the presumption that openCL apps ran signifigantly faster with *nix types. CUDA has comparable or very slightly improved performance on windows historically. But *nix type computers are better for proccessing large amounts of data because no NTFS filesystem garbage amoungst many other things.
Proofs? GPGPU is usually faster or same on Linux for both CUDA and OpenCL. Take Blender for example, 100% render time decrease in Linux vs Windows.
blenderartists.org
There is reason why most VFX studios use Linux for rendering, it's just faster, so clearly problem is not in graphics stack but elsewhere.
Not that user but all of the non-ASIC GPU memecoin farms run windows. Guess that's just because of drivers though.
Or more specifically the chinks designing those ASIC's serial layer of communication only ever write windows drivers for them. This is because most of china uses pirated windows XP computers. Hence the binary compatibility with windows for chink made ASIC's.
There is also the fact most chinks wouldn't know how to use linux or a *BSD because their government would actively block such libre software. IDK why chinks prefer windows XP honestly besides it just works. Any chinamen wana chime in?
Because we tried to copy ancient shit from Xerox PARC and also put things that needed to be in the kernel in userspace. The former was out of laziness and that the community had zero experience with 'multimedia' back then. The latter was a combo of laziness and Linus not wanting to deal with sound/video in the kernel. That was back when Linus was autistically opposed to a lot of important things, like threads.
dohoho, no. It's a miracle the Linux drivers even work. And OpenCL is often slower than CUDA, but it depends on the specifics of what you're writing.
linux gfx stack was designed by neanderthals
thank god Vulkan is coming around
But Vulkan wont replace current graphics stack present in Linux. Vulkan is just a rendering API like OpenGL or DirectX.
Ehhh, it will significantly reduce the amount of processing done in the driver itself. So sure, it won't reorder the stack, but it will help make it less relevant.
What part of it is overengineered? The drm have worse performance but we lose more kraft with the driver quality so i don't bother with it.
Vulkan does absolutely nothing to improve Linux's mess.
I don't get people who play games on Linux. I have a pretty decent PC but games I can play at 60fps on Windows I get about 20 on Linux with constant drops. Only Source games work half decent.
It's nice to have less spyware.
This might be highly subjective question, but are there any graphically intensive games that are worth playing right now? Popular multiplayer games usually have horrible community e.g. Dota 2, CS:GO...
The "People's" Republic of Chinks has banned Microsoft Windows on government computers. The Chink government has used a state-developed chink version of Red Hat for many years. Unfortunately, the government only cares about its own software freedoms and does nothing to free the people from Microsoft's shackles.
>(((redhat)))
So they installed one of the few backdoored linux systems. Nice job chinkland you traded microscam for (((cianiggers))). Atleast they get cheap support when stuff (((breaks))).
Joke's on them, the backdoors are in the processor, now.
The newest deus ex and hitman both work on Linux and look pretty neat. you also have the metro games and X series though that one taxes the machine through the complexity and scope of itself not graphical fidelity.
That's why chinks are trying to make their own.
en.wikipedia.org
en.wikipedia.org
Because GPUs are complex as fuck and manpower was always lacking to tackle them. Both on the open-source drivers front (which usually struggled to make basic features work, they never got to the point of worrying about speed) and proprietary blob front (because low market share).
Because it doesn't render fonts in the kernel and there's actual memory protection in the drivers (except nvidia, who threw an autistic shrieking tantrum when webgl was introduced)
What file in /dev is this?
Mac OSX also has font rendering in the kernel. But the design paradigms aren't quite the same as Linux either since Linux is much more of a purist monolithic kernel while Windows and OSX aren't "hybrid" kernel marketing buzzterms aside
This guarantees that there's now a magic packet backdoor in Intel's ethernet chips. Those things are powered even when the machine is off and have access to RAM without going through the processor.
I know FreeBSD used to be the OS to pick if you wanted graphics performance, I'm assuming this is still true given the video game console makers still using it as well as all those digital render farms.
>en.wikipedia.org
Getting a redlink
en.wikipedia.org
I understand the windows grpahics system but I have never understood the linux graphics system, on the API level I can do GLX graphics and get openGL working, but thats it, while in windows I know how to use winGDI and that on older versions of windows and DOS you just call the bios interrupt, and get the raw framebuffer, but how do you get a framebuffer on linux? Now, I know that windows is more closed down and you have to do all of your graphics though GDI, but linux is supposed to be more open right? So why cant I do graphics from console mode, instead I have to do it with X as my middle man, so its not very desirable. I get that in windows you have the GDI middle man, but since linux is supposed to be more "open", I would expect that you could obtain a raw framebuffer as a standard kernel or OS feature (and not SVGAlib, which, doesnt even work on modern systems) and it dissapoints me a lot because I would think that linux is better for the kind of programming I care about, but its literally the same as windows just with documentation that's more spotty. Now, I heard BSD is nicer for this, which is something I want to look into, because my friend said that it lets you have framebuffers, instead of talking through the X server crap.
Linux lets you access the raw framebuffer on a virtual terminal. A library that helps with this that you should look into is DirectFB.
There's also several image viewers and such that can run on linux framebuffers as well.
en.m.wikipedia.org
SDL, GTK and Qt all have raw framebuffer support, as well as MPlayer (video player) and links (web browser).
Then again, why the fuck aren't you simply writing your own protected mode/EFI application?
Thanks for the help, im just really looking for the docs about how to acess the framebuffer, because some of the literature on it is confusing. So, lets say I start using the API described here: kernel.org
ummon.eu
Is this only for drivers (those are implemented as kernel modules, right?) or can I write userland programs using these API's? It's unclear but the next time that I work on linux, I will have to try this out. Thanks for the useful reply.
can you explain "EFI application" to me? I'm trying to stay in the userland of Operating systems.
The former url points to a driver's implementer doc. It's probably to write your own framebuffer drivers (if you didn't know, the linux text-mode console works on a "real" video mode, instead of a text-only video mode).
The latter url seems to contain a proper example program, but I'm not sure how correct it is.
Your best bet otherwise is looking into the SDL souce code, or simply using SDL directly in framebuffer mode. This way, you don't have the X middle-man, but you still have a pretty good library for your convenience.
I mentioned an EFI application, because what you're looking into isn't really to make anything anyone else will use, but rather tinker around. UEFI is a low-level API that replaces and expands BIOS. With it, you can easily set the video mode you want, get raw screen access, get raw hard drive access, and you get good libraries to access filesystems, external devices and even the network. All this, without needing to have an actual kernel running, and without the need to figure out the mess that is BIOS (including all it's vendor-specific corner cases and differences), and set up 64bit long-mode yourself, as well as write keyboard and filesystem drivers and such.
The only thing you'd need is a computer with UEFI, and a USB drive with a FAT32 filesystem to boot your program from.
This isnt true, I plan on writing games that use software rendering in the future, and I want people to play those games, so I want to be in userland. I think its funny that linux is so badly documented when it comes to this that lots of support suggestions are "read the SDL source code", ( Lots of those when asking questions about Xlib ). An EFI program sounds pretty cool though, I wouldn't mind writing a port for that sometime. I guess I will read the SDL source code now, thanks for pointing me in the right direction.
If you want to make a game that people will play, you do not want people to have to switch to a virtual terminal where X isn't running to run your game. If everyone who will use your game on linux will run on X, then please, oh please just use X. Even better, since it's a game, just use SDL and forget whatever OS or display server the user is running, be it windows, linux, Xorg, wayland or apparently even framebuffers. You can very easily manipulate the raw pixels with SDL if you *really* want to, but why not take advantage of the hardware you're running on, through SDL?
Documentation is actually pretty hard to write (outside of API docs). You never really know what the user expects to learn from it, and what to bring to the front, and what kind of tutorials/examples to write.
FLOSS benefits from this with the fact that you can just read the code for what you need to know, provided the code is readable and properly structured. This allows the actual users to write documentation for the things they actually find important.
This, sadly also means that least-used and more arcane features are usually barely documented, which means you'll have to run around in IRC channels and forums of interest to find your answers.
It's not perfect, it's just different, and it'll take a bit to get used to. Just be happy you at least have some code (and that SDL is actually pretty readable), because there's a ton of shit that doesn't have either.
The x86 platform as a whole, for example, is scarcely documented except for the processor which has so many useless pages about it you'll never find what you're looking for.
This all said, I decided to google "linux framebuffer examples". These came up:
stackoverflow.com
cubieforums.com
gist.github.com
All three seem like exactly what you're looking for.
I already use X, and win32, by the way SDL is not sufficient for what I want to do. Webm related is not possible using SDL in win32, this is because you have to fight winAPI for this behavior. The point of programming for me is not to "forget" what OS or display server the user is running, but to try and do the opposite.
Vid related is not the game I want to make with a framebuffer, its just an example.
GNU/linux
Because most of the GNU/linux users a servers admin.
They don't need graphical bloats to manage a server.
Because Nvidia and AMD are doing it for ==MUH GAMES==
This
This again
What behavior? I'm unsure what you're referring to. You're doing software rendering of a spinning thing and it somehow has something to do with dragging a window? How is it any different from doing the same by manipulating the raw pixels in SDL?
The "opposite" would be either force the user to use whatever you programmed it for, or port your program to everything you can think of.
If you start dragging the window around in windows, windows will automatically freeze the window, meaning that execution will be blocked and the window wont update. This isn't software rendered, its done with vulkan, the point is that it tries to block execution and you have to do a weird workaround to get past this limitation. Thats the difference. What I mean by the opposite is that I enjoy writing platform specific code, and knowing about how other platforms work, and how to tune my ports to take advantage of them. See here for more about the issue with winapi: gamedev.net
Oh, that's nice. I'm unsure why that'd be of any importance for a game, but if you enjoy that, go ahead.
Just keep in mind that when porting to Linux, well, you're going to have to put up with Xlib or use whatever glue you think suits your style.
In the end, the answer to your original question has been given: Yes, you can access framebuffers in Linux directly. But if you want people to just be able to run your game "normally", you're going to have to use X, since that's what most people use on Linux, and/or Wayland in the future. Vulkan would hopefully work the same, though.
Now for some shitty philosiphical rambling of mine:
Historically, games didn't run on actual Operating Systems. At best you'd get a BIOS or DOS-like API and that was it, or you'd get a library to just directly interface with the hardware.
Games would then have to implement their own version of a user interface: The menus, the keyboard, the HUD and all that stuff.
Operating Systems are made to provide a user interface to run a lot of programs in, and to provide those programs with all the things they need to provide a user interface, be it graphical or text-mode.
Thing is, even though games now run on Operating Systems, they still tend to reimplement their own user interface. That is often because the game "is" the interface, and because the interface has to be different depending on the game, to provide the functionality the game needs. Yes, it'd still be possible to use the Operating System's interfaces, and adapt them to your needs, but it just isn't as convenient, especially when going cross-platform.
Since games provide their own user interface, and draw most of everything on their own, they barely even need the Operating System. With just a screen to draw on, a way to load files, a way to reproduce sounds, and a way to get input from the user, you'd already get very far in creating a game.
This is why I find it stupid to try to deal with the Operating System you're running on if you're making a game. SDL is a very simple library, that provides you with all you need to create a game, and additionally gives you a lot of optimization by using the hardware to it's fullest. Since games rely very little on the Operating System, a game can almost be fully written in SDL, and SDL itself is very easy to port to new platforms (and has been done so numerous times). This grants you a lot of portability, which is a really nice bonus.
Oh, it already has a working linux port. The only part that doesn't work is vulkan because i haven't been able to work on that on a computer that can run vulkan programs, but I have the OpenGL renderer ported.
I think you're absolutely correct about how games interact with operating systems, in that they are like an OS within an OS, but, writing platform specific code is needed to squeeze all the features you might want. X windows and Win32 are actually implemented in very similar ways, so there was no fundamental difference in the structure of my program's linux port, because X works so similarly to windows. But its true that in game programming, the OS can get in the way a lot.
Note that a lot of 'optimizing for games' consists of literally overriding those games programmers own instructions. Game devs write shit that runs slow, so nvidia(I dont know if amd does this as well) explicitly changes those games behavior to make them faster.
I actually really miss the days, back when the first windowing environments came out, when games integrated into the native GUI like other applications, allowing players to fit it into their preferred style of use.
Nowadays, even something as simple as using larger or multiple monitors is barely supported even by the most PC-native strategy and simulator games.
Was that integrated in the game or did someone pick the name?
can I pci pass through play games on Linux and then also use my dualshock 4 controller on the game in the vm? even if no native ds4 support and I need to get some program to make it useable?
If you have two GFX cards you can use the secondary one for GPU passthrough and USB (i guess) passthrough for your controller.
I think USB passthrough might require a separate host adapter for some low-level stuff, like sound does.