No GL3 and no newsletter yet...

[EvilOne]

Yeah, compatibility at every price. But I were more happy with writing a second code path for rendering from buffers, instead of having the current situation.

Somehow it seems, that D3D is draw-call-bound, and GL is now setup-call-bound.

And by the way, a little wish I have for GL3. I’d like to have the Direct3D9 DrawIndexedPrimitive call emulated:

HRESULT DrawIndexedPrimitive(
  D3DPRIMITIVETYPE Type,
  INT BaseVertexIndex,
  UINT MinIndex,
  UINT NumVertices,
  UINT StartIndex,
  UINT PrimitiveCount
);

In particular, BaseVertexIndex and StartIndex is what I have always missed. So this would help in setup cost somehow. The D3D version of my landscape renderer looks so elegant… Bind once, then draw, draw, draw… Maybe, I just have overseen the similar function in GL (my multiplaform backend ambitions were a bit halfhearted).

[Dark_Photon]

@EvilOne

by the way, a little wish I have for GL3. I’d like to have the Direct3D9 DrawIndexedPrimitive call emulated:

HRESULT DrawIndexedPrimitive(
  D3DPRIMITIVETYPE Type, INT BaseVertexIndex,
  UINT MinIndex, UINT NumVertices,
  UINT StartIndex, UINT PrimitiveCount );

In particular, BaseVertexIndex and StartIndex is what I have always missed…Bind once, then draw, draw, draw… Maybe, I just have overseen the similar function in GL

I believe you have a StartIndex analog in OpenGL. Just bind your vertex attribute and index VBOs, then pass the appropriate index start offset to “indices” in glDrawRangeElements (0, 128, etc.). For those like me that don’t do D3D, the idea here is you have the indices for a bunch of batches stored in the same index VBO, and you want to issue multiple batches without rebinding VBOs.

However, there’s no BaseVertexIndex analog AFAIK (i.e. a value that gets added to every index that is fetched). Only useful when you don’t know what offset your vertex attributes are going to be from the start of their VBO when you cook the index list for the index VBO – rarely true, but I could see this potentially being useful for streaming into pre-allocated VBOs. In that case, just add N to your indices when you store them. Simple and cheap.

The MS canonical docs on this API are the pits, but this blog post does a good job of explaining what MS didn’t.

[ruysch]

Where is the binary shader interface, why do we have to recompile every freaking shader every time!

Where is the clean interface allowing us to set states inside shaders.

Where is the hardware queries for vcache usage, bandwidth used, etc?

Where is the shader precompiler ?

Where is the support for half floating-point (Yeah it was exposed once by NVIDIA but to conform with the standard they removed it)

Where is the GL version of D3DX.

Where is the GL version of DXUT (and dont say free glut, glut …)

The problem with OpenGL is that its a standard which in it self isnt worh much, its the tools, tools, tools.

There was a time where a company didn’t see the potential in the mass-consumer market (SGI) and now there is a standard which hasn’t discovered that standards are there for people to use them, and for people to use it they need tools.

The problem with the people, (including my self), devoted to OpenGL is that every time the ARB board/SGI/Kronos f*cks up (sorry about the language we still whine about Microsoft and DirectX.

But what about ATI or NVIDIA, look at the tools they make for DirectX and then take a look at what they offer for OpenGL.

My advice to the ARB board, starting up your favorite editor and keep coding like us Because we don’t need any more standards we need tools! We do not need any more excuses about evil Microsoft who obviously is doing a much better job than we do …

[CatDog]

Can somebody recommend a good book, that describes D3D from an experienced OpenGL users point of view?

(This ranting seems to be fun - but I need more input, before I can participate.)

CatDog

[ruysch]

Book, that would cost you money …

Just download the SDK, thats the proper way to learn DirectX.
http://msdn2.microsoft.com/en-us/directx/aa937788.aspx

There is also a free online draft on a DirectX9 book.
http://www.xmission.com/~legalize/book/download/

You could also start with XNA,
http://forums.xna.com/

[Roderic_Ingenu]

@ruysch

…and now there is a standard which hasn’t discovered that standards are there for people to use them, and for people to use it they need tools.

Or maybe it does, and that’s the source of the problem.
Ever noticed that OpenGL is not ONLY for games ?
In fact it’s usage is way wider in other areas than in gaming, which raises the question : Who is OpenGL for ?
(Democracy would mean the game industry would have little weight in decisions about OpenGL, since it’s a minority.)

[EvilOne]

Maybe someone want to elaborate about the journeys of using GL under OS X. I have read, that GL under OS X is mostly implemented by Apple (so to say, the D3D way)?

[Korval]

Where is the hardware queries for vcache usage, bandwidth used, etc?

That belongs in a platform-specific profiling system, not a platform-neutral graphics API.

Where is the support for half floating-point (Yeah it was exposed once by NVIDIA but to conform with the standard they removed it)

… and? Half-float was a temporary measure that nVidia needed because their GeForce FX hardware sucked.

Also, this isn’t a tool.

The problem with OpenGL is that its a standard which in it self isnt worh much, its the tools, tools, tools.

Nonsense. Give me a performant API that doesn’t have pitfalls and has implementations I can trust, and I’ll take care of the external tool stuff. I’m a grown-up programmer; I don’t need any particular hand holding.

Tools aren’t going to make it easier for me to figure out which kind of vertex formats hardware supports in code. Tools aren’t going to make ATi’s glslang compiler work. Tools are meaningless if you can’t even trust the API that those tools depend on.

[ruysch]

I reckon then everything is just sweet candy.

Look at XNA from Microsoft, now thats a platform which is going to have long lasting consequences on the flow of programmers into the DirectX camp. Look a Game studio again from Microsoft.

Look at the content pipeline provided with XNA, but I reckon tools aint usefull…

Look at at Mircosoft PIX, or NVPerfHUD, again profiling is overrated…

I mean be honest, take a look at the OpenGL SDK
http://www.opengl.org/sdk/

Is that what OpenGL has to offer the next generation of graphics developers?

[knackered]

lol! do you really think professional programmers use XNA Game Studio??
PIX and perfhud are great tools, but that’s about it for useful things in DX. Everything else you mentioned is for amateurs/hobbiests.
The XNA framework itself is pretty pointless in my opinion. If I’m writing a game for multiple consoles, what have I to gain from locking the PC and 360 versions to some win32 specific bloatware? I’ll have to come up with a tool chain for the other platforms anyway, so why would I bother with the added complexity? The answer is of course that I wouldn’t, I’d either write the tools and platform-specific code myself, or I’d use some tried and tested middleware such as unreal or renderware.

[Zengar]

I absolutely agree with knackered and Korval (hey guys! for the first time you actually say something similar ) — D3DX, GLU and things like that are toys and are not needed at all besides for small demos, as the required functionality is coded within one-two days by more or less proficient coder. Actually, you don’t need an “SDK” at all (actually I never understood what this SDK thing is about? Usually when people talk about “SDK” they seem to mean API bindings). We don’t need API-specific tools, we need a good API first. The tools will come with the time.

[imported_bobvodka]

I wouldn’t have said they ‘arent needed at all’; while they aren’t as much use to big software houses and people who know what they are doing having something like that to kick start your learning of the API can be and IS helpful.

[knackered]

An up-to-date and easy to implement API is perhaps a little bit more important, however. Which brings us back to this ridiculous delay in the GL3 spec.

[Zengar]

Well, I mostly said “not needed” to make some dramatic impression. I hope you all understood what I meant — it isn’t so much different from what knackered and Korval (just to name a few) were saying.

[knackered]

I think bobvodka’s struggling with the english language, specifically the difference between ‘needed’ and ‘helpful’. Yes an SDK would be helpful to novices, but no it’s not needed by the main people a low-level rendering API is aimed at - i.e. people who use it to make money or to help in research projects.

[pudman]

@Korval

Where is the hardware queries for vcache usage, bandwidth used, etc?

That belongs in a platform-specific profiling system, not a platform-neutral graphics API.

If the hardware queries are directly related to the graphics API, the performance of said API, or configuration of said API, might the API provide even a simple extensible mechanism by which IHVs could provide those capabilities?

Or maybe this begs for an OpenGP… “Open Graphics Profiler” API that would happily coexist with GL. Then again, I believe there was some mention of a GL3.0 debug profile which may be what people actually need.

Maybe because Kronos is (possibly) redoing GL3.0 they’ll skip v3.0 and head right to v5.0. That might make D3D coders more at ease… skip those versions that we all know will suck. I have high hopes for GL10.x!

[Ilian_Dinev]

My only wish from GL is that writing to the FIFO doesn’t take thousands of cycles. glBindBufferARB-2k cycles, gl*Pointer - 2k cycles,…
It would be great imho if nVidia and ATi provide some closed-source driver/interface for each type (or just for at least one-two) of their most recent cards. It’ll be just few cards: the GF7200, GF7x00, GF8x00, GF9x00, R1x00, RHD2x00. It’s things we can handle easily with wrappers and allowing to pin-point optimize for some cards. This probably will open-up space for some more things that can be done in a frame, or simplify some designs. A GL/DX wrapper will still be necessary, but I’d rather code more than spend most of the time in trying to see how specific cards and drivers behave.
With such a low-level interface, windowing and vram resources will be problematic, but I don’t think it’d be too hard to be managed either by the driver or by ourself.

Or simply GL3 should finally come >_> … and it’d better be lightweight.

We don’t need tools, just a way to compile and bind shaders, set uniforms, queue-up vertices with attributes from vram/sysram, draw points/wide-lines/tristrips/indexed_tris, do occlusion queries, use RTT and R2VB, tweak basic hw facilities (culling, depth-test, stencil), and present onscreen - all being as fast and pipelined as possible.

[Korval]

If the hardware queries are directly related to the graphics API, the performance of said API, or configuration of said API, might the API provide even a simple extensible mechanism by which IHVs could provide those capabilities?

Hey, IHVs have always been free to add whatever extension to OpenGL that they want.

[noncopyable]

[quote=Korval]

… and? Half-float was a temporary measure that nVidia needed because their GeForce FX hardware sucked.

Don’t know its origin but a half float is in most conditions alot more than enough, and half memory cost, imo it is another >>must<< for a serious api/language whatever you call.

[ruysch]

Lets just not hope halfs are in the spec… or what Korval, because
I know half will be in OpenGL 3.0 …