4 ms·
In general, pretty great on FreeBSD. You have nVidia binary blob 32-bit and 64-bit drivers. The OpenGL performance equals Linux and Windows. The blobs aren't av
by byuu 12y ago
In general, pretty great on FreeBSD. You have nVidia binary blob 32-bit and 64-bit drivers. The OpenGL performance equals Linux and Windows. The blobs aren't available for the other BSDs. There's some trouble at the moment due to the move to KMS and the new VT, with a new Xorg and new AMD/Intel drivers for it. Some consternation over when/if nVidia will release FreeBSD/KMS drivers. Supposedly the Intel driver is a bit behind, but nobody's running Intel video for graphics performance. Nouveau isn't available due to KMS breakage.
But to me, the focus should not be on trying to run the latest games. Linux isn't replacing Windows for gaming, so there's no chance FreeBSD is going to.
I'm running a 2560x1600 display on VESA, and after a few MTRR tweaks, it's more than fast enough (I can push over 100 full frames per second), even for watching video and playing 2D games. The only thing missing is Vsync support in the protocol. And what I get in return is never seeing another graphics driver crashing my entire system (because we're still stuck with monolithic kernels running video card drivers in ring 0 in 2014.)
I would say, get a nice desktop up using only a frame buffer with maximum bandwidth possible. Then if people want to run an EGL context, they can render 3D stuff to a buffer, and blit that into a window, or do a fullscreen EGL app that controls the display. But that should be entirely optional and only used where needed. The BSDs are server OSes, so I think this is acceptable to favor stability over performance.
The best part would be that this could run on (top of, if necessary) any system. Windows, OS X, DOS, Haiku, Minix, you name it. If you could write pixels to a screen, you could run the display server.
- clarry 12y ago> I'm running a 2560x1600 display on VESA How does that work? For long I've lamented the fact that VESA/VBE caps at some not-particularly-high 4:3 resolution. Also, the lack of DMA & vsync... Having a simple way to drive modern displays at a reasonable speed would be nice. The complexity of the accelerated graphics stack is depressing... and I don't really want or need it. Hell, I didn't need it ten or twenty years ago, so why now.
- byuu 12y ago> For long I've lamented the fact that VESA/VBE caps at some not-particularly-high 4:3 resolution. The official VESA modes are all 4:3 (and 5:4 for 1280x1024). But most video cards have non-standard modes. These modes are usually just more 4:3 variants or really low-res 16:9 (1366x768, gee thanks!) By some miracle, my PNY GTX 760 OC 2GB card had a 2560x1600x16bpp custom mode. No 32bpp mode, but in this case I'll take half the bandwidth requirements (twice the speed) for the extra color anyway. The way this works behind the scenes is that the VESA VBE is part of the VBIOS image. This BIOS contains 16-bit instructions that poke the video card into video modes based on a table. Nowadays, 64-bit OSes just emulate the VBIOS instructions to set the video mode. Yet unfortunately none of them are proactive enough to let you specify your own modified VBIOS file to use in substitute (like you can with EDID) Some people have had luck hacking the VBIOS and adding in their monitor modes, and flashing it back to the card. However, gaining that write access can be difficult, and often times these files are now compressed and/or encrypted. > Having a simple way to drive modern displays at a reasonable speed would be nice. God yes. I am so sick of the ridiculous complexity of everything these days. I miss the ease of working with serial, PS2, gamepad ports, SB16 cards, and VESA. Nowadays you need a team of 40 engineers to support the 10 USB variants (UHCI, EHCI, OHCI, XHCI, etc) just to poll a damned keyboard. This stuff really cripples the chances for any hobbyists to ever come up with a new, breakaway, successful OS. I doubt Linux would ever take off if it had to start in today's SecureBoot / long-mode / SATA / RAID / USB3 / Wifi / binary-blob-graphics world. A simple frame buffer with page flipping or Vsync really is enough to do pretty much anything 2D-based you'd want to. And at the rate CPUs are gaining cores, I suspect we could even pull of some really rudimentary software 3D rendering, too (not MESA, that tries too hard to emulate and is ungodly slow.)
- clarry 12y ago> And at the rate CPUs are gaining cores, I suspect we could even pull of some really rudimentary software 3D rendering Indeed we can; we could long ago. I think of that when I play games like Doom and Quake (which is often). They look awesome, they were software rendered. And to think that the effort on software renderers was more or less abandoned around when Unreal came out in 1998 -- that was pretty much the last FPS engine to have an advanced software mode (which looked amazing), and it worked for me back then since I didn't have a 3D accelerator. Where would we be at if that effort had continued for the next 16 years?