3 ms·
The problem is that graphics doesn't really have a ramp up. Without bloating drivers that are already half a GB or larger, there isn't really a fix for that. Be
by SolarNet 9y ago
The problem is that graphics doesn't really have a ramp up. Without bloating drivers that are already half a GB or larger, there isn't really a fix for that. Because you have to with any rendering framework:
* Open a hardware context in the window manager.
* Describe to the window manager / operating system how to configure that context. (SDL/GLFW helps with this)
* Collect the functions and features (provided by different vendors based on OS, and hence this step is required) you require from that context. (GLEW helps with this)
* Write and load shaders. Including setting up that toolchain, writing boiler plate, choosing a language to use, choosing an IDE, etc.
* Describe a 3d object. Whether by loading, or directly in memory. Decide now about future steps.
* Load that object onto the hardware. Assuming there is enough room, etc.
* Describe to the hardware how that data is organized (in a different language of attributes, since the hardware cares about different things) that agrees with the shader.
* Describe how you would like to draw things if they aren't the "sane" defaults (often from 1990).
* Clear the screen (including describing how to clear the screen the way you want).
* Choose a shader (and describe how it should be used).
* Draw the object, based on how you configured everything earlier and the shader is written.
* Inform the window manager you are done with the hardware context and ask it to display the screen.
* Repeat the last 4 steps 60 times a second.
And that is for a zero features system. No dynamic movement, no lighting, no textures. Just a triangle or a cube sitting there. If you want easy ramp up, use a library that makes decisions about all of those things for you. In light of your assembly analogy, it's like you are trying to write an assembly program that prints hello world to a printer over the network, using it's assembly language so that it can optimize how many times a second it can print hello world locally. It's hard, because the goal is not "hello world" it's some complex structure that allows us to display "hello world" in a complex way (3d) in real time.
The difference is OpenGL when used incorrectly, does nothing. Vulkan comes back with an error and says "you forgot step 7a of describing how the memory you gave me was organized".
- atemerev 9y agoThe difference is that with networking, I don't need to bother myself with data being aligned to physical layer boundaries, or similar level small details that belong to network drivers or OS stack layer — and still get gigabytes per second throughput, because of good abstractions. And with OpenGL/Vulkan — it's like I am writing driver-level code, which is not my idea of fun. For printers, there is PostScript. Why there isn't a similar standardized 3D rendering protocol? Additionally, what you have described is still 10-15 lines of code. Vulkan is still more demanding.
- groovy2shoes 9y ago> For printers, there is PostScript. Why there isn't a similar standardized 3D rendering protocol? There is. It's called OpenGL ;) That said, I share your sentiment. Tossing aside the drivers and the general optimizations they offer seems to me to be akin to tossing aside your compiler because you can write more efficient assembly by hand. I think the ability to write such low-level code will always have its place, but I can't help but feel like we (as an industry) are going in the wrong direction with this. In trying to be optimistic about Vulkan and the like, it may be an opportunity for developers to experiment with different higher-level APIs until we manage to find abstractions that are as good as the ones we have for networking (and hopefully better, even). > it's like I am writing driver-level code, which is not my idea of fun. Luckily, that's somebody's idea of fun :)
- munchbunny 9y agoVulkan solves a different problem though, specifically one where performance is the primary consideration and simplicity is maintained to the extent that someone who writes engines gets all of the options they need. It's a bit hard to equate to assembly because the bulk of the complexity isn't so much "general purpose code" as "data processing pipeline." Additionally, graphics still has a very real "out of memory problem" that you can safely ignore for the most part in modern OSes and normal programming. The moment you hit "virtual graphics memory" your framerate tanks. If you're looking for sane defaults, the answer is to use things like Unity, Unreal, etc. You can actually get quite far with their defaults and very little code. That's why I usually tell people to skip OpenGL, DirectX, or Vulkan and just go use an engine. 3d also just has an inherent complexity that at every stage you're dealing with the limitations of processing 3d data using 2d buffers. That's why any fancy effect requires you to manipulate primitives (buffers and shades).
- atemerev 9y agoI work with realtime scientific visualization, game engines solve different kind of problems. So I have no other choice than to work with OpenGL/Vulkan directly, which is... less than satisfying. Good abstraction layers are totally possible, like it was done for networking, 2D graphics, and other hard problems. However, with 3D, it is more of a cultural issue — the APIs were designed by hardware / driver people, who eat these kinds of complexity for breakfast. The rest of us have to suffer and adapt. Additionally, Vulkan is increasingly pushed as a replacement for OpenGL, and this makes me cringe. It's like somebody took the worst of WinAPI and combined it with joys of developing device drivers...