Slashdot Mirror
Khronos Releases OpenGL 4.2 Specification
jrepin tips news that the Khronos Group has announced the release of the OpenGL 4.2 specification. Some of the new functionality includes:
"Enabling shaders with atomic counters and load/store/atomic read-modify-write operations to a single level of a texture (These capabilities can be combined, for example, to maintain a counter at each pixel in a buffer object for single-rendering-pass order-independent transparency); Capturing GPU-tessellated geometry and drawing multiple instances of the result of a transform feedback to enable complex objects to be efficiently repositioned and replicated; Modifying an arbitrary subset of a compressed texture, without having to re-download the whole texture to the GPU for significant performance improvements; Packing multiple 8 and 16 bit values into a single 32-bit value for efficient shader processing with significantly reduced memory storage and bandwidth, especially useful when transferring data between shader stages."
PARENT LINK IS GOATSE
It took me a good 30 seconds or so before I realized that I wasn't looking at some real-world DirectX code written in C++.
I don't know what delusion planet you are posting from but here in the Real World OpenGL has left DirectX in the dust in both features and performance a long time ago.
Khronos is absolutely on fire with giving developers what they want as quickly as possible. OpenGL developers have access to the absolute bleeding edge features of new graphics cards that people who are stuck still using DirectX have to wait around for Microsoft to get off their ass and implement.
It shouldn't be surprising OpenGL has won the API war with Microsoft:
210 Million OpenGL ES based Android devices a year.
150 Million OpenGL ES based iOS devices a year.
Every Linux, Mac,and Windows machine
The dying PC games market and the last place Xbox 360 are the only places left in the world still using the dead end DirectX API.
They did that already. As of OpenGL 3.1 the only non-deprecated rendering method is Vertex Buffer Objects. Link.
There are a lot of things OpenGL could do to make itself more accessible - better-supported crossplatform utility libraries, three or four shortcut commands that set the various glEnable() states that 95% of new developers actually care about, streamlining eyebrow-raising pile of mipmap generation options, the entire process of setting up a vertex buffer object could be MASSIVELY simplified...
Honestly, what OpenGL needs isn't fewer features, but rather for the features most people want to use to be placed front and center with extremely simple, well-documented data formatting rules and optimized, efficient helper functions. Microsoft might have been Slashdot's Great Satan for a long time, but they do listen to the sort of developers they're hungry for, and DirectX is one of the better examples of that.
Perhaps somebody in the know can enlighten me about this.
I see many fairly advanced features and functions in both the DX and OpenGL APIs , but I was under the impression that a modern graphics cards were basically designed to do a few fairly primitive operations very well and in parallel. So basically, how much of these APIs actually deal with interfacing the graphics card and it's hardware accelerated features, and how much of it is more along the lines of just a standard library that contains frequently used graphics algorithms?
Maybe my view of how programming is done these days is a bit naive, but I've always sort of felt there was a difference between the APIs that are there in order to let you use the hardware without mucking around with terribly low level and platform dependent stuff like interupts and so on, and on the other hand just standard libraries that is pretty much things where the code would be more or less the same on most platforms, but you just don't want to write it all over again whenever you make a new program ( things like some container class for C++ ).
My idea of what OpenGL and DirectX did was to let you access the features of the video card without having to worry about all the little differences between one card and another. So you could send the card a bunch of textures or something without having to rewrite the code for every card you wanted to run on.
Am I missing a lot here? Do the OpenGL and DirectX APIs also deal with a load of stuff that is just generally handy to have around when writing graphics programs?
OpenGL promised in the last version to cut away a lot of the features from really old versions, just like DirectX 10 did. This would have the disadvantage of breaking compatibility but the advantage of making it easier to support into the future and more efficient right now. Instead they maintained backward compatibility which made it bloated and hard to use.
You are aware that the complaints that you are repeating were about OpenGL 3.0, were addressed in 3.1, and the current topic is 4.2? 3.0 introduced a deprecation mechanism, and deprecated a load of stuff. 3.1 removed it. In 4, all of the fixed-function stuff is gone completely.
I am TheRaven on Soylent News
I'm a newbie at this stuff, but here goes:
"single-rendering-pass order-independent transparency" - let's say I have three translucent objects at roughly the same depth, with parts of one in front of and behind parts of the others (and maybe the same is true for objects B and C as well). Figuring out the correct draw order is absolute fucking murder, and there still isn't a generalized approach for anybody but the most advanced of the most advanced (like Dual depth peeling or making convex hulls out of all translucent geo in the scene). Core API support for dealing with this issue would be a godsend and is about 10 years overdue for ALL graphics APIs.
Neat fact: the PowerVR-based GPU used by the iPhone/iPad uses a tile-based rendering method in which (I am told) this problem generally doesn't arise.
"Capturing GPU-tessellated geometry and drawing multiple instances of the result of a transform feedback to enable complex objects to be efficiently repositioned and replicated;" Easier to quickly render massive crowds, forests, and procedural cities.
"Modifying an arbitrary subset of a compressed texture, without having to re-download the whole texture to the GPU for significant performance improvements;" Shaders not requiring four fucking separate mask textures all dancing on the head of a pin to pull off a simple effect? Yeah, I'll take that. Could probably also have some nice gains in procedural content variation.
"Packing multiple 8 and 16 bit values into a single 32-bit value for efficient shader processing with significantly reduced memory storage and bandwidth, especially useful when transferring data between shader stages." Massive performance gains for any sort of post-processing work, basically.
Wait , I really hope you are not saying VOXELS are ready for prime time over the standard polygon model?
- d
It's a troll or loufoque is a bit detached from reality, but this does bring up an interesting point: a lot of what people are looking into these days in terms of rendering is voxels drawn using polygons. Minecraft? Basically those tiles are voxels being rendered as an uniform convex hulls - lends itself to some amazing efficiency.
This is even more interesting from a technical perspective - stretching isosurfaces across voxel terrain to create a truly malleable world.
You know that is one of the things MSFT really should be given credit for, because DirectX "just works".
Is that why so many games using DirectX come bundled with all those DirectX updates and patches?
Checking a randomly chosen game I have installed here (Dragon Age Origins) shows no less than 74(!) cab files with DirectX updates and patches, from Feb2005_d3dx9_24_x86.cab to NOV2007_d3dx9_36.x86.cab
Yep, it "just works".