Hot answers tagged

16

Smooth in this case just makes the surface normals at vertices point the same way, when interpolated it looks smooth. Meshsmooth would add vertices. 1) how is the smoothing possible without increasing the detailing of the mesh geometry? Human eyes cant actually see curvature except on the edges of objects. All they can do is approximate the smoothness and ...


12

If the scene does not entirely fit into memory, you are entering the field of out-of-core rendering. There are essentially two approaches here: a) Generate your scene on-demand b) Load your scene on-demand The former approach aligns well with most animation workflows, where models are heavily subdivided using e.g. Catmull-Clark and can become very memory-...


8

Here's my take on it. A pixel is not a square, and it isn't even a rectangle. A pixel is a point (infinitely small) that has a color associated with it. The only way I personally have ever seen pixels viewed (interpreted) by a display is to use "nearest neighbor" sampling where the pixels were on a rectangular grid, which means that the color of any given ...


7

If you organize your scene in a spatial structure (the usual way being a Bounding Volume Hierarchy), you can use a sort of virtual scene (I am making up this term, in reference to virtual textures). A memory manager would keep only a limited number of bounding boxes loaded at a time, and abstract the operation consisting in retrieving one. This way, a box ...


6

There's a third option you've neglected. Because of how graphics APIs work, typically you have to copy the data between the CPU and GPU anyway - even if you're on a mobile SoC where they share the same physical memory. This copy is the ideal time to take the hit of changing format, since you have to touch all of the memory anyway. So the copy in user memory, ...


5

Opengl doesn't care how long it has been running. However there are a few other challenges with long running applications in general: memory leaks, both normal ones and opengl resources. lack of precision after incrementing a float to a big number. After 4 weeks your millisecond counter will be at 2.4 billion which is well beyond the point where integers ...


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

Lowering register pressure doesn't necessarily give you any performance boost though. I recently went through this exercise myself on GCN architectures (for a simple ray tracer) and reduced register pressure so that it increased occupancy from 2 to 4, which had no impact on performance. It's generally a good idea to reduce the pressure if you need to hide ...


4

True color is 8 bits per color channel, so 3 bytes per pixel. 1024x768 is 785,408 pixels. At 3 bytes per pixel that is 2,356,224 bytes. Since it's double buffered we double that number to 4,712,448 bytes which is about 4.5MB.


4

The post October 22, 2019 version of the OpenGL 4.6 standard gives atomic counters the same incoherency restrictions as image load/store and SSBO operations. You have to use explicit barriers to synchronize access to them and so forth. This is a textual change from older versions of the standard, but it isn't a behavioral change from implementations. The ...


4

glMemoryBarrier is for when you want to make writes from one rendering command visible to reads from a subsequent rendering command. That is, you can do all the atomics you like during a rendering command. But without the barrier, there's no guarantee that any of those atomic actions will be visible to later commands. Yes, they will still be atomic, but ...


4

If one examines old CRT television displays, one will observe red, green, and blue phosphor dots in a triangular lattice. Some LCD television sets had a somewhat similar arrangement; pixels were rectangular rather than square, but successive rows of pixels were staggered so that the horizontal position of a red pixel on one row would be halfway between the ...


4

For modern GPUs it's commonly stored in VRAM which for discrete GPUs are separate from the CPU memory. This usually means there is a penalty associated with letting the CPU access this as the data typically has to be copied across some bus. Mobile devices tend to use shared RAM for both GPU and CPU.


4

Since you're talking about "vertex shaders" and "fragments", I assume that your question is to be interpreted in the context of real-time rendering using the graphics pipeline on a modern GPU through some modern graphics API. Even if we narrow down the question like that, I don't think a general answer can be given to what you're asking. It depends a lot on ...


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

Vertex count may be more accurate of a measurement of "mesh memory usage and mesh rendering time", but vertex count is not nearly as easily measured. Yes, given a specific mesh with all of its attributes, it's easy to tell how many vertices are in it. But how many modelling tools can tell an artist how many vertices a given mesh will produce? After all, ...


3

While the existing answer adress your question quite well, I'd like to add some general advice, even if you might already be aware of that. Rather than just wasting that fourth component on the GPU, you might as well use it for additional data. It might be an obvious suggestion, but a 4th unused 32-bit word can store a variety of useful data: 8-bit RGBA ...


3

Whenever there's too much churn of things being created and destroyed, regardless of the specifics of the situation, a common way to dealing with this is to make free object pools. How these work is when you are done using something, instead of actually freeing or destroying it, you put it back into a list or array of "free objects". When you need a new ...


3

Yes, of course. The duration it has to run for doesn't make much difference. Your Android smartphone's main GUI is OpenGL, and phones typically have an uptime longer than four weeks. Air Traffic Control centres might use OpenGL SC (the subset of GL for safety-critical applications) continuously for months or years. If you do have free choice of software, ...


3

If your goal is to learn GPU programming, it doesn't matter at all whether you have DDR3 or GDDR5 memory. The way you program it isn't going to change based on how fast the memory is. It will affect performance, but if that's not a primary consideration for you, then you don't need to worry about it. Do make sure that you get a GPU that supports the latest ...


3

Assuming your code has several locations that can allocate/release GPU memory, but you don't know which one leaks. Maybe you can try to add a GPU memory monitor to that code. When GPU memory is allocated in code, insert the buffer handle that was returned, the buffer size, the function/file name (or even better, stack trace) in a globally defined array. ...


3

Probably not. Most OpenGL resources (framebuffers, vertex buffer objects, textures &c.) are controlled by host code (i.e. your C++ code), but take up GPU memory. OpenGL doesn't make it very easy to manage these resources, so it's most likely that they're being created but not deleted from your C++ code. For example, it might create a new VBO per frame ...


3

Is such a method of zero-copy texture loading possible/optimal on modern discrete graphics hardware? You say that as though it were optimal back then. The Intel 740 was not exactly warmly embraced by the market, as noted by the Wikipedia article in question: The AGP Texture concept soon proved to be a tremendous error in design, because the card had to ...


2

In your 31 bit solution, the thing most likely to happen there is that you'd give an extra bit to green and make a 32 bit solution. In 16 bit color for instance, r and b get 5 bits while g gets 6 bits, because your eye can distinguish more greens. Or maybe you'd use that extra bit to have 1 bit alpha? Not sure if that'd be very useful though... As far as ...


2

To make an application, OpenGL or not, run for extended time safety-critical applications are mostly built to restart on error, be it a driver bug, your application is broken, or hardware failure. If function during the downtime is required you need redundnacy. In your case maybe start multiple sessions of the same program, or even having dual computers ...


2

You don't. These objects typically work with CPU memory, not device memory. And to the extent that they involve device memory, such allocations tend to be rare and/or fixed in size (a queue may have a small spot of device memory that the hardware queue reads commands from or something, but even that is implementation-dependent). Vulkan allows you to give ...


2

I've used imageStore as part of compute shaders doing surface extraction. I've only ever used it in compute shaders, to store the calculated data in a texture to be consumed by another shader - I know it's possible to do imageStore in a fragment shader as well but I haven't come across a use case for it yet. I also haven't used imageLoad at all, since ...


1

Yes it is possible by putting Samplers in descriptor tables to dynamically assign and index into them. Source: https://youtu.be/Wbnw87tYqVg?t=754 Here's an example that uses the HLSL root signature syntax to do this here: https://youtu.be/Wbnw87tYqVg?t=5277


1

Typically you will need VRAM to store your frame buffer (memory used to store pixels for use with the display and for rendering). This would usually be 4 bytes per pixel so a 1080p frame buffer is 1920x1080x4 bytes (1 byte each for R,G,B components + 1 padding byte). Your card is going to use 2 of these for double buffering so it can use one for display ...


1

The conversion from option A is likely faster than you think. See, for example, Intel's version which claims to do the round trip at 1.5 cycles per vector with AVX. There are also some operations which don't require the conversion at all. For example, if you want to compute a bounding box, you can do it directly with the packed data in chunks of 4 vectors ...


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