I believe that on current (and recent) hardware it's all just "memory", and that the days where a driver may prefer to store different buffer types differently are behind us. This is definitely confirmed by e.g the Mantle documentation:

In the Mantle API, specialized vertex and constant buffers are removed in favor of more general buffer support. An application can use regular buffers to store vertex data, shader constants, or any other data.

In any event there may be organizational or data reasons to keep the buffers separate, but it appears as though you no longer have to.

Under D3D12, and since it has feature levels going down to 9, I would expect at some stage you'll want to keep them separate for performance reasons too, but I haven't looked at the D3D12 documentation in great detail.

With GL vertex layout is defined by vertex attrib function call, so you can mix different data type on the same buffer as long as you use correct offset/stride and pay attention to data alignment.

However I don't know if you can bind a buffer to several "type bind point", ie array_element_buffer and array_buffer, or array_element_buffer and shader_storage_buffer, at the same time. I never read it was forbidden by the spec but I don't know the spec by heart.

On D3D12 it isdefinitively be possible since you only pass gpu virtual address, gpu doesnt know that they belong to the same buffer from OS or app perspective.

Back in the day, GPUs weren't actually able to read indices from GPU memory. They were always streamed from main memory. But that is ancient history. Nowadays, on at least some hardware, I've heard that uniform buffers, texture buffers, and possibly shader storage buffers get special handling. The glBufferStorage API (which you should be using, not BufferData) requires you to pick a specific buffer type, not a mask. However on closer reading this appears to be simply a question of the buffer's binding point, not anything to do with the actual usage (which doesn't kick in until BindBuffer). I don't see anything offhand that says you can't bind the same buffer to more than one binding point, and from there it's just a question of offsets.

So yeah, go for it. I would be inclined to keep constant/uniform buffers and texture buffers separate from everything else, though.

I get the impression that mixing different kinds of data in single buffer (in old or current GL or D3D anyway) is not something you've done or seen done

unbird is the only one I've heard of. Without a clear indication that performance is drastically enhanced, it would be a bit of a pain to fill the buffer correctly (vertex-data + offset + index-data, or index-data + offset + vertex-data), if a D3D11 DrawIndexed call would be used for rendering. In spite of the advertised behavior, I was surprised when I (also) experimented and found that D3D11 didn't complain when the same buffer was bound to the input as both a vertex and index buffer! I didn't go further than that - i.e., I didn't calc the offset, fill the buffer, etc.

On modern OpenGL 4: You can use glBufferStorage to create a single chunk of memory that can be used for: vertex, index, constants, UAV and texture buffers. The first binding point the memory is used with can be used as a hint to the driver for performance, but it's just a hint (and afaik... ignored by modern implementations).

On D3D12: See OpenGL 4.

On D3D11: You can use same buffer for vertex & index buffers, but constants have their own. UAV and texture buffers have their own binding point as well.

On WebGL: Every buffer can only be used for one specific type for security reasons (the browser can assume what contents the buffer will contain and perform a lot of validation; as long as you don't modify the buffer again, the validation triggers when you upload data, if WebGL allowed multiple binding points, the validation would have to trigger every time it's bound differently or with a different range which could cripple performance).

@vlj: Your wording on it being forbidden by the spec somehow brought up one OpenGL-related thought I've had on background - the API may permit things, but may not actually work outside the common ways of use.

@Promit: I may very well be reading incorrectly between the lines, but I get the impression that mixing different kinds of data in single buffer (in old or current GL or D3D anyway) is not something you've done or seen done, at least enough to be a somewhat common pattern?

Correct, but that's not to suggest there's any issue with it. I've just never seen any of the documentation from the IHVs suggest that you should do it, so it never really crossed my mind to try it. I think it's a good idea if GPU memory fragmentation is a concern.

This was a few years ago: https://developer.nvidia.com/sites/default/files/akamai/gamedev/files/gdc12/Efficient_Buffer_Management_McDonald.pdf