• Advertisement

AverageJoeSSU

Member
  • Content count

    775
  • Joined

  • Last visited

Community Reputation

564 Good

About AverageJoeSSU

  • Rank
    Advanced Member
  1. Direction for a seasoned web dev

    NCsoft just released a fully featured javascript plugin for unreal engine 4. For someone like you that might be a fun thing to hammer on.    https://wiki.unrealengine.com/Unreal.JS   https://forums.unrealengine.com/showthread.php?92022-Unreal-js
  2. [solved] re-committed sparse texture is mangled

    Unfortunately it seems like TexPageCommittment is a blocking operation?
  3. [solved] re-committed sparse texture is mangled

    Fixed! somehow the format passed to subimage either changed the second time around, or mattered the second time around, prolly the former. UGH. at least i found it.
  4. Puzzling issue. I have a code path that creates a sparse texture, and returns a Texture that is committed and sparse.   I then can uncommit it, which turns the texture to black ( i am rendering it onto a quad). If i then commit it again, which is the same path as was used when the texture was first created (minus the storage part), the texture appears but is totally mangled.   I checked width and height and texid values and format values, and they are the same (or at least after many checks appear to be, i could be missing something stupid). I know my data is at least getting in because the recommitted image is there, just mangled and rearranged in chunks.   Are there any things i need to do when recommitting a sparse textures memory? I know i need to reupload my pixels, and i know the memory needs to be commited before doing so, but I use the same code path when creating it the first time, and it renders and looks fine. the ONLY difference is i call uncommit before that same code path gets executed.   Any ideas?    -Joe   PS: First time image is created and committed (and bits uploaded) and rendered : [attachment=27579:firstTime.png]   Second Time the image has been uncommitted, then recommitted (and bits uploaded) and rendered: [attachment=27580:recommit.png]     
  5. Sparse Textures broken on Nvidia Linux drivers.

    Needed to commit the storage before calling texSubImage to upload the data. Simple but elusive issue.
  6. Anyone else experiencing completely broken sparse texture support on Nvidia Linux?   I tested my program on a GT 750m and k5000 with 331 drivers and 346 drivers and got the exact same behavior. basically when you do a glTexSubImage the driver loads the texture data incorrectly into the tiles of the sparse texture. If the image is the size of one tile, then it is uploaded fine, but if it exceeds 1 tile, the same (some arbitrary subset of) texture data is seemingly copied to each tile, rather than the driver correctly offsetting and mapping the correct texture data to the correct tile.   Super annoying since for a while i thought it was my code, but my tests and reading suggest otherwise (there is no mention anywhere of an application having to manage tiles).
  7. Sparse texture requires that Texture storage be a multiple of Virtual Page Size.   Any ideas at what the best approach is for handling any width and height of image? Does Texture data HAVE to fill exactly the dimensions of a TexStorage?   If a texture is added at 0,0 and just doesnt fill the entire texture storage, you would need to know the texture width and physical width and then divide to figure out where the sample should be. Is there any way to avoid this?
  8. Little late to this topic but....   First off since you mention you are learning, do yourself a favor and if you really want to learn opengl, get yourself in a situation where you can limit the frustration of having to do setup code, and provide yourself with an environment that can help you debug. THIS IS NOT MAC OSX. Ubuntu or Windows  + Clion or VS + GDEbugger + common support libraries like Glew, GLFW and SOIL help you get a window and load textures quickly (just a hypothetical example)   Also, as has been suggested before, there is very much an old way and a new way of doing things in OpenGL, and they have big implications on performance.   Luckily, An Nvidia guy has a github page that has sample code for the new way of doing things. I highly suggest you clone that repo and study it religiously.   That github page, paired with study of the opengl spec that describes the features in that code, will IMO be your best bet at learning opengl.   In a nutshell... the movement in the OpenGL API has been that of 0 driver overhead. That is, the application does some of what the driver usually does and thus the driver does less work, so you can really slim down the runtime graphics stuff.   Lastly, in the repo is a solution to packing multiple textured quads using (might not have the right names) ARB_BUFFER_STORAGE, SHADER_DRAW_PARAMETERS,  BINDLESS_TEXTURE_ARB, SPARSE_TEXTURE_ARB, and MULTI_DRAW_INDIRECT. Again, the application is doing what the driver might do, thus reducing overhead. If you think of a draw call as packing data of similar objects as opposed to actually drawing a single object, you begin to see how the transition of old opengl to modern opengl is themed.
  9. My attempt at bindless textures not working....

    Phew, I grossly misunderstood bindless texturing. Residency is only for the texture handles. Sparse Texture support is for residency of texture memory. Luckily the two work together quite well, so if I add sparse texture immutable storage I can leverage the same querys of determining bindless residency to deal with sparse residency.
  10. My attempt at bindless textures not working....

    So I think it actually is working.... what throws me off is that vram seems to stabilize... so the driver must keep residency memory reserved using a data structure of some sort (makes sense).   i can handle 80 high rez images w/ mipmaps (basically camera animates over them (by 2s).
  11. My attempt at bindless textures not working....

    I wanted to keep my issues with bindless in the same thread, as to keep things somewhat tied together. See latest edit at the top for details.   I could post more detailed code if needed, But it seems like a simple thing.   What are the requirements for making a resident texture non resident? By definition, what does making a texture non resident actually do?   A comment in the spec says that if the texture isnt going to be used "for a while" it can be made non resident, maybe the GPU won't specifically release the memory if it has plenty? Perhaps the crashing i am seeing is when it actually starts releasing and adding textures from VRAM.
  12. My attempt at bindless textures not working....

    I actually tried just doing regular binding and i get the same result.   Do i NEED to bind a "sampler"?   maybe its my VAO... it's pretty straightforward vertexBufferSize = desc.vertexBufferSize; indexBufferSize = desc.indexBufferSize; glGenVertexArrays(1, &vaoID); glBindVertexArray(vaoID); glGenBuffers(1, &vboID); glBindBuffer(GL_ARRAY_BUFFER, vboID); glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex)*vertexBufferSize, &desc.meshData[0].x, GL_STATIC_DRAW); glGenBuffers(1, &indexID); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, indexID); glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(unsigned short)*indexBufferSize, desc.indexData, GL_STATIC_DRAW); glEnableVertexAttribArray(0); glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), 0); glEnableVertexAttribArray(1); glVertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)(12)); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, indexID); fprintf(stdout, "vbo: %d\n", vboID); fprintf(stdout, "index buffer: %d\n", indexID); fflush(stdout); glBindVertexArray(0); // Disable our Vertex Array Object }
  13. My attempt at bindless textures not working....

    Okay...   Texture Creation Texture &tex = (*textures)[desc.filename]; if (tex.name.compare(desc.filename) == 0) { return tex; } if (desc.width < 1 && desc.height < 1) { //bad input } int width, height, channels; unsigned char *textureData = SOIL_load_image ( std::string(TEXTURE_DIRECTORY).append(desc.filename).c_str(), &width, &height, &channels, SOIL_LOAD_AUTO ); fprintf(stdout, "width: %d, height %d: \n" , width, height); fprintf(stdout, "Done Loading Texture... \n"); printf( "SOIL loading error: '%s'\n", SOIL_last_result() ); fflush(stdout); GLuint textureHandle; glGenTextures(1, &textureHandle); glBindTexture(GL_TEXTURE_2D, textureHandle); glTexImage2D(GL_TEXTURE_2D, 0,GL_RGB, width, height, 0, GL_BGR, GL_UNSIGNED_BYTE, textureData); //set texture parameters glTexParameteri(textureHandle, GL_TEXTURE_WRAP_S, GL_CLAMP); glTexParameteri(textureHandle, GL_TEXTURE_WRAP_T, GL_CLAMP); glTexParameteri(textureHandle, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(textureHandle, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glGenerateMipmap(GL_TEXTURE_2D); //get GPU PTR GLuint64 textureGPU_ptr = glGetTextureHandleARB(textureHandle); fprintf(stdout, "texture pointer: %lu \n", textureGPU_ptr); fflush(stdout); //Make the handle resident on the GPU before using it. //Here we assume that we are creating a texture because we want to display it. //If we didnt want to display it right away, we wouldnt make it resident. //We can also move textures off the GPU by calling glMakeTextureHandleNonResidentARB glMakeTextureHandleResidentARB(textureGPU_ptr); tex.TextureID = textureGPU_ptr; tex.width = desc.width; tex.height = desc.height; //if everything checks out, assign the name so it becomes valid in the hashmap. tex.name = desc.filename; glBindTexture(GL_TEXTURE_2D, 0); return tex; Square mesh data... struct Vertex { float x, y, z; float u0, v0; }; name = "square"; vertexBufferSize = 4; indexBufferSize = 6; meshData = new Vertex[vertexBufferSize]; for(int i = 0; i < vertexBufferSize; i++) meshData[0].x = -0.5f; meshData[0].y = -0.5f; meshData[0].z = 0.0f; meshData[0].u0 = 0.0f; meshData[0].v0 = 0.0f; meshData[1].x = -0.5f; meshData[1].y = 0.5f; meshData[1].z = 0.0f; meshData[1].u0 = 0.0f; meshData[1].v0 = 1.0f; meshData[2].x = 0.5f; meshData[2].y = 0.5f; meshData[2].z = 0.0f; meshData[2].u0 = 0.0f; meshData[2].v0 = 1.0f; meshData[3].x = 0.5; meshData[3].y = -0.5; meshData[3].z = 0.0; meshData[3].u0 = 1.0; meshData[3].v0 = 0.0; indexData = new unsigned short[indexBufferSize]; indexData[0] = 0; indexData[1] = 1; indexData[2] = 2; indexData[3] = 0; indexData[4] = 2; indexData[5] = 3; } the setUniformTextureHandle64NV call above actually calls glUniformHandle64ARB void Shader::setUniformTextureHandle64NV(GLuint location, GLuint64 value) { //Runtime function glProgramUniformHandleui64ARB(this->ShaderProgram, location, value); } and the shaders again: #version 440 layout (location = 0) in vec3 VertexPosition; layout (location = 1) in vec2 TexCoords; uniform mat4 worldMatrix; uniform mat4 projectionMatrix; uniform mat4 viewMatrix; out block { vec2 Texcoord; } Out; void main() { mat4 mvp = projectionMatrix * viewMatrix * worldMatrix; Out.Texcoord = vec2(TexCoords.x, 1.0-TexCoords.y); gl_Position = mvp * vec4(VertexPosition, 1.0); } #version 440 //#extension GL_NV_gpu_shader5 : require // for 64-bit integer types #extension GL_ARB_bindless_texture : require in block { vec2 texCoords; } In; layout (bindless_sampler) uniform sampler2D textureID; layout (location = 0) out vec4 FragColor; void main() { FragColor = texture(textureID, In.texCoords); } Here are images:   [attachment=25574:bindlessNotWorking.png]   [attachment=25575:textureAndStack.png]
  14. Double EDIT: I have updated my renderer with a prototype to test this feature. and glMakeTextureHandleNonResident seems to not do anything.   I used the following code as a test to see how much memory i have (at the end of my Renderer::Draw() before unbinding the GLContext): GLint currentAvailableVideoMemory = -1; glGetIntegerv(GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, &currentAvailableVideoMemory); GLint totalAvailableVideoMemory = -1; glGetIntegerv(GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX, &totalAvailableVideoMemory); float percent = (float)currentAvailableVideoMemory/(float)totalAvailableVideoMemory * 100.0f; fprintf(stdout, "VRAM (%d MB) Usage: %f%% \n", totalAvailableVideoMemory/1024, 100.0f - percent); fflush(stdout); which reports 95.xxx% always...   And in gDebugger i always have the same number of texture objects.   when i add 100 images. i get a couple of frames and then the renderer dies, asummingly because the textures are not actually made NonResident.   Is there something i need to be doing to ensure that non resident calls are executed? Could this be a bug in the nvidia linux driver?       EDIT: stupid shader in/out blocks didnt match... thanks compiler!   Here is the output for my program, i also checked in gDebugger and the texture loads just fine.   Vendor: 4.4.0 NVIDIA 343.36 Supported GLSL version is 4.40 NVIDIA via Cg compiler. Aspect Ratio: 2.400000  vbo: 1 index buffer: 2 Shader Source: #version 440   layout (location = 0) in vec3 VertexPosition; layout (location = 1) in vec2 TexCoords;   uniform mat4 worldMatrix; uniform mat4 projectionMatrix; uniform mat4 viewMatrix;   out block {     vec2 Texcoord; } Out;   void main() {     mat4 mvp = projectionMatrix * viewMatrix * worldMatrix;     Out.Texcoord = vec2(TexCoords.x, 1.0-TexCoords.y);     gl_Position = mvp * vec4(VertexPosition, 1.0); }   ../shaders/simpleTexture.vert Compilation Successful  Shader Source: #version 440 //#extension GL_NV_gpu_shader5 : require    // for 64-bit integer types #extension GL_ARB_bindless_texture : require   in block {     vec2 texCoords; } In;   layout (bindless_sampler) uniform sampler2D textureID;   layout (location = 0) out vec4 FragColor;   void main() {     FragColor = texture(textureID, In.texCoords); }   ../shaders/simpleTexture.frag Compilation Successful  Linking Shader Program: simpleTexture.vert Shader Link Successful GL_ACTIVE_UNIFORMS = 4   0) type:mat4 name:projectionMatrix location:0   1) type:sampler2D name:textureID location:1   2) type:mat4 name:viewMatrix location:2   3) type:mat4 name:worldMatrix location:3 width: 500, height 331:  Done Loading Texture...  SOIL loading error: 'Image loaded' texture handle pointer: 4294969856     My question is, given those shaders and the fact that glGetTextureHandleARB returns non 0, should it work? (of course given the correct geometry and uvs)  
  15. Thanks for the review!   High resolution clock is the "fastest", but it is not reported as steady. I think this means that if the CPU is throttled and the system clock is changed because of battery or whatever, then the clock will change, thus becoming inconsistent? I am not sure if this is important or not, since it doesnt need to be 100% consistent forever (perhaps this is what i am seeing in the blips?)   The autos might seem a bit tough to decipher if you are not familiar with chrono. accumulator is a duration<int64_t, std::micro> which should be as good as i can get?   your snippet of code looks good, i'll plug it in and see if that improves the results!
  • Advertisement