next »

[powly]

I'd say skip VAOs and attributes in GL and skip vertex buffers and input layouts in D3D. Just go with generic buffers for vertex attributes. The only vertex shader specific input you need is the vertex index. This results in the exact same operations performed by the hardware and saves a great amount of API hassle.

[Crimsontide]

I'd say skip VAOs and attributes in GL and skip vertex buffers and input layouts in D3D. Just go with generic buffers for vertex attributes. The only vertex shader specific input you need is the vertex index. This results in the exact same operations performed by the hardware and saves a great amount of API hassle.

Actually, as much as I'd like to agree with you, there is still a lot of hardware out there where input layouts is faster than manual fetches from a vertex shader.  As far as AMD/NVidia are concerned I'm not sure, but I know (know as in have read, not personally experienced...) most of the Intel chips input layouts are much faster, as well as with many mobile GPUs.

As much as I'd love to see them ditch the IA and rework vertex shaders to be more of a geometry generation shader (the notion of 1:1 input vertex to output vertex is rather antiquated at this point IMHO), we sadly are not there yet.

[Cheezmeister]

I'm still quite fuzzy on the difference between VAOs and VBOs in OpenGL. Any good reading material that explains the difference in plain English?

[powly]

VAO is an OpenGL object holding bunch of vertex attribute and bind state, VBO is a bit of a misnomer since it refers to just any OpenGL buffer object that happens to be bound to a vertex attribute.

most of the Intel chips input layouts are much faster, as well as with many mobile GPUs.

This is most likely true but for any desktop NVIDIA/AMD card that even allows this kind of approach the performance is the same. And you're correct; this isn't the go-to solution yet. I kind of hope that some day it will be. In the meantime, it's a very neat shortcut if you do stuff that already requires a pretty beefy GPU.

[qMopey]

https://en.wikipedia.org/wiki/Vertex_Buffer_Object

Pretty much all the buffer stuff. The point is you can make a buffer to upload data to the GPU through a big array, instead of calling immediate mode functions (glVertex3f et al).

[powly]

The point is you can make a buffer to upload data to the GPU through a big array

Not only this but also to store it on the GPU so if subsequent frames use the same mesh you can reuse the data instead of resending it over PCI-E each time. Or you could generate the vertices on the GPU and then render them; great for generating all sorts of large procedural meshes. Essentially it saves on time spent moving data between RAM and VRAM.

You could also do vertex arrays straight from RAM. Essentially you don't bind anything as the current buffer. After this the offset pointer in glVertexAttribPointer refers to main memory instead of a GPU-side buffer and you can just give a normal CPU-side pointer to the data.

[qMopey]

Just to clarify, a vertex array makes use of those old glVertexAttribPointer functions, as in, hard-coded attributes, right? And a VBO uses the generic attribute?

[JWki]

Just to clarify, a vertex array makes use of those old glVertexAttribPointer functions, as in, hard-coded attributes, right? And a VBO uses the generic attribute?

Vertex Array Objects aka VAOs simply store the state you set by using glVertexAttribPointer as well as the current VBOs being bound to the different slots. With modern OpenGL, you can use them in a way such that they only store the current input layout and use glBindVertexBuffer to mix that up with different vertex buffers, making it equivalent (more or less) to the input layout objects that other APIs have.

[ferreiradaselva]

I'd say skip VAOs and attributes in GL and skip vertex buffers and input layouts in D3D. Just go with generic buffers for vertex attributes. The only vertex shader specific input you need is the vertex index. This results in the exact same operations performed by the hardware and saves a great amount of API hassle.

Unfortunately, you can't skip since it's obligatory to have at on GL >= 3.2 and core, which is the whole upsetting thing.

You could also do vertex arrays straight from RAM. Essentially you don't bind anything as the current buffer. After this the offset pointer in glVertexAttribPointer refers to main memory instead of a GPU-side buffer and you can just give a normal CPU-side pointer to the data.

VBOs are at least very flexible, I can't complain about it. I'm using similar approach as you describe, since I modify the vertices (against the model matrix) on client-side.

I've done that before I knew about what VAOs were.

In tinygl I create a single VAO because it is required, and I never do anything with it. https://github.com/RandyGaul/tinyheaders/blob/master/tinygl.h#L291-L293

That's what I will be doing today .

But when we say "clean up" it is very subjective! Personally I think hiding all of these attribute states behind a VAO is a poor use of abstraction. VAOs are an abstraction of state. This abstraction does hide the details in the above link, but personally I think these details are important to lay out in the open. It gives a clearer picture of exactly how GL is used in tinygl.

I agree with that. Also, if you decide to target computers with an older GL version, if you remove VAOs from the way, you have at least something less to worry during porting.

[powly]

Unfortunately, you can't skip since it's obligatory to have at on GL >= 3.2 and core, which is the whole upsetting thing.

This is not true. While you do need a VAO to bind VBOs to vertex attributes, you can just not use vertex attributes at all. To load data you just bind a generic buffer and read it based on gl_VertexID.

VBOs are at least very flexible, I can't complain about it. I'm using similar approach as you describe, since I modify the vertices (against the model matrix) on client-side.

VBOs are flexible but I find the setup overly verbose and thus a bit clumsy.

[gimymblert]

this is the best thing i've ever seen

Link is dead, what was it? mirror?

[oahda]

Weird. I think it was this:

[powly]

Unfortunately, you can't skip since it's obligatory to have at on GL >= 3.2 and core, which is the whole upsetting thing.

This is not true.

Ha, finally tested this and found out I was completely wrong! You still don't have to have any VBOs but a VAO is strictly required.

[oahda]

https://codegolf.stackexchange.com/questions/11880/build-a-working-game-of-tetris-in-conways-game-of-life

[Cheezmeister]

https://codegolf.stackexchange.com/questions/11880/build-a-working-game-of-tetris-in-conways-game-of-life

Unless that's running inside Minecraft on a virtual workstation in Half-Life 3, not yodawg enough. =P

[oahda]

lololol

[ProgramGamer]

What he's actually doing is this, right?

Code:

let i = 15;
while(i-- > 10)
{
    //Do something
}

[oahda]

yes

disclaimer: op was joking too

[ferreiradaselva]

https://michaldrobot.com/2014/04/01/gcn-execution-patterns-in-full-screen-passes/

tldr: when drawing a background, drawing a single triangle that covers the entire window is faster than drawing two triangles (a quad). 10% faster.

[ThemsAllTook]

Clever! I'd never thought of doing it that way.