Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 21 Jun 2009
Offline Last Active Aug 12 2015 09:00 AM

Topics I've Started

Explicit uniform buffer location

20 February 2015 - 11:19 AM

Is there a way to specify explicit uniform buffer location in GLSL?

I am aware of the "layout (binding = 0)" specifier, but that's not what I'm looking for.


What I want is something like:

// GLSL code
layout (location = 4) uniform SomeBuffer

// C Code
assert(4 == glGetUniformBlockIndex(ProgramID, "SomeBuffer"));

But layout(location) doesn't seem to work for uniform buffers.

Is there a way to do it?

OpenGL samplers, textures and texture units (design question)

10 January 2015 - 02:20 PM

I'm porting a DX rendering framework to OpenGL. The DX framework follows the DX API - there is no relation between the samplers and the textures, and binding them to shaders is done seperatly. A pseudo-code of the DX framework looks like

pProgram->SetSampler(sampler_shader_var_name, pSomeSampler);
pProgram->SetTexture(texture_shader_var_name, pSomeTexture);

So from the user prespective, both are just another type of shader variables.


I'm trying to achieve the same simplicity using OpenGL, but the way GL works complicates things.

The problem is that samplers are not bound to shader variables, but to a texture unit. Once the sampler is bound to the texture unit, it affects all textures bound to the same texture unit.

The simplest solution is to let the user manage texture units on its own, but that means losing the abstraction.

Another solution is to create a psuedo-sampler state (not a GL object), then let the user bind it to the texture, and change the texture's sampler parameters. This is not good since it means I can only use one sampler at a time with each texture.


I have a bunch of others solutions, but nothing as clean as the DX code.


Well, I'm stuck. Spent the last 4 hours thinking, coding, deleting and vice-versa. Any advice on a clean way to it?

GLFW and multisampled backbuffer

23 December 2014 - 11:02 AM


I'm using GLFW to initialize a window and a context. I use this to ask for a multisampled backbuffer:

glfwWindowHint(GLFW_SAMPLES, RequestedSampleCount);

GLFW doesn't treat this sample count as a hard constraint, so it can create a framebuffer with a different sample count.


What's the simplest way to find the actual sample count of the back-buffer? I don't think GLFW exposes it, and using WGL to find this number is OS specific.



StructuredBuffer and matrix layout

14 September 2014 - 02:40 AM

Not sure if this is a bug of a feature, but apparently this code always generates column-major matrices:


This is regardless of using D3DCOMPILE_PACK_MATRIX_ROW_MAJOR or #pragma pack_matrix(row_major).

Anyone has an elegant way to fix it? It's a real irritating 'feature'.

HLSL compiler weird performance behavior

08 September 2014 - 08:13 AM

I have this animation demo, which takes quite a few seconds to load. I initially thought that it was related to the model, but apparently the culprit is the skinning VS, and specifically the bones-matrices.

The VS looks like

cbuffer cbPerMesh : register(b1)
	matrix gBones[256];

struct VS_IN
	float4 PosL : POSITION;
	float3 NormalL : NORMAL;
	float2 TexC : TEXCOORD;
	float4 BonesWeights[2] : BONE_WEIGHTS;
	uint4  BonesIDs[2]    : BONE_IDS;

struct VS_OUT
	float4 svPos : SV_POSITION;
	float2 TexC : TEXCOORD;
	float3 NormalW : NORMAL;

float4x4 CalculateWorldMatrixFromBones(float4 BonesWeights[2], uint4  BonesIDs[2], float4x4 Bones[256])
	float4x4 WorldMat = { float4(0, 0, 0, 0), float4(0, 0, 0, 0), float4(0, 0, 0, 0), float4(0, 0, 0, 0) };

		for(int i = 0; i < 2; i++)
			WorldMat += Bones[BonesIDs[i].x] * BonesWeights[i].x;
			WorldMat += Bones[BonesIDs[i].y] * BonesWeights[i].y;
			WorldMat += Bones[BonesIDs[i].z] * BonesWeights[i].z;
			WorldMat += Bones[BonesIDs[i].w] * BonesWeights[i].w;

	return WorldMat;

	VS_OUT vOut;
	float4x4 World = CalculateWorldMatrixFromBones(vIn.BonesWeights, vIn.BonesIDs, gBones);
	vOut.svPos = mul(mul(vIn.PosL, World), gVPMat);
	vOut.TexC = vIn.TexC;
	vOut.NormalW = mul(float4(vIn.NormalL, 0), World).xyz;
	return vOut;

As you can see, this shader supports up to 256 bones per model. Compiling this shader takes around 5 seconds on my Core-i7 CPU.

If I reduce the number of supported bones to 16, it compiles almost immediately.

Funny thing is that the generated assembly is exactly the same (except for the CB declaration).


I find it weird - the code doesn't rely in any way on the matrices count.

Anyone has any idea why the performance degradation?