Hot answers tagged

11

In a real GPU, instead of having multiple cores trying to read/write the same region of the depth buffer and attempting to synchronize between them, the depth buffer is divided into tiles (such as 16×16 or 32×32), and each tile is assigned to a single core. That core is then responsible for all rasterization in that tile: any triangles that touch that tile ...


10

Highly specialized hardware handles it. A typical strategy is for a GPU to tile rasterization and store depth information in compressed formats (e.g. the z-equation when a polygon completely covers a tile). This allows testing across an entire tile at once; other cool HW tricks include depth testing before the pixel shader is run (assuming conditions permit -...


6

While creating a set of glTF models for a tutorial, I also intended to create THE minimal glTF file. Update: The following referred to glTF 1.0/1.1. See below for an update of this example to glTF 2.0. As already mentioned in the answer by 5chdn, one issue may be the material. According to the Appendix A: Default Material of the specification, an asset ...


5

When a shader accesses a resource (buffer or texture), it needs some information about that resource to be able to do so correctly. On a modern GPU, that information will generally just be some kind of number. It could be something as simple as a GPU virtual memory address (with the particular details of what kind of resource is being used defined by the ...


5

Short answer: Move your near clip plane further away. Depth buffer precision is very sensitive to the near clip plane distance. Complicated answer: Use different math in your view projection. There are a few techniques that can help, some of them are outlined here: https://developer.nvidia.com/content/depth-precision-visualized


5

Yes, the back buffer is for the GPU to write the frame that's in-progress, while the display controller sends the front buffer to the attached display. Swapping buffers doesn't really copy anything these days. The display controller has a register which tells it the address of the frame buffer to display. Swapping buffers simply puts the address of the old ...


5

Yes, it's totally possible, and in fact it's preferable to keep buffers in memory if you will be accessing them over the life of your program, rather than deallocating and reallocating them again. I can't speak for Unity's way of allocating persistent buffers - I work with Unity and do a lot of shader writing in Cg, but most of our stuff is on mobile so ...


4

You can put the data into a data uri to store the data inline in base64 format. "buffers": { "a-buffer-id": { "byteLength": 1024, "type": "arraybuffer", "uri"="data:application/octet-stream;base64,..." } }, It's still a bit bloated compared to storing the data in a binary file though.


4

When depth testing is enabled, the testing occurs after the fragment shader executes. The procedure is relatively simple (and spelled out pretty well here): Get depth of fragment Test against depth buffer Discard if it fails Early-z discard is when a rasterizer discards a fragment before a fragment shader runs because it's clear early on that it won't pass ...


3

It depends. There are a few competing factors at work here. First, consolidating terrain data into fewer buffers (or one) may allow you to combine multiple terrain patches together in a single draw call—assuming there aren't other state changes between patches that would prevent this. So, you may be able to reduce draw-call overhead this way, or at least ...


3

well, if anyone is stumbling across this and needs to know what solved it for me: We can bind a compute buffer to global shader memory if we just know what exactly we need to do within the Compute shader the RWstructuredBuffer is declared as (without the "\" infront of float): uniform RWStructuredBuffer<\float3> buffer : register(u1); (not certain ...


3

The marquee feature of buffer storage is not immutability of the allocation itself, but instead is a feature you couldn't have without immutable allocation: persistently mapped buffers. Pre-buffer_storage, you could not use a buffer while it was mapped. This is done to allow implementations the freedom to play games with mapping behind your back. For ...


3

After spending a hard time to understand the way how the binary buffers work in the gltf files I finally managed to generate a truely minimal gltf file. It's a single yellow triangle (demo). I tried to remove everything which is not needed from the gltf. This is what is required it seems (github): { "accessors": { "accessor0": { "...


3

Also check out the glTF models used in Cesium: https://github.com/AnalyticalGraphicsInc/cesium/tree/master/Apps/SampleData/models https://github.com/AnalyticalGraphicsInc/cesium/tree/master/Specs/Data/Models Patrick


3

As stated, the question is a bit generic. It all depends on what part you want to display in the 512x512 display. If you have a 1024x1024 frame buffer from some source and only want to display 1/4 of the information, by all means copy the first 512 elements from the first 512 lines. If you want to support panning, you'll start at a different index in a ...


2

There is a difference between "can" and "should". You "should" not use glBufferData to change the size of an existing non-immutable buffer. You can still do so, but don't expect this to be advantageous. You "can" not change the size of an immutable buffer with any function. How do I replace the whole VBO with my new data, but if my new data is smaller ...


2

tl;dr The vao caches the calls to glVertexAttribPointer et. al. Every call to glVertexAttribPointer, glEnableVertexAttribArray and the binding of gl_Element_Array will store the parameters into the currently bound vao. In the case of glVertexAttribPointer it will also store the current binding to GL_VERTEX_ARRAY in the vao. This is a major help when ...


2

VAOs are essentially 'plumbing' objects that help get data from your buffers into your vertex shader ready for drawing. On the GPU this is handled by the vertex fetch stage, so a VAO is basically just a bundle of vertex fetch state corresponding to a particular model. You can think of it as a bundle of pointers, but with somewhat more complexity than CPU-...


2

According to the OpenGL spec, any integer other than zero can be a potential name. Zero is the only value that's guaranteed not to be an object name. Relevant quote from the spec: 2.6.1.1 Name Spaces, Name Generation, and Object Creation Each object type has a corresponding name space. Names of objects are represented by unsigned integers of type uint. ...


2

I have tried doing glCear(GL_BACK_LEFT) between each iteration but it is not clearing, I'm wondering if I'm missing a line of code before the glClear, or if I'm calling it right. I think the problem is that the back buffer isn't clearing This comment of yours sheds some light on the matter. This function call doesn't do what you think it does and is ...


2

In addition to @russ' answer, I was able to decode the buffer with the gltf Utilities. let uri = "data:application/octet-stream;base64,AAABAAIAAwACAAEABAAFAAYABwAGAAUACAAJAAoACwAKAAkADAANAA4ADwAOAA0AEAARABIAEwASABEAFAAVABYAFwAWABUAAAAAvwAAAL8AAAA/AAAAPwAAAL8AAAA/AAAAvwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAL8AAAA/AAAAvwAAAL8AAAA/AAAAPwAAAL8AAAC/AAAAvwAAAL8AAAC/...


2

The information you're looking for is defined in the 'accessors' and 'bufferViews' near the top of the source file you linked. Bufferviews simply divide the buffer up into sub ranges and define broadly what kind of data lives there using some obscure shortcodes. In this case, target 34963 means index data and 34962 means vertex data. So from the other ...


2

Ok sometimes you have to ask a question to figure out the answer already. Example datasets are available in the same repository as linked in the question already. Here are some: supermurdoc.gltf duck.gltf etc. pp.


2

There are a couple of issues. First you need to make sure that veBuffer has the correct type, so that probably means you need to cast it to pointer to vertex: const auto vertices = reinterpret_cast<const Vertex*>(reBuffer); Second a range-based for-loop needs to know where the range ends and giving it a raw pointer does not provide that information, ...


2

Technically any file format where you can dump the entire file into a VBO and then render from that will work for the .bin files. Unfortunately those formats are less well known than they should be. Then you only need to adjust the bufferview elements to reference the proper subset of the file


2

I think you may be focusing on the wrong thing here. Moving the data from an SSBO to a uniform buffer might give some speedup, sure, but that is a micro-optimization. I would search for algorithmic optimizations first. As noted in the comments, processing all 200 records for every vertex is both a lot of data to read, and a lot of computation to do if there'...


1

The Z buffer used to be specialized memory set aside for a single purpose, some web sites still explain it like that, but no longer. Now the Z buffer is just a chunk of memory you allocate, or an API like OpenGL allocates on your behalf. The size of that chunk of memory will depend on the type of the Z buffer values, in the example you gave it is a 32bit [...


1

Do I could get event better perf by making it a compile-time constant ? You'll have to profile it. That being said, "a few hundreds mat4" is not "small". I have trouble understanding what could be the best value for the 'usage' parameters of the buffer. All buffers being written to and read several time, I'm not sure what to put here. ...


1

Can it be (eg. if I run a video game full-screen) that the compositor could simply declare the application's off-screen buffer the same as its 'screen buffer' Yes. This is one of the things that "fullscreen exclusive" mode would do for you: it enables the application's swap buffers (front/back default framebuffers) to be directly scanned out by ...


1

Your code is non-functional, but only because (in the core profile) you cannot bind a buffer to GL_ELEMENT_ARRAY_BUFFER unless a VAO is also bound. So the part that creates the buffer would need to use a different binding point, which is totally fine: const GLuint indices[6] = { 0, 1, 2, 0, 3, 2 }; glGenBuffers (1, &EBO); glBindBuffer (...


Only top voted, non community-wiki answers of a minimum length are eligible