Slashdot Mirror
OpenGL 1.5
Yogijalla writes "SGI and OpenGL ARB just announced
the OpenGL 1.5 specification, introducing support for a new OGL Shading Language. Also, check out the new Java bindings to OpenGL.
OGL 1.5 is a step towards the OGL 2.0, already suggested 2.0 by 3DLabs." Also worth pointing out that OpenML SDK has been released as well.
http://www.khronos.org/openml/sdk/linux_requirem ents.html
Id really like to try this OpenML SDK, but it seems you are requered to enter your phone number - now why is that??
> Now I need to buy another video card.
:)
Oh, not necessarily. The OGL shading language is just a high-level version of the shading extensions that have previously existed. I'm pretty sure drivers will adapt by simply compiling the code before passing it to the card. The other extensions mentioned (like the ARB_vertex_buffer_object and ARB_occlusion_query) have been extensions to 1.4 for a while now, and my GeForce FX 5600 supports them already.
Now if the cards can accept the high-level language itself... that would be interesting (and perhaps will make for a bigger, hotter video card...)
Pet peeve: Profane people propagating perfunctory pedantry.
I wonder when these will become standard (not just as an ARB extension but as an ARB required feature). Hopefully in 2.0? It will save a lot of calls, at the very least--just check the version number of the GL implementation, no more searching extension strings...
You can see at
http://www.opengl.org/developers/about/arb/note
That the reason that it was called 1.5 and not 2.0 is that the shader language didn't make it to the core specs, and that they plan to promote it to core specs (and release 2.0) soon, possibly even in the next ARB meeting in september or the one thereafter.
Here is the quote
> That's _thee_ key feature Apple needed to do the fully OpenGL desktop,
:)
But there have always been tools to circumvent the power-of-two limitation. You can always use only part of a texture on a primitive (triangle, quad, etc.). There are tools to tile non-power-of-two textures on a power-of-two texture to minimize memory usage.
At least in game dev, it didn't really prove to be useful. (Except for those artist whiners who insist that they can use any size image that comes out of Photoshop. *laugh* just kidding guys... I hear ye)
I'm just thinking that Apple wouldn't be making the late introduction of non-power-of-two textures into OpenGL as a plausible excuse for not making the desktop fully-OpenGL already. Besides, they can always introduce Apple-specific extensions--why didn't they do that already? Methinks they're just lazy.
Pet peeve: Profane people propagating perfunctory pedantry.
Apropos to the recent Perl 6 announcement I'll just go ahead and mention the perl interface as well. Wouldn't want anybody to forget.
Apple did implement GL_EXT_texture_rectangle (DRI implements it as well). It has some uses, especially with GL_APPLE_ycbcr_422 or GL_MESA_ycbcr_422, but in games, it is non issue, for reasons you mentioned. Do not forget, that NPOT textures still aren't first-class citizens compared to POT textures, you lose tiling for example.
These are valid concerns. I'm surprised the guy got marked as a troll.
:))
> - What still remains before we can say OpenGL is back toward its original goal [...] every card uses a different opengl "extention" to do the exact same goal.)
Well, I must say that OpenGL never really swayed from its original goal. OpenGL follows a pseudo-Bazaar philosophy--let vendors push for features they want, and if they get a massive following then it's good enough to put into the standard. I say pseudo-Bazaar because, unlike open source, this process happens somewhat too slowly for it to be competitive with DirectX.
> - What still remains that DirectX excels at that OpenGL is lagging behind at
The only thing that DirectX seems to excel at right now is standardized support for a lot of graphics programming constructs, i.e. its D3DX library (especially those mesh/skinning functions, quaternion arithmetic and the myriad transformation matrix builders it has by default--can anyone say D3DXMatrixShadow?
However, we can also say that DirectX contains too many features that won't be used by many (and in fact some of them do get dropped in subsequent API releases) OpenGL, on the other hand, tries to promote a *clean* standard, not a super-bleeding-edge standard that contains a lot of cruft. That is also the reason why OpenGL lacks the utility functions I mentioned in the above paragraph; many developers have a (portable) base of utilities that works well for them, and all they want is a (portable) API to display their graphics, not something like DirectX which coerces you to use the Microsoft-only stuff for mostly everything (including the math, which should be something the programmer himself should handle).
> - What of the things in the above two lists will be fixed by OpenGL 2.0, when/if it is adopted.
OpenGL 2 is a draft (and therefore moving) standard, and it will be largely up to the ARB to define what is being used by most applications to be declared fit for the standard. It doesn't necessarily mean it will beat DirectX in terms of functionality, but it will surely be a cleaner, more general standard that vendors will be happy to adhere to.
Pet peeve: Profane people propagating perfunctory pedantry.
This is good news, but I should point out the OpenGL 1.5 spec is not at this moment available yet, it's only been announced. Hopefully it will be available with some headers and implementations Real Soon Now (tm). I know the past few ATI Catalyst drivers have had experimental glslang extensions in them... Of course, it'd be nice if Microsoft would update their implementation such that OpenGL on Windows could make use of this without going through extensions, but I'm not holding my breath, nor is it really a huge issue.
The OpenML SDK is an alpha release and the final spec for it won't be out until about this time next year.
However, the Khronos Group also released the OpenGL ES spec and there's actually a couple implementations already available. OpenGL ES is for embedded systems and mobile devices, it's essentially just a subset of OpenGL. Seems like it might be pretty nifty...
Granted, OpenGL 1.5, with improved programmable shader support is indeed a step toward OpenGL 2.0, it is really a fairly minor evolutionary step.
When OpenGL 1.0 was initially proposed, it provided a standard implementation for fixed pipeline segments (with the idea that individual implementations could selectively choose which pieces of the pipe would be implemented in software, and which would be implemented in hardware). This was a very significant development, as it meant that everyone could operate with the same set of rules, and could do the same things, but those without hardware support may suffer some performance penalties (of course, with modern CPUs, some of the stages in the pipeline can have very high-perf implementations in software).
Since then, the rules have changed significantly. Hardware developers have started to suggest that the behaviour of the individual components of the pipeline could be programmable. NVidia and ATI have already responded to this, providing a wide variety of programmable shader technologies (e.g. programmable vertex and pixel shaders). I understand that OpenGL 1.5 essentially brings this level of programmability up to current levels (I think that DirectX 9.0 does the same thing, but I would love for someone to correct me on this. I haven't touched DirectX in a while, so I'm a little rusty. In fact, at the pace that hardware is evolving, I'm actually very rusty, and likely collapsing due to decay.) OpenGL 2.0 extends this idea of programmability to every stage of the pipeline. For most current video cards, this means that a lot of that programmability has to be implemented in software (which is essentially what people are doing anyway. If you want to implement programmable textures, you write software that interfaces with your video card's static texture routines.) 3DLabs is hoping to turn the computer graphics world on its ear by providing almost completely programmable graphics cards. Nearly every stage of the pipeline should be programmable in hardware. Of course, we will have to wait to see what they deliver, but I imagine that even if their cards suck ass in terms of performance (or they'll be targetted to the super high-end, so most of us will never see them), they should offer some features that will force some new developments from ATI and NVidia, which will eventually make their way down to regular consumers.
It's good that OpenGL 1.5 is out, to help keep OpenGL on the map of standards (especially since DirectX is a really inconvenient standard for those of us who don't run Windows), but I'm still pretty psyched for the release of OpenGL 2.0, w00t!
Yes there are hacks, but those hacks eat memory, and you only have so much texture memory on a card.
And Apple has a loooong list of OpenGL extensions. They implemented this all some time ago now. You should see some of the realtime video editing that they can do.
Nothing gets into OpenGL that wasn't an extension first - that way it's all developed and debugged before we have to deal with it.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
- What still remains before we can say OpenGL is back toward its original goal (you write for one standard instead of having to write for every single little card driver, something kind of ruined by the fact that many things these days, every card uses a different opengl "extention" to do the exact same goal.)
- What still remains that DirectX excels at that OpenGL is lagging behind at
I don't think pt.1 has really been lost, unless you are doing really cutting edge stuff you can use OpenGL pretty happily as is. Many scientific applications are actually coded to Performer which works just fine on OpenGL 1.0. I've written lots of stuff, some just a couple years ago, that used plain immediate mode OGL 1.0, with a switch added later on for vertex arrays.
What remains is the vertex and pixel shaders, these will be in 2.0. They are already pretty much supported with the nv FX and I guess the 3D Labs card. I haven't been programming the ATI card, though many have for it's speed advantage, but from what I understand it doesn't quite live up to the requirements of 2.0. Also I think 3D Labs is pressing for infinite length programs, this can be implemented in the driver by simply compiling to multiple passes implicitly, though who knows about the performance. But the nv would handily beat the ATI if you do this because it can natively handle pretty long instruction streams. Unless this is already a driver trick, I dunno.
2.0 will almost certainly wait until ATI is ready on the hardware level at least. If you program to extensions...OpenGL is ahead of Direct X, but this means you are stuck with the vendor if you use their specific stuff, say using fp30 Cg on the FX. I think everyone pretty much does program to extensions and not the standard if they are doing cutting edge stuff, usually with a compile or run-time code switch based on the extensions present.
However, NPOT textures are the only way to get fully accelerated DMA AGP updates. POT textures are not currently accelerated in 10.2.6, see Apple's TextureRange sample code.
As you point out, this is primarily useful with video textures, but any game that does animated textures can take advantage of it.
No doubt, my knowledge of 3D APIs and hardware is pathetic; however, what exactly do you mean by "fully OpenGL desktop"?
Quartz Extreme, Apple's name for the Mac OS 10.2 version of the Quartz Compositor, uses OpenGL to render what you see on the screen. Note that just because it uses OpenGL doesn't mean that it uses any 3D - all it takes advantage of is 2D bitmaps, special effects like shadows, and alpha transparency.
But that's a really big deal! It means that all of the bitmaps representing your windows and other screen objects are in your graphic card's RAM, and moving a window in OS X doesn't require computing of any pixels at all on the CPU. (Unfortunately, resizing is slower, because every redraw requires sending a new bitmap, of a different size, to the graphics card.) This also allows them to do the Genie effect, window scale effects, and Expose superfast without wasting any CPU cycles. Compare that to Windows or X - when you move a window, all of the windows underneath it get repaint events, which can take a while to trigger depending on the application.
Note that the Quartz Compositor is a totally different thing than Quartz, the new 2D graphics library in OS X that is designed to replace QuickDraw.
The Quartz Compositor is what makes it possible for QuickTime movies to keep playing when you minimize them to the dock, transparent overlays to smoothly fade in and out when you hit a volume control key on the keyboard, and 10.3's fast user switching to literally "rotate" the screen in 3D to show the other user's desktop.
Quartz Extreme - i.e. using OpenGL to implement Quartz Compositor - is what makes it fast.
The great thing about Quartz Extreme is that Apple has only begun to explore the possibilities. The fast user switching effect probably only took them a day to code up, because all of the underlying technology was there.
Oops, check my response to Anonymous Coward on the other subthread. :) Sorry for the misinformation. Apple did have non-power-of-two textures through the multivendor GL_EXT_texture_rectangle extension; I was just pointing out that they didn't bother using this for their desktop. :)
:)
You're right about the hack-nature of what I proposed though. In practice, however, you only lose very little texture memory, if you have a good tiler. Besides, I believe that non-power-of-two textures will suffer some memory loss as well in two ways:
(1) If the card vendor gets lazy and implements non-power-of-two textures as power-of-two textures. I've seen this happen with DirectX 7 on a GeForce 2 before--damn texture loader forced a power-of-two memory space for my proportional-width font characters, which is why I had to make my own tiler in the first place!
(2) If the bitmap word spans on the card force a power-of-two texture width, which will accumulate if you have a large amount of small textures.
Pet peeve: Profane people propagating perfunctory pedantry.
But that's a really big deal! It means that all of the bitmaps representing your windows and other screen objects are in your graphic card's RAM, and moving a window in OS X doesn't require computing of any pixels at all on the CPU.
Actually, that's due to the fact that the bits are in your computer's RAM. Quartz double buffers all drawing so that it doesn't flash and looks smooth. Because of this no redrawing has to be done when part of a window is revealed. On the other hand, resizing means that the buffer has to be reallocated and redrawn.
Reliable, Great Value Hosting: $7.95/mo 2.4G/120G
Sure, if you already HAVE a fancy-schmancy GeForceFX/Radeon 9500+ level card. For previous-generation hardware, you might get very simple shaders to work, but for more complex shaders that require looping, data-dependant branching, overbright float pixels etc, you're still gonna need new hardware :-) Even earlier hardware, well, tough - you might get vertex shaders if you're lucky.
Now if the cards can accept the high-level language itself...
No chance :-) It's difficult enough to decode the time-encrusted x86 instruction set for efficient hardware execution by a flexible CPU. It'd be a helluva lot harder to decode modern, high level, arbitrary-syntax code for execution on a much less flexible, highly parallely & extremely specialised GPU...
Why would anyone engrave "Elbereth"?
If it's a decently implemented X server on the client then it should support it provided the application isn't using any calls or extensions that aren't supported. For example my Linux PC (with GForce4 graphics card) will work as an X server for my Indy for some applications but not for others.
Sun announced full Open[GL,AL] support here:
http://games-core.dev.java.net/
Here's a great example of using OpenGL/OpenAL under Win32/Linux written in Java.
(It uses the LWJGL - which is an OpenGL/OpenAL Java wrapper that uses nio).
http://www.puppygames.net/
Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ (Java Web Startable)
One of its key features is that the Java bindings are automatically generated from the C OpenGL bindings, so it's pretty trivial to keep it up to date with the very latest changes Compare this to gl4Java which has really started falling out of date.
Don't forget, there are two very popular bindings currently out and very usable: lwjgl which does away with AWT/Swing and JOGL which keeps AWT/Swing support. I currently use LWJGL for some hobby stuff I'm doing. Bindings are begining to become VERY good, especially using the new nio package.
----- "Blame the guy who doesn't speak English." -- Homer J. Simpson
Java3D is currently on hold. This isn't a replacement for Java 3D, it's just something different. Kinda like Inventor is different than OpenGL, although it uses OpenGL.
Not on hold - its officially dead. All of the resources working on the project have been moved off and are now working on either JSR-184 or the new OpenGL bindings JSR (once it gets started).
We're involved in various efforts to replicate and replace Java3D with another scene graph. If you need something immediate, take a look at the Xith3D project from Dave Yazel and the MagiCosm guys. Alternatively, if you can wait a couple of months, we're in the process of ripping our OpenGL scene graph out of the core of Xj3D to turn it into a separate project. The difference between the two is that Xith3D is focused on games (it has primitive objects for particle systems, for example) where our work is focused on CAVEs, powerwalls, linux clusters etc.
Life is complete only for brief intervals in between toys or projects -- John Dalton
It's not "officially dead" until Sun says it is. When I spoke to the developers at JavaOne, they said it was on hold. That's the official line right now.
Sun cannot ever proclaim anything dead. It is admission of failure to them and therefore not acceptable. If you are waiting for them to declare it as dead, you'll probably die before they will state that. JSDT is still officially "on hold" too - it has been for the last 4 years...
When evertything has been cancelled, and their developers are now not answering emails on the java3d list, and have been assigned to other parts of Sun, it is dead. Also, we already have been told that we'll have access to parts of Java3D - either completely open source, or access to the patents. Either way, they are not doing any more development on it, nor are there any intentions to return to develop it in the future.
Life is complete only for brief intervals in between toys or projects -- John Dalton