We Really Want MultiDrawElements for multi-RES

[fmpc77]

I saw (and was sad of it) that glMultiDrawElements wasn’t available in GL implementation instead of glMultiDrawArrays was (same GL_multi_draw_arrays_EXT promoted from openGL 1.4).

I thought there was a reason and so checked sources. I saw that jogl/nio couldn’t support void** C prototypes and that’s really bad !!
I (& surely others) could help if some1 would explain the matter in this thread ;D

I explain briefly why i want it. I want to implement multi-resolution mesh that from a high resolution mesh corresponding vertices set, have different indexed sets defining a corresponding max/lower res. Each indexed set would be striptified for optimization. But in this case glMultiDrawElements could give a really signifiant gain against using glDrawElements multiple times from application for each strip that’s composing mesh. All mesh data is obviously stored in graphic device buffers.

Note : I recall i gave a solution for Windows Pixel format selection bug (enabling multisampling) in Multisample Support, Cross-Plateform Antialiasing Thread & I’m sure many would be happy to have a new release

[princec]

I’m afraid you’re wrong, and this method cannot be implemented in Java. This API call is a C-hack to speed up something using a C trick and make life easier for those poor souls. There is no speedier way to implement it safely in Java. The best you can do is wrap it in a call that takes an array of IntBuffers and calls glDrawElements one by one. At worst you’ll only be losing a tiny percentage of CPU on this anyway.

Cas

[mithrandir]

Eh? You’re smoking crack there. I actually have it implemented in JOGL but never submitted the patch because I couldn’t get any native code to compile on my local machine due to some dodgy configuration that they’re doing with the Ant stuff. It’s not that hard to convert void pointers of any dimensions into any sort of object you want. A void pointer is just a reference to an Object. Double void pointers are arrays of Object (ie void** == Object[]) etc.

[zingbat]

void** is the address of a memory location containing the adress to another memory location that can be anything. To emulate this stuff in java its necessary to have a previously knowledge of the type of data the last address refers to so in Java things have to be done differently for security reasons.

[mithrandir]

There are a lot of other places that OpenGL uses void* as an argument - for example the vertex array methods. If you can do one dimensional, you can do n-dimensional structures. Since JOGL seems to currently magically support these other methods, I can’t see why that same magic can’t apply to something of more dimensions. In fact, it has already been done, not once, but at least twice. Have a look at the shader functions where there is 2-D arrays there that needed to be supported, and JOGL handles it fine. You’re making excuses that are invalid.

[zingbat]

Actualy (i may be mistaken of course) but in C if you have a void* you can’t dereference it as an array. Thats because C needs to know the type to find the array index.

If you have something like int* x then its perfectly possible to do

x[i]

and obtain an index value. A similar way to do it

((int)(sizeof(int) * i))

but much more cumbersome and almost like assembler code.

With a void* its meaningless to write sizeof(void). You need to know or guess what (void*) points to and then cast it to some known pointer type or union structure.

I don’t know much or nothing of opengl but void** is commonly used as an array of pointers to simulate a polymorphic collection. Something that can be implemented in java but its probably more efficently done using different techniques that take advantage of Java.

[princec]

void ** can’t be used sensibly in Java, it’s a big security hole. The IntBuffer you’d be a passing in would contain pointers, which are not available in Java. Therefore you’d be passing in, say, an array of IntBuffers instead.

But! glMultiDrawElements is a performance hack in C, and to use it in Java would be slower than to iterate over an array of IntBuffer[] with glDrawElements java-side. To do it in the C++ side you’d have to get a lock on the array, get each IntBuffer object out one by one, etc. So if you need to implement it, implement it in Java, where it will be faster.

So, no crack, just good sense.

Cas

[mithrandir]

I’m sorry, but you really are smoking some serious weed there. void** is nowhere near a security hole when used in Java. It is no more a security hole than int**, void* or any other pointer. These are pointers to a piece of memory. An address. Nothing more, nothing less.

There is no security hole anywhere, any more than having a reference to Object[] being passed to an ArrayList. You must do something with that array of objects - maybe iterate over them and place them in another structure (how is that different to Integer[]?), or cast them to a higher level object to pass to a C function call. In each case, the object is still a Java object and user code that the object is wrapping still doesn’t do anything. The operating system is reading from the piece of memory that the reference (pointer) is pointing to. It’s never executing the code. No function calls are being made using that object reference, so there is never any way for the code to escape from Java land (eg by having that object wrap a native library). It’s treated as a bucket of bytes to be read as an array of floats, any never anything different.

Claiming that they’re a security hole shows a fundamental lack of understanding of Java and how also it integrates with the underlying operating system.

[zingbat]

Hey calm down. I think that what he is trying to say is that if you convert a void** directly into a java array you loose the performance advantage since its a C trick that has no direct equivalent in Java. As for the security part hackers are very clever people. They exploit bugs on code that developers think are clean and secure. Reading some void** structure and then convert it to an Object[] could have problems if there was a bug in the native code that allowed hackers to do their dirty business. The main rule for secure programming is don’t trust your own code.

[princec]

Yes, that’s what I’m trying to say. There is no void** in Java, so you’d have several overloaded methods taking, say, IntBuffer[] instead, and the overhead outweighs the original purpose of the method which was simply to save jumping in and out of subroutines in C.

Cas

[kbr]

There will certainly be some overhead associated with calling a C function taking void** where the Java data type is e.g. Buffer[], but I’m unconvinced that this overhead will be huge. We had a similar debate over LWJGL’s use of raw C pointers rather than java.nio Buffers, and in the end it turned out that calling the JNI GetDirectBufferAddress entry point had negligible overhead.

Changes have just been checked in to the JOGL source tree (and in particular to the GlueGen tool) to convert Java types like Buffer[] and IntBuffer[] to C types like void** and int**. glMultiDrawElements has been exposed in the JOGL API, fixing Issue 71. These changes will be present in the forthcoming JOGL 1.1 beta 06. They have not been tested thoroughly, though, so if you all could, please take an update and file bugs if you find any issues.