Jump to content

  • Log In with Google      Sign In   
  • Create Account

FantasyVII

Member Since 13 Jul 2012
Offline Last Active Jul 28 2016 06:53 AM

Posts I've Made

In Topic: "no Shaders Attached To Current Program" Only In Release Build

16 July 2016 - 05:34 PM

I edited my post before I saw your reply. Check the last bit as I think that might be your issue.

 

 

 

I thought It is always a good idea to pass by reference so you wouldn't wast memory and cpu cycles copying from one variable to the other. This way both variables have the same memory address.

 

I'm no expert on this so take it with a grain of salt but you should be very very careful when using pass by reference, passing things into functions by reference is often a good idea particularly with very large objects (otherwise they have to be copied each time). You should try to pass in const references though unless you know the function will/must modify your object. It's often unnecessary to pass things like ints and floats by reference but passing something like a string by reference usually makes sense.

 

Where it all goes very bad is when you start returning references. This can have it's uses but don't use it as a rule  of thumb, it's more an exception rather than a norm and you need to be very careful that the thing you are returning the reference from is going to outlive the thing you are returning it to. Also you are just returning an int which will likely be the same size as an int& (depending on your system) so you don't gain any extra memory from doing it. The same goes for passing references into functions for types such as ints, it's likely the same size as a reference (again, depending on your system).

 

It is as you say, the reference is essentially just a pointer pointing to memory and you return a reference to something allocated on the stack, as soon as that function returns the local variable no longer exists but the memory still does and could contain anything. The way you are using it I guess there isn't a chance for that memory to get reused so it's lucky the 'value' stays the same but you shouldn't do that.

 

 

Alright, cool.

Thanks ! :D


In Topic: "no Shaders Attached To Current Program" Only In Release Build

16 July 2016 - 05:03 PM

 

Alright, I did some more investigating and for some reason glAttachShader is return an error code of 1281. I have no idea why. In debug mode it returns 0.

 

In that case which of these values are not as expected?

            glAttachShader(programID, vertexShader);
            glAttachShader(programID, fragmentShader);

If programID ok, is vertexShader ok, is fragmentShader ok?

 

I just noticed this:

GLuint &GLShader::CompileShader(std::string shaderCode, GLenum shaderType)

You are returning a reference to a local variable that is a bad idea. Surprisingly I did a quick test and (in my test at least) it did return the value I would expect in both debug and release build but you really shouldn't be doing that. I am surprised it works but I am no expert.

 

 

 

Alright, removing the reference from CompileShader fixed the problem.

 

Can you explain to me why is this bad? What was actually happening when I was passing it by reference ?

I thought It is always a good idea to pass by reference so you wouldn't wast memory and cpu cycles copying from one variable to the other. This way both variables have the same memory address.

 

wait, wait, wait.....

 

I think I know why.

Ok, so i'm just guessing here but here is my theory.

When I return by reference to a local variable from a function, this variable will be removed from the stack because the function finished it's work and since both variables have the same memory address they will both be deleted and I will just point to an empty memory address.

 

How off am I?

 

 

[edit]

Quote from Stackoverflow

 

This code snippet:

int& func1()
{
int i;
i = 1;
return i;
}

will not work because you're returning an alias (a reference) to an object with a lifetime limited to the scope of the function call. That means once func1() returns, int i dies, making the reference returned from the function worthless because it now refers to an object that doesn't exist.

 

 

wow, I wasn't off at all. yay, I'm not stupid...

Well, I made this mistake so.... yeah.. :P

 

Thanks ! :)

 

 

[Edit 2]

 

 

You should really check these return values when before you use them too. Don't just print an error then carry on as if there was no error. Could you paste the full log you get when you fail to compile the shader? It might be an idea to post the shader code too. Also, is it the vertex or the fragment shader that isn't compiling?

 

Print the actual code you pass to the shader, ({after doing your split function). Is everything null terminated correctly? I remember having issues at some point where I wasn't doing that step correctly and I had junk on the end of my shader which prevented it from compiling. This isn't an issue in debug because the whole length of memory is usually initialised to 0 so the string ends up being null-terminated but in release this isn't the case. Make sure your code stops where it should stop.

 

 

Here is my shader code

#Vertex Shader
#version 450 core
layout(location = 0) in vec3 inPosition;
layout(location = 1) in vec3 inColor;

out vec3 fragmentColor;

void main()
{
	gl_Position = vec4(inPosition.xyz, 1.0f);
	fragmentColor = inColor;
}

#Fragment Shader
#version 450 core

in vec3 fragmentColor;
out vec3 color;

void main() 
{
	color = fragmentColor;
}

and here is the code after splitting

 

Vertex shader

#version 450 core
layout(location = 0) in vec3 inPosition;
layout(location = 1) in vec3 inColor;

out vec3 fragmentColor;

void main()
{
	gl_Position = vec4(inPosition.xyz, 1.0f);
	fragmentColor = inColor;
}

Fragment Shader

#version 450 core

in vec3 fragmentColor;
out vec3 color;

void main() 
{
	color = fragmentColor;
}

and here is the output of the compiled vertex and fragment shader.

GLuint vertexShader = CompileShader(vertexShaderCode, GL_VERTEX_SHADER);
GLuint fragmentShader = CompileShader(fragmentShaderCode, GL_FRAGMENT_SHADER);

std::cout << vertexShader << " " << fragmentShader << std::endl;

//Bad output
VertexShader output:- "2724212624"
FragmentShader output:- "2775447968"

//Correct output
VertexShader output:- "1"
FragmentShader output:- "2"

Again, thanks :)


In Topic: "no Shaders Attached To Current Program" Only In Release Build

16 July 2016 - 04:31 PM

Alright, I did some more investigating and for some reason glAttachShader is return an error code of 1281. I have no idea why. In debug mode it returns 0.


In Topic: "no Shaders Attached To Current Program" Only In Release Build

16 July 2016 - 04:03 PM

Differences between release and debug builds are commonly due to uninitialized stack variables: the debug memory allocator will typically initialize these to something well-known, the release allocator will not and you'll just get stack garbage.

 

I just went through my entire code base and made sure that everything is Initialized as a member list. I also made sure that every variable in a function is initialized, but i'm still having the same problem. I'm out of ideas. :(


In Topic: casting double* to float*

17 March 2016 - 04:55 PM

The most significant performance hit for using doubles will probably come from the CPU cache misses and memory bandwidth caused by them taking up twice as much memory.

 

In addition SSE instructions can handle four floats at a time, but only two doubles at a time. So for code which uses them the performance hit can be significant.

 

For basic operations on values in registers, floats aren't significantly faster than doubles. For some more complex operations (like division) doubles will be slower than floats, as they have more precision, but overall you probably won't notice much difference.

 

For details on specific instructions look at Intel's optimization manual - http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html (for example you can compare the divsd and divss instructions there, to see the timings for float vs double division).

 

Yep. that's what I thought. I have been reading a lot about cache optimization and fitting everything on the cache line. It's very interesting.

Thanks happy.png


PARTNERS