OpenGL 3.1

OpenGL
41

How often you reconfigure your FBOs? Sure, FBO should be immutable object. Why we need all this entry points like glFramebufferTexture2DEXT/3DEXT etc if we can define a structure?

Draft minds:

enum GL4_TEXTURE_TARGET
{
GL4_TEXTURE_1D = 0,
GL4_TEXTURE_2D,
GL4_TEXTURE_3D
// and so on
};

enum GL4_DEPTH_STENCIL_ATTACHMENT
{
GL4_DEPTH_ATTACHMENT = 0,
GL4_DEPTH_STENCIL_ATTACHMENT
};

struct GL4_FRAMEBUFFER_COLOR_ATTACHMENT_DESC
{
GL4_TEXTURE_TARGET TextureTarget;
GL4handle Texture;
GLuint MipLevel;
GLuint ZOffset; // use only for 3D textures
// and so on
};

struct GL4_FRAMEBUFFER_DESC
{
GL4_FRAMEBUFFER_COLOR_ATTACHMENT_DESC ColorAttachments[ GL4_MAX_COLOR_ATTACHMENTS ];
GL4_DEPTH_STENCIL_ATTACHMENT DepthStencilAttachment;
GL4handle DepthStencilBuffer;
};

// user code:

GL4_FRAMEBUFFER_DESC Desc;

Desc.ColorAttachments[0].TextureTarget = GL4_TEXTURE_2D;
Desc.ColorAttachments[0].Texture = m_MyTexture;
Desc.ColorAttachments[0].MipLevel = 0;
Desc.DepthStencilAttachment = GL4_DEPTH_STENCIL_ATTACHMENT;
Desc.DepthStencilBuffer = m_MyDSBuffer;

// Create immutable FBO, all validations are occurs here.
GL4handle FB = gl4CreateFramebuffer( &Desc );
if (FB == GL4_INALID_HANDLE)
{
// Unsupported fbo.
}

If we want to encompass new functionality, we can extens struct GL4_FRAMEBUFFER_COLOR_ATTACHMENT_DESC like this:

struct GL4_FRAMEBUFFER_COLOR_ATTACHMENT_DESC1 // GL 4.1
{
GL4_FRAMEBUFFER_COLOR_ATTACHMENT_DESC Desc4;
GL4uint AdditionalMember;
};

and create new entry point like gl4CreateFramebuffer1(). // GL 4.1

42

Unfortunately, using this technique you are likely to run into packing/alignment issues across different platforms.

Regards
elFarto

43

This is not a structure of vertex itself, it’s just a description of attributes layout, so no issues with alignment.

44

What if you have n independent extensions that need additional members? You’d end up with 2^n different struct definitions.

Plus you need to guarantee that the struct memory layout used by implementations is the same as that used by applications.

45

Plus you need to guarantee that the struct memory layout used by implementations is the same as that used by applications.

Don’t forget that non-C languages have to be usable too. And their “struct-equivalents” are entirely different and usually incompatible.

There is a reason why Longs Peak had “templates” that were created and modified through a series of generic functions.

46

FYI, a thinly veiled copy of the d3d10 API isn’t going to win you many points around here. A few points for amusement, perhaps, but few if any for originality.

P.S. You can mix floats and ints in 2 lists (not that you’d really want to).

47

Xmax, please post some “real” examples about extensions for vertex attributes layout. It stay unchangeable in OpenGL for decade, except that glVertexAttribPointer() entry replace and generalize all FFP glXXXPointer() entries.

48

modus, it’s pleasant that you are familiar with D3D10. Yes, i’ve found that it design is very pretty and want to see some of it decisions in OpenGL, rather than crappy glVertexAttribPointer() and handreds of other entry points and token names. I try to proof that C-struct mechaninsms can be used in API, even in some extensible form. Of course not all parts of API can be extended with structs, but major parts - sure.

49

I try to proof that C-struct mechaninsms can be used in API, even in some extensible form.

And your proof has failed. Everyone’s pointed out the problems with it. Like I said, there’s a reason why Longs Peak was going with Templates and not actual structs. They’re far easier to extend, far easier to use in non-C languages, and so on.

Also, as I keep pointing out, if the ARB wanted to create a new API, they’d have done so by now. They clearly have no interest in it or we’d have Longs Peak.

50

As for me, structures are easier to use, probably a few harder to extend, but possible. In what languages structures are unavailable? I know C/C++, Pascal, C#, Java all used structs. To avoid alignment issues, ports can use compiler directives to force align structure members to 8-byte boundaries, for example.

>Also, as I keep pointing out, if the ARB wanted to create a new >API
ARB definitely interested in object model, but maybe simply lack of ideas/communication/no forward thinking or something else. As Barthold wrote on this page http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=243193&fpart=7
“We ran into details that we couldn’t resolve cleanly in a timely manner”.

It’s just a humble proposals of next GL version design, for starting discussion, voting etc.

51

I don’t want to appear as a show-stopper here, but aren’t there already enough threads about “the next GL version design” and similar rants around this board?

Could you please start your own thread (let’s call it “OpenGL 4.0”), instead of hijacking the only really constructive thread on this forum? Remember, this thread is called “OpenGL 3.1”, and it started out strictly with suggestions for new features that extend the current OpenGL 3.0 proposal.

I hope the people in charge of the spec are still going to notice the suggestions at the beginning of this thread, despite all the noise…

52

Thank you Overmind. We all wanted the object model that was described in pipeline newsletter, it was perfect. Suggesting a brand new API that looks suspiciously like DX10, as modus said, won’t do you any favours. If we wanted to use DX10, we would.

Regards
elFarto

53

Binary shader program blobs! It would save so much time each time my app is run! I just want to be able to link a shader program, read it back as a binary blob and save that to disk, then when I run my app again I can quickly load the binary blob as a shader program, rather than wait for shaders to be compiled from text all over again.

It could be a simple extension to the shader_objects extension:

void GetProgramBlobARB(handleARB programObj, sizei maxLength, sizei *length, void *blob)

//returns false if the data is invalid - this may occur if a driver has been updated. In that case it’s necessary to build the program from source again.
bool LoadProgramBlobARB(handleARB programObj, sizei length, const void *blob)

54

Thinking about it, a glNamedVertexAttribPointer, where we just add the vertex array object to the parameter list, isn’t going to be good enough.

We’ll need:

void glNamedVertexAttribPointer(
	GLuint		vao, 
	GLuint  	index, 
	GLint  		size, 
	GLenum  	type, 
	GLboolean  	normalized, 
	GLsizei  	stride, 
	GLuint		buffer,
        GLuint		offset);

Where buffer is the VBO you wish to use, and offset is the position of the first attribute in the buffer. This gets rid of all dependent and latched state.

This function also nicely precludes the use of client arrays.

Regards
elFarto

55

Don’t Disturb, like this? http://www.khronos.org/registry/gles/extensions/OES/OES_get_program_binary.txt

56

Definately NOT like that, that extension requires you to GUESS how big the binary will be and pre-assign a buffer for it.
It also has an unnecisarily complex syntax.
The driver should create the binary blob with a simple header that gives the total blob size and defines the manufacturer, hardware model and driver version.
The command should be more like:
*void GetProgramBinary(uint program)
which returns a pointer to the blob, the application then only needs to read the size uint in the header to write it to disk.

57

Definately NOT like that, that extension requires you to GUESS how big the binary will be and pre-assign a buffer for it.[/QUOTE]
What’s so hard about using PROGRAM_BINARY_LENGTH_OES to read the buffer size?

58

The driver should create the binary blob with a simple header that gives the total blob size and defines the manufacturer, hardware model and driver version.

Absolutely not. You should hand the driver a pre-sized buffer, where it then writes the binary blob. I don’t want an extension to have to specify things like the lifetime for the memory for binary blobs.

This extension is exactly what is needed. The syntax is quite good.

59

Its an extra call to the driver.
When writing the blob to disk its size has to be written as well.
Much simpler to do it in the one operation.

We can agree to disagree on this point, i can see 3 ways to do this:
1/ (OES’s)
Call GetInteger(PROGRAM_BINARY_LENGTH)
allocate memory
Call GetProgramBinary (copies binary to your buffer)
Insert BlobSize and BinaryFormat values into buffer
Write to disk
De-allocate memory
2/
Call GetProgramBinary (makes an internal copy of binary)
Write to disk
Call DeleteProgramBinary
3/
Call GetProgramBinary (returns read-only pointer to existing binary)
Write to disk
<Blob pointer remains valid until your next call to re-link the rogram>

The OES method seems to be the most complex to me.

Even the enum for the BinaryFormat?
This creates a new set of enums that someone will need to manage.
Every time an IHV wants to add a new format they will need to apply to someone for a new value.
And why do we need it? Why would i ever want to query the available formats with GetIntegerv(PROGRAM_BINARY_FORMATS_OES) or find out which one my blob uses.
The whole idea of a “Binary Blob” is that i dont need to know anything about it besides its size.
The only part of it that needs to be standardised is a way to distinguish between IHV’s, and this needs to be part of the blob because the only thing i need to with it is write it to disk with the blob.
Everything else, including the PROGRAM_BINARY_FORMAT, should be part of the IHV blob because nobody but the driver needs to know anything about it.

60

When writing the blob to disk its size has to be written as well.

Maybe. The Operating System may write it to disk, but there’s nothing that says you need to write the size to the file. You can just ask the OS how big the file is when you load it.

The OES method seems to be the most complex to me.

If you consider that complexity to be significant in any way, how can you use OpenGL?

Even the enum for the BinaryFormat?

Hey, this extension was written by IHVs. If they think it’s important, I’m happy to put it somewhere and regurgitate it on command. So long as I don’t have to compile/link all my shaders each and every time I load my program, I’m happy.