25

The most data I've seen is on the relative expense of various state changes is from Cass Everitt and John McDonald's talk on reducing OpenGL API overhead from January 2014. Their talk included this slide (at 31:55): The talk doesn't give any more info on how they measured this (or even whether they're measuring CPU or GPU cost, or both!). But at least it ...


25

The actual cost of any particular state change varies with so many factors that a general answer is nigh impossible. First, every state change can potentially have both a CPU-side cost and a GPU-side cost. The CPU cost may, depending on your driver and graphics API, be paid entirely on the main thread or partially on a background thread. Second, the GPU ...


22

An architectural advantage of compute shaders for image processing is that they skip the ROP step. It's very likely that writes from pixel shaders go through all the regular blending hardware even if you don't use it. Generally speaking compute shaders go through a different (and often more direct) path to memory, so you may avoid a bottleneck that you would ...


22

Pixels get grouped into little squares (how big depends on the hardware) and computed together in a single SIMD pipeline. (struct of arrays type of SIMD) This pipeline (which has several different names depending on the vendor: warps, wavefronts) will execute operations for each pixel/fragment in lockstep. This means that if 1 pixel needs a computation done ...


21

Speed is the most common reason why this is not done. In fact you can do what you propose, if you make your own operating system, its just going to be very slow for architectural reasons. So the assumption that its faster is a bit flawed. Even if it would be faster, it would be less efficient in terms of development (like 1% speed increase for 10 times the ...


15

As TheBuzzSaw said, it does depend on lots of things, including implementations of the rasterized graphics vs the vector graphics. Here are some high performance vector graphics methods that are rendered using traditionally rasterization methods. Loop and Blinn show how to render a vector graphics quadratic bezier curve by rendering a single triangle, and ...


15

work on any 32-bit color GPU (even old ones)? Bit of history here: this is how games were done on PC up until graphical accelerators started to become available in the mid-90s. It did indeed work on all hardware, because the hardware wasn't doing much. A graphical accelerator allows the drawing of pixels considerably faster than a CPU can, by using ...


14

Just to add to joojaa's answer, things are still being drawn pixel by pixel. You're just generating the pixels using a vertex shader/assembler/rasterizer, then texturing and lighting them using a fragment shader. This was all done in software in the 90's when your video card wasn't much more than a blitter and a frame buffer, but it was slow as hell. Hence ...


13

Use cases are only limited by your imagination! noperspective means that the attribute is interpolated across the triangle as though the triangle was completely flat on the surface of the screen. You can do antialiased wireframe rendering with this: output a screen-space distance to the nearest edge as a noperspective varying and use that as coverage in the ...


13

On modern hardware if all invocations in a group follow the same path then the unused path doesn't get evaluated. in pseudo code: if(cond){ res = ... }else{ res = ... } becomes if(anyInvocationARB(cond)){ res1 = ... } if(anyInvocationARB(!cond)){ res2 = ... } res = cond?res1:res2; Where anyInvocationARB will be true if any invocation of ...


11

What you're talking about is commonly called "dependent texture reads" in the mobile development community. It's an implementation detail of certain hardware, and therefore it really depends on the GPU as to whether or not it has any performance implications. Typically it's something you see brought up for PowerVR GPU's in Apple hardware, since it was ...


11

It is possible to avoid overdraw from opaque objects even with forward rendering by doing a depth pre-pass and using that information to reject any pixel that is not actually visible. However, depending on the vertex cost of your scene, a depth pre-pass may add an unacceptable amount of performance overhead. Additionally, rendering using the pixel shading ...


11

In general, when you render an object in an immediate mode—issuing line drawing commands for instance—you build up a series of commands that you submit to the graphics card to draw. If you're drawing a lot of data, or drawing very frequently, you can waste a lot of time sending this data over and over again. A vertex buffer allows you to produce a single ...


10

There are two steps that make the VBO more efficient than immediate mode. Immediate mode (glBegin/glEnd, glVertex*, etc.) means that at each frame, you spoon feed the vertices, attribute per attribute (position, normal, color, etc.), to the driver, which then reformats them and finally sends the whole package as a command to the GPU. That a lot of function ...


9

Doing math with uniforms is a shader won't usually get you any performance over doing it on the CPU. A CPU isn't slower than a GPU at doing matrix math, it just isn't structured so as to do large amounts of math in parallel. But you have to actually do that large amount of math to get a win. Sending extra data to the GPU just to have the GPU multiply two ...


9

The main difference would be that with OpenGL in let's say a video game you will have a process called rasterization which basically takes care of determining what part of the scene you see. It needs to be fast so we can experience it as realtime. Therefore the algorithm does a few simple steps. check if a certain part of the scene is in my view frustum ...


9

Yes, occlusion culling is still worth it. At minimum, a draw call that you skipped due to culling is a draw call that doesn't have to run the vertex shader. Triangle count goes up as quickly as GPUs start supporting more triangles, because why not? With unified architectures, vertex shaders use the exact same hardware that pixel shaders do, so every vertex ...


9

John has already written a great answer so consider this answer an extension of his. I'm currently working a lot with compute shaders for different algorithms. In general, I've found that compute shaders can be much faster than their equivalent pixel shader or transform feedback based alternatives. Once you wrap your head around how compute shaders work, ...


9

Avoid stereo when possible There was some research published recently measuring when users can or cannot tell whether the specular contribution, which is view point dependent, is different between eyes. Perception of Highlight Disparity at a Distance in Consumer Head-Mounted Displays In the future, this could be use to share some computation between the ...


8

There are many, many ways to draw things in OpenGL, so this is naturally confusing sometimes. The first method you describe, setting the shader parameters and issuing one draw call per object is usually the most inefficient, due to the high API overhead. The second one, using instanced drawing is a much smarter approach for objects with the same parameters. ...


8

There might be. Less technical answer: If you're building a website or another application where you have nothing to do with the graphics programming then the answer is probably yes. The underlying APIs will try to guess how to render them and cache them efficiently. However, as your application runs and the API sometimes guesses incorrectly it may have to ...


7

You're comparing apples to oranges The game is like the view port in your modelling app. You can use the viewport for render and you will get same 60fps speeds. There is no reason why you can not get realtime graphics that are very good out of modelling software like Maya or 3DS Max. Results that are par with many games. They have viewport shaders just ...


7

Alex Vlachos from Valve has had two great GDC talks about this: the one from 2015 the one from 2016 Other than that (and what you have linked yourself), there isn't much left to do than to simply optimize your app until you spend at most 10 ms per frame (100 Hz, targeting a 90 Hz display + margin). Standard rendering optimizations apply. Apply a technique, ...


6

By using an immediate mode interface (e.g. old style OpenGL glBegin()/glEnd()/glVertex()) you're effectively drip feeding data to the driver one piece at a time. It then has to take that single piece of data, reformat it and pass it on to the hardware (which these days means putting it into a command buffer). By using a vertex buffer object, you're ...


6

There are a few ways of rendering vector graphics. As TheBuzzSaw mentions, NVIDIA has an extension that can render general paths quite quickly (but of course it only works on NVIDIA GPUs). And Alan Wolfe mentions the implicit surface methods (Loop-Blinn/distance fields), which define a function which says whether you're inside or outside a shape, and color ...


6

Shader compilers are extremely aggressive about unrolling since early HW often didn't have flow control and the cost on more recent HW can vary. If you have a benchmark you are actively testing against and a range of relevant hardware, then try things to see what happens. Your dynamic loop is more amenable to developer intervention than a static loop - but ...


6

Yes ( with 50% of the FMA 32b throughput on nVIDIA Maxwell). See https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#arithmetic-instructions


6

That diagram includes a CPU block titled "wait for GPU". I do not see the part of your code that includes an equivalent command. Furthermore, even if it did include glFinish/glClientWaitSync/etc, there is no guarantee that the CPU time in any way relates to how much time the GPU spent processing it. glFinish might block on a mutex, thus ending the thread's ...


6

I don't know if this is exactly what you're looking for. I work tangentially in the film and TV industry. I don't work for a studio, but I work on the software that studios use for their productions. It's software that any user could buy if they wanted to, but it has been used in feature films, television shows, commercials, music videos, and more. About ...


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, ...


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