5 ms·

It's not just affecting 3D applications that need OpenGL though. I find it sad that we have no modern standard akin to VESA / VBE -- to get any reasonable grap

by clarry 12y ago

It's not just affecting 3D applications that need OpenGL though. I find it sad that we have no modern standard akin to VESA / VBE -- to get any reasonable graphics at all at your native display resolution, you have to live with an incredibly complicated (and unreliable) graphics stack. Purely CPU based rendering (which was fast enough in the 90s) is no longer a choice really.

rasz_pl 12y ago
SDL
- euank 12y ago
  To expound on this comment: SDL1 defaults to fully software rendered output. You can hack in opengl hardware rendering, but it's fairly common for SDL1 games and such to be fully software rendered and run fine. SDL2 in general is hardware rendered. SDL1 is a good counter-example to "software rendering isn't quick enough anymore". You can make perfectly performant 2d games with sdl1's software rendering... 3d, not so much.
  - tagrun 12y ago
    People usually use SDL1 with OpenGL, and I don't understand what part of it is "hack". Is using OpenGL with a manually created context with tens of platform ifdefs less hacky? Or is EGL/glut/<your favorite wrapper> the one true way of doing things?
    - euank 12y ago
      It's not a hack in that it's held together by tape, precarious, or any such thing; it's a hack because it's going around the back of SDL to do the graphics, even though SDL is supposed to do all the graphics for you. Perhaps my wording was poor. It's more of a hack than in SDL2, where all the SDL functions support hardware rendering with no need to touch OpenGL directly ever. The general point still stands that you can write performant software rendering in SDL1.
- clarry 12y ago
  I am talking about the layers below SDL. The layers that give rise to questions like will the graphics card be supported on my favorite OS if I buy this new computer?. These layers are responsible for detecting and configuring your adapters & monitors, setting the resolution, colour depth, interrupts for vsync, dma for fast frame copying, etc. If these things do not work right, you are in for a sad sad desktop experience, even if your CPU were fast enough to do all the 3D magic you want. Hilariously, using software SDL for your framebuffer (at least on X.org) will be much slower than using OpenGL PBOs. Don't talk about hardware acceleration here -- all we're doing is transferring a finished frame to the display. At this point, we already need much more than the "small" amount of code to implement KMS. Can it break? Yes it can. Does it break? Yes it does. Graphics driver issues are still among the most common problems I witness people struggle with, as far as getting their OS to run smoothly goes.
  - rasz_pl 12y ago
    You use SDL precisely to not care about layers below. SDL 2 will select fastest mechanism to get your software rendered frame to the screen.
    - clarry 12y ago
      I care about the layers below, because they affect people, and they affect me. If the layers below are broken, SDL does not fix it.
datenwolf 12y ago
> to get any reasonable graphics at all at your native display resolution, you have to live with an incredibly complicated (and unreliable) graphics stack. Actually no. OpenGL in no way deals with setting up the display or creating a window on the screen. That has always been the responsibility of the underlying graphics infrastructure (KMS, X11, GDI, etc.) > Purely CPU based rendering (which was fast enough in the 90s) is no longer a choice really. In fact on Linux you can use KMS and the fbdev without making use of OpenGL. Heck, mplayer and ffmpeg even support do operate on the fbdev without going through a windowing system – just naked writes to the graphics framebuffer. > I find it sad that we have no modern standard akin to VESA / VBE Actually there is such a standard, it's called EGL. However EGL by itself is graphics stack agnostic and has been designed to be usable on a wide range of plattforms and graphics infrastructures. So you still have to use some kind of operating system dependent API to open the display device, but then you can use that display device handle with EGL to create abstract surfaces that OpenGL, OpenVG and other API can use to draw on.
- wtallis 12y ago
  EGL is completely different from VBE. VBE was a hardware interface that got you modesetting, a framebuffer, and vsync for any hardware with a single driver that was always there as a fallback. EGL's just an API for applications to talk to the drivers the same way regardless of the window system, but you still need the multitude of drivers. The modern analogue to VBE would be one of the EFI graphics standards, if there weren't two of the damn things, and if anybody would bother properly implementing EFI.
  - datenwolf 12y ago
    True, but it's a single API you can ideally use across a multitude of platforms. That's a huge step forward compared to the plethora of APIs you have/had to deal with: WGL, GLX/X11, AGL, Cocoa, Carbon, etc. From a user space process programmer's perspective the graphics device is some abstract thing, represented by the operating system through a unified API. When it comes to actually setting the framebuffer mode on the hardware, well, in theory it sounds nice to have a common hardware standard like VESA to support this. But then such a low level interface was of little use to user space applications running in memory protected environments. For a long time the X server was required to be SUID root because it drilled a hole through memory protection using ioperm so that it could talk to the graphics chip directly; but talking VESA required some code of the Video BIOS to execute, which technically requires a real mode environment the X server also included a 8086 emulator to run the Video BIOS code in. We had to live with this mess until KMS came along. From a programmer's perspective KMS is the far nicer, much less complex solution, even on the low level. Yes, it requires dedicated code for each kind of GPU, yes there is some code duplication. But the advantage is a huge reduction in complexity: Not interacting with a Video BIOS (or a EFI driver) means, that you don't have to provide a runtime or execution interface in your kernel for them to operate in. Writing a universal emulator/VM, verifying that it always does the correct thing is much harder, that punching down a few dozen lines per GPU class to deal with the low level mode setting stuff.

by clarry 12y ago

rasz_pl 12y ago

SDL

euank 12y ago
To expound on this comment: SDL1 defaults to fully software rendered output. You can hack in opengl hardware rendering, but it's fairly common for SDL1 games and such to be fully software rendered and run fine. SDL2 in general is hardware rendered. SDL1 is a good counter-example to "software rendering isn't quick enough anymore". You can make perfectly performant 2d games with sdl1's software rendering... 3d, not so much.
- tagrun 12y ago
  People usually use SDL1 with OpenGL, and I don't understand what part of it is "hack". Is using OpenGL with a manually created context with tens of platform ifdefs less hacky? Or is EGL/glut/<your favorite wrapper> the one true way of doing things?
  - euank 12y ago
    It's not a hack in that it's held together by tape, precarious, or any such thing; it's a hack because it's going around the back of SDL to do the graphics, even though SDL is supposed to do all the graphics for you. Perhaps my wording was poor. It's more of a hack than in SDL2, where all the SDL functions support hardware rendering with no need to touch OpenGL directly ever. The general point still stands that you can write performant software rendering in SDL1.
clarry 12y ago
I am talking about the layers below SDL. The layers that give rise to questions like will the graphics card be supported on my favorite OS if I buy this new computer?. These layers are responsible for detecting and configuring your adapters & monitors, setting the resolution, colour depth, interrupts for vsync, dma for fast frame copying, etc. If these things do not work right, you are in for a sad sad desktop experience, even if your CPU were fast enough to do all the 3D magic you want. Hilariously, using software SDL for your framebuffer (at least on X.org) will be much slower than using OpenGL PBOs. Don't talk about hardware acceleration here -- all we're doing is transferring a finished frame to the display. At this point, we already need much more than the "small" amount of code to implement KMS. Can it break? Yes it can. Does it break? Yes it does. Graphics driver issues are still among the most common problems I witness people struggle with, as far as getting their OS to run smoothly goes.
- rasz_pl 12y ago
  You use SDL precisely to not care about layers below. SDL 2 will select fastest mechanism to get your software rendered frame to the screen.
  - clarry 12y ago
    I care about the layers below, because they affect people, and they affect me. If the layers below are broken, SDL does not fix it.

datenwolf 12y ago

> to get any reasonable graphics at all at your native display resolution, you have to live with an incredibly complicated (and unreliable) graphics stack. Actually no. OpenGL in no way deals with setting up the display or creating a window on the screen. That has always been the responsibility of the underlying graphics infrastructure (KMS, X11, GDI, etc.) > Purely CPU based rendering (which was fast enough in the 90s) is no longer a choice really. In fact on Linux you can use KMS and the fbdev without making use of OpenGL. Heck, mplayer and ffmpeg even support do operate on the fbdev without going through a windowing system – just naked writes to the graphics framebuffer. > I find it sad that we have no modern standard akin to VESA / VBE Actually there is such a standard, it's called EGL. However EGL by itself is graphics stack agnostic and has been designed to be usable on a wide range of plattforms and graphics infrastructures. So you still have to use some kind of operating system dependent API to open the display device, but then you can use that display device handle with EGL to create abstract surfaces that OpenGL, OpenVG and other API can use to draw on.

wtallis 12y ago
EGL is completely different from VBE. VBE was a hardware interface that got you modesetting, a framebuffer, and vsync for any hardware with a single driver that was always there as a fallback. EGL's just an API for applications to talk to the drivers the same way regardless of the window system, but you still need the multitude of drivers. The modern analogue to VBE would be one of the EFI graphics standards, if there weren't two of the damn things, and if anybody would bother properly implementing EFI.
- datenwolf 12y ago
  True, but it's a single API you can ideally use across a multitude of platforms. That's a huge step forward compared to the plethora of APIs you have/had to deal with: WGL, GLX/X11, AGL, Cocoa, Carbon, etc. From a user space process programmer's perspective the graphics device is some abstract thing, represented by the operating system through a unified API. When it comes to actually setting the framebuffer mode on the hardware, well, in theory it sounds nice to have a common hardware standard like VESA to support this. But then such a low level interface was of little use to user space applications running in memory protected environments. For a long time the X server was required to be SUID root because it drilled a hole through memory protection using ioperm so that it could talk to the graphics chip directly; but talking VESA required some code of the Video BIOS to execute, which technically requires a real mode environment the X server also included a 8086 emulator to run the Video BIOS code in. We had to live with this mess until KMS came along. From a programmer's perspective KMS is the far nicer, much less complex solution, even on the low level. Yes, it requires dedicated code for each kind of GPU, yes there is some code duplication. But the advantage is a huge reduction in complexity: Not interacting with a Video BIOS (or a EFI driver) means, that you don't have to provide a runtime or execution interface in your kernel for them to operate in. Writing a universal emulator/VM, verifying that it always does the correct thing is much harder, that punching down a few dozen lines per GPU class to deal with the low level mode setting stuff.