[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][quote name='Eric Lengyel' timestamp='1309832790' post='4831213']What mainstream GPU, specifically, do you believe doesn't have alpha test capabilities outside the pixel shader?

[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][quote name='Eric Lengyel' timestamp='1309915357' post='4831584']I agree that having the kill instruction early in a shader can provide a performance increase for complex shaders

Would you just have the renderer which receives the commands switch on type and reinterp cast the memory?

Having a system like the one you propose would kill performance having each render command require a virtual call plus a lot of vector iterations.[/quote]It's important to note why it would be slow in a naive implementation. The main bottleneck here is not the clock-cycles required to perform arithmetic, but the time spent waiting for data to be moved from RAM to the CPU.

Iterating through a vector is actually the best kind of iteration -- you're accessing memory in a completely linear fashion, allowing great cache utilization. Iterating through a blob is the same (except that each item is of variable size) -- you start reading at the beginning of a contiguous blob, consuming items in a linear fashion until you reach the end.

Virtual functions on the other hand, are not cache friendly. To call a virtual, you read the vtable pointer (often the first 4 bytes of the object), add an offset to that pointer, read another pointer located at that address, and then execute the code referenced by the second pointer... a process which is not at all friendly to your cache -- it involves jumping to random memory locations, instead of predictable, linear iteration.

Going back to vectors -- iterating through a single vector is fast. However, each individual vector is going to be in a random memory location, meaning that when you finish with one vector and decide to start iterating another, you'll end up stalling as data is pulled down into the cache... If you could somehow put all of your vectors into the same region, then they could all be pulled into the cache in advance, and the amount of time stalling could be reduced dramatically.

I use a linear allocator to create the state-groups. This is where "blobs" come in -- like in the ascii-diagram, a header is allocated, followed by a sequence of commands, each of which is an ID followed by data. This means the group, although made up of several allocations, is all actually allocated in a single contiguous block. To read the blob, it's a bit like working with a serialized file-format.
This also means that all of the different state-groups are in the same region of memory; each group is allocated just after the end of the last group. The state-group allocations of an entire level fit comfortably into your L1 cache (or a SPU...)

As an aside - because "blobs" are just bits (i.e. POD), another nicety is that you can simply [font="Courier New"]memcpy[/font] them into an array of bytes somewhere, and you've got yourself a "command buffer". This lets you easily multi-thread your draw submission on API's without native multi-threading capabilities.

To iterate through a state-group (or a command buffer), you can [font="Courier New"]switch[/font] on the ID value to figure out how many bytes there are until the next command. Alternatively, you can use fixed-width commands to remove this detail.
When you you want to execute a command, you can again [font="Courier New"]switch[/font] on the ID value to figure out which function to call (and pass the data section to). If you're iterating and executing, you can [font="'Courier New"]switch[/font] once to call the execution function, and have it return the size of the data block that needs to be jumped over to reach the next command.

Unlike virtual functions, you've got a lot more control over how things are laid out in memory when using a simple "[font="Courier New"]switch[/font]" based solution.
Some potential examples (not necessarily good ideas) --
* instead of using a [font="Courier New"]switch[/font], you could manually write a table of function-pointers, and use the ID as an index into that array. This allows you to choose where in memory you allocate the table, and compared to [font="Courier New"]virtual[/font], you've only got a single table instead of one per-class.
* you could write a [font="Courier New"]switch[/font] containing [font="Courier New"]goto[/font]'s, which will automatically be compiled into a jump-table. At the [font="Courier New"]goto[/font] labels, you could force-inline your command-handling functions, in order to ensure that all your instructions are in the same region to get good i-cache performance.

Just a quick mockup of a renderer::render method. Am I completely on the wrong track?

I'm having a hard time figuring out which commands I could define as all I could come up with where the 5 I've shown. I'm also a bit in doubt why you would make a separate Drawcall class instead of having it as a command.[/quote]As above, I've got commands for each different render-state. I've also got commands for each different CBuffer slot and each texture-binding slot (for each type of shader).

I've limited myself to 14 CBuffer slots each for the vertex and pixel shader, so, there's actually 28 different IDs that are associated with the "bind cbuffer" command.

My draw-calls are actually a command, just like state-changes. However, I split commands into 3 different categories -- general state-changes, draw-calls, and per-pass state-changes.
State-groups can only contain general state-changes. Actual render-instances must use a draw-call command (not a state-change command).
The 3rd category are stored in something similar to a state-group, which is used to set up an entire "pass" of the rendering pipeline -- commands such as binding render-targets, depth-buffers, viewports, scissor tests, etc go into this category.

Come command queue execution I have to apply / update these uniforms after having bound the shader program. Would that result in a new command type?[/quote]There's a bunch of different abstractions for how uniforms are set, depending on your API... GL uses this model you're familiar with, you set the uniforms on the currently bound program... DX9 uses a model where there's a set of ~200 global registers, and any changes made to them persist from one shader to the next... DX10/11 are similar to 9, but you've got a set of bound CBuffers instead of individually bound uniforms.

So, I looked at these abstractions, and decided that the cbuffer approach made the most sense to me. No matter what the back-end rendering API actually is, my renderer deals with cbuffers -- and as as above, I've got 14 cbuffer binding slots/commands per shader type.

The way this is used generally, is that a "shader" state-group on the bottom of the stack contains commands to bind cbuffers that contain default values. The "material" and "object/instance" cbuffers then contains commands to bind their own cbuffers (which override the "default" commands).

On APIs that don't actually use the cbuffer abstraction, then yes, there's a step that looks at the currently bound cbuffers and sets all of the individual uniforms. I do this step prior to every draw call (with a whole bunch of optimisations to skip unnecessary work).
Regarding memory layout, I allocate all my cbuffer blocks (which are blobs containing uniforms) from a separate linear allocator.