nVIDIA's Cg

[elias]

So, how interested are we in implementing Cg in LWJGL like jogl did? I might even do the work, given enough enthutiasm.

And I'd like 0.8 to be released here soon, too EDIT: or is it 0.7? I forget.

- elias

[princec]

Well - are we going to take the plunge with these buffers then?
And are we going to do it SWT style, where we keep the ints, but make them private, and unwrap them in Java (probably much faster than doing it native - time for a benchmarking test)? Because that means we don't have to bugger around with the C code, and there's a lot of it.

Cas

[elias]

I prefer swt style. Other than that we need to decide on a particular implementation and then comment on it for a few days.

Other than that, I can't find find my favorite solution. But I'm leaning towards using ByteBuffers directly as parameters, which will make sure we get the lowest memory overhead per buffer, but trading in for a slightly higher overhead in C code. And exactly how much is env->GetDirectBufferAddress costing?

What does jogl do?

EDIT: Yes, swt style is contradicting my favorite solution.

- elias

[elias]

Alternatively, we could find the few solutions we can live with and post them as a poll.

- elias

[princec]

The C overhead is fixed and unchangeable and unoptimisable whereas Java can probably do a few little tricks and magic away nearly all the overhead. There's only one small problem - we can't get the address of a bytebuffer at all in Java, so we're kinda shafted and have to do it in C.

jogl uses arrays (!)

Cas

[elias]

And another thing while were changing everything - can't we make the context calls static? There's no reason all the gl calls can't be static for example.

- elias

[princec]

Is static import going to make it into JDK 1.5? If so, definitely - if not, then almost definitely

Cas

[spasi]

I vote swt style. Much easier and much faster (any benchmark results?). I believe it's the best solution. Could you give me any disadvantages of such an approach? Cause I can't think of any...

What exactly has jogl done with Cg?

[spasi]

static import will be in 1.5 for sure...

[elias]

If you want swt style, you would have to add a wrapper object to every ByteBuffer, adding memory overhead.

- elias

[spasi]

If you want swt style, you would have to add a wrapper object to every ByteBuffer, adding memory overhead.

- elias

Well, I already do this. When I started working with LWJGL I had all those buffers and their adresses lying around my code. It got ugly after a while. So I wrapped them in a single object and was happy ever since. And I think it's a negligible overhead, given the convenience it provides. I'm used to it, maybe that's why I find it a nice solution...

Ok, this is what I've been doing:
-------------------------------------
FloatDataBuffer buffer; // "FloatDataBuffer" is my wrapper

FloatBuffer data = buffer.data;

// Fill/Retrieve/Process the FloatBuffer...

gl.vertexPointer(3, GL.FLOAT, 0, buffer.address);
-------------------------------------

This may become:
-------------------------------------
// Same as before

gl.vertexPointer(3, GL.FLOAT, 0, buffer);
-------------------------------------

gl.vertexPointer receives the wrapper and retrieves the (private) cached pointer.

Now I'm a happy (and safe) Java programmer. And I don't have any performance impacts.

Is this what swt does?

[elias]

Yes. In effect taking your model and bringing it into lwjgl.

- elias

[ckline]

What exactly has jogl done with Cg?

JOGL has a full Cg binding (well, minus one method that we haven't gotten around to having the code generator parse yet). Unfortunately  during the transfer of code from our private CVS server to the new java.net one the CG binding got ripped out (along with most of our demos) because Sun wanted to be sure about the legal restrictions surrounding those things. So you can't build the Cg binding right now with the Makefile and .cfg files that are available online (unless you create your own .cfg files), but we're working on getting that all back online ASAP.

I'm not sure what Cas meant about JOGL using arrays, if he was implying that it uses only arrays then that is incorrect. For function call arguments, JOGL can use arrays OR Buffers, or even allow both. By default it uses both (for instance, a void* param will be expanded to all possible array types plus a Buffer form on the java side), but you can add an NIOOnly directive to the configuration file to tell it to only generate the Buffer version.

I think a lot of this misconceptions will go away if we could get some JavaDocs online.   Hopefully soon Ken and I will have owner status on the JGO site so I can actually post stuff.

BTW, has anyone notified SpaceGhost of the migration of the JGO community to this site?

-chris

[princec]

I imagine JeffK's mentioned it by now... besides I've got to discuss a few things with ChrisM. about JVM licensing. I must get rid of Jet out of the equation eventually because it's a bit of a pain with it only running on Windows.

Still, it doesn't really hurt. Well, it hurts me slightly, 'cause if it gets too bandwidth-hungry I'll be the one paying for it

Cas

[Fuseboy2]

The Cg runtime interface would be handy, since it would make parameter binding a easier.  Currently my ant script just compiles my Cg programs to the OpenGL vertex/fragment profiles, and I load the results in.  It does mean, however, that I have to manually relate the parameter indices.