Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Jun 2010
Offline Last Active Today, 06:28 PM

#5315426 CPU + GPU rendering with OpenGL

Posted by on 16 October 2016 - 09:04 AM

For the kind of workload described by the OP I'd suggest that writing to depth in the fragment shader is probably going to be OK.  It's likely that the sprites would need to be drawn back-to-front anyway, so early-z seems irrelevant here.

#5315354 Shader Permutations

Posted by on 15 October 2016 - 01:55 PM

UBOs aren't a GL 4.5 feature - they're core since 3.1; this may influence your decision on how to handle this.

#5315303 CPU + GPU rendering with OpenGL

Posted by on 15 October 2016 - 05:16 AM

Check your parameters to glTexImage2D - it's probable that the driver is having to do a format conversion before it can upload, e.g. if you're using GL_RGB (which doesn't actually exist in hardware).

#5315124 Comparing id3d11inputlayouts

Posted by on 14 October 2016 - 02:31 AM

I can simple use strcmp to compare them and be done with it.

Beware - they're not 0-terminated so use memcmp instead.

#5315027 Comparing id3d11inputlayouts

Posted by on 13 October 2016 - 12:59 PM

@mhagain: can you give me some rough outline/ pointers on how to create a hash 'key'/ value based on the elements's name and dxgi formats? (Unfortunately no hashing experience here)


Just take the array of D3D11_INPUT_ELEMENT_DESC and pass it into your hashing function.  The name and format is insufficient; you need all of the D3D11_INPUT_ELEMENT_DESC members to ensure uniqueness.  It's just a lump of binary data so do something like:


D3D11_INPUT_ELEMENT_DESC layoutElements[] = {.......};


// assume that HASH is the type of hash generated by your hashing function and

// that the signature of HashFunction is (void *data, size_t length)

HASH hash = HashFunction (layoutElements, sizeof (layoutElements));


For a hashing library I've found that MD5 is probably sufficient for this purpose; CRC16 is definitely not good enough.  See this StackOverflow question for other suggestions and discussion: http://stackoverflow.com/questions/4678447/md5-and-sha1-c-hashing-library


From there the concept is that rather than storing the input elements in your ShaderManager class you instead store the hash (16 bytes) and compare the incoming hash with stored hashes to determine equality.

#5315000 Comparing id3d11inputlayouts

Posted by on 13 October 2016 - 09:53 AM

In the past I've taken a hash of the elements array.  It doesn't need to be a cryptographically secure hash, but does need a sufficiently low number of possible collisions.

#5314718 Fast Approximation to memcpy()

Posted by on 11 October 2016 - 01:18 PM

50% accuracy!

for (int i = 0; i < len; i += 2)
    dst[i] = src[i];

#5314664 Fast Approximation to memcpy()

Posted by on 11 October 2016 - 07:57 AM

Since you asked for an "approximation" to memcpy:


void *src; // assumed that this is set to something valid

void *dst; // assumed that this is set to something valid


dst = src;


There you go!  Approximately equivalent to memcpy!

#5314527 Variable lights count

Posted by on 10 October 2016 - 07:12 AM

Draw with multiple passes; this is the way Doom 3 did it, which used OpenGL and was targetted to a similar GL version.


First pass was a depth-only pre-pass and the screen was cleared to black.

Then enable additive blending (glBlendFunc (GL_ONE, GL_ONE);)

Then each subsequent pass draws one light and one light only, adding the contribution for each light into the framebuffer.


It's all about tradeoffs; you use a single shader irrespective of number of lights which means fewer state changes and keeping the shader instruction count down, in exchange for more draw calls and extra blend passes.  It also makes it easier to integrate shadows if you're planning on doing so in future.

#5314517 Texture mapping coordinates for OpenGL and DirectX

Posted by on 10 October 2016 - 02:50 AM

So both API use 0,0 UV for the bottom left corner?


OpenGL uses {0,0} for bottom-left, D3D uses {0,0} for top-left.


However, when you're loading data to a texture, OpenGL begins loading at bottom-left and D3D begins loading at top-left.


So what happens in practice is that the differences cancel each other out and you can use the same texcoords for both.

#5313874 Converting resources GPU/CPU

Posted by on 04 October 2016 - 08:55 AM

Ok. Say I have 2Gb on my video card. If I load 3Gb's of images into my program, it will all be in CPU memory and will be passed to the video card when needed?




What will likely happen is that each resource will go into video memory as it is loaded.  When you run out of video memory, the least-most-recently-used resource(s) will be swapped out of video memory to make room.

#5313826 Converting resources GPU/CPU

Posted by on 04 October 2016 - 02:47 AM

So the shader resources are not on in GPU memory already?


No, they are.


What will happen is that the move from GPU memory to CPU memory and back is handled automatically.


What "The OS will then try to make sure that those resources are available in GPU memory, potentially moving things to or from system memory" means is that if the resource is already in GPU memory then it doesn't need to be moved.

#5313681 How to put different textures on different sides of a Cube in DirectX 11?

Posted by on 03 October 2016 - 02:49 AM

As an alternative to cubemapping use a standard texture array with 6 slices.  Your texture coordinates become 2 floats and an int rather than just 2 floats, with the 2 floats being the very same as what you would use for a standard 2D texture and the int specifying which slice to sample from.  Use Texture2DArray::Sample rather than Texture2D::Sample in your HLSL, and beware of some tutorials (e.g. the popular RasterTek one seems to suffer from this) that try to teach you that a texture array is just an array of textures (it's not).

#5313248 peekmessage while vs if (main/game loop)

Posted by on 29 September 2016 - 08:43 AM

@Norman barrows: the book (D3D11 Luna) focusses on learning, not performance.

I wouldn't consider that "performance"; I'd consider it "getting the basics right".  Put it this way: if tutorial code that I expected to learn from was actually teaching me fundamental bad practices, I'd be mightily annoyed at the tutorial.  I should demand no less of a professionally written book.

#5313193 Amd openGL driver crashes

Posted by on 29 September 2016 - 02:42 AM

a->Data = (void*)(U64)glCreateShader(type);


glCreateShader returns a GLuint which is mandated to be 32-bit by the spec.  It looks like you're casting it to a 64-bit type here so you've got a buffer overflow.  This might or might not be the cause of your crash, but either way you shouldn't be doing it.


Also, you may or may not be aware of this, but if you run a 32-bit program on 64-bit Windows, pointer types are still 32-bit.


I'd suggest that you hunt down and clean up anything like this first.