Jump to content


Member Since 07 Nov 2002
Offline Last Active Today, 01:19 PM

Posts I've Made

In Topic: GLSL Error C1502 (Nvidia): "index must be constant expression"

14 October 2015 - 02:34 PM

This overlaps with what Matias said, but is from a bit different perspective, and I'm not someone with too much actual in-depth knowledge, but here goes anyway:


The array of blocks syntax creates several blocks, with separate binding points for each, and each of them can be backed by a completely different buffer. My intuition says indexing blocks is therefore possibly implemented very differently than indexing within a block, where arrays are actually laid sequentially in memory.


On second thought, on cards where the blocks are only 16kb at most or something similarly small, the data could be copied around in the GPU when glBindBufferRange or glBindBufferBase is called so that they end up being laid out in an array for the shader to access, but there doesn't seem to be any guarantee for that to be case.


I also just tried a very simple vertex shader with an array block, and the program crashes at shader linking in a way that hints the cause might be outside my code. The code has so far worked well in other (simple test) cases and the reference compiler has no complaints about the shader, but of course there's still a chance it's a bug in my code. (In any case, I'm running on an oldish Radeon card on Linux with the free drivers, so knowledge of this potential bug may not be very relevant to you.)

In Topic: Why is glGetShaderiv(); crashing my written program.

13 June 2015 - 09:34 AM

There still seems to be a potential problem in the code. ShaderCompileLOG is defined to be 256 bytes long, but ShaderCompileLENGTH is passed to glGetShaderInfoLog. After the latter glGetShaderiv, ShaderCompileLENGTH will contain the actual length of the info log, which might be more than 256 bytes long! Still, the buffer given to glGetShaderInfoLog will always be just 256 bytes, so OpenGL would end up trying to write more text to the buffer than it can contain.


The easy way to fix this is to pass 256 as the maxLength parameter to glGetShaderInfoLog. Using a constant is probably a good idea to make sure the array length and the parameter stay in sync. Of course, if the log is longer than that, you will get only part of the data, so vstrakh's suggestion of allocating memory for the log text (ShaderCompileLENGTH bytes, to be exact) can be a good idea in that regard too.

In Topic: What are your opinions on DX12/Vulkan/Mantle?

08 June 2015 - 12:47 PM

Apple has announced their upcoming OS X version El Capitan. Thought that it would be relevant to this thread, as it will bring support for their Metal API to OS X.


I have no details, but apparently there has been claims of 50 % improvement in performance and 40 % reduction in CPU usage.

In Topic: Vulkan is Next-Gen OpenGL

20 April 2015 - 06:35 AM

It's nice to notice the video is recorded on a KDE desktop, hinting it's running on Linux. I suppose that also implies the demo is run with an Intel GPU. Well, I guess it's actually the video being a LunarG demo that implies it being run on Intel GPU, my understanding is that they wrote the Intel Linux driver.

In Topic: Vertices and indices in the same buffer?

06 April 2015 - 10:35 AM

Seems kind of curious that using big combined buffers in pre-AZDO world has apparently not really been a thing, considering it could maybe be used to minimize state changes when editing buffer contents, if the "AZDO approach" is to use them as larger memory pools. Like, how hasn't it been a thing earlier? I guess there just isn't that much benefit (with the older GL API at least), when combining buffers of single usage type alone creates large enough blocks of memory, along with keeping things conceptually easier to grasp. Oh well, I'm not advanced enough graphics programmer to make any strong conclusions.


Anyway, I think I'll choose to have just a general Buffer type instead of artificially separated VertexBuffer, UniformBuffer et cetera (this approach actually still entices me, I'm a little bent on having strict compile-time sanity and validity checks), though mostly from the viewpoint of there being less code in general.


Thanks for your feedback!