Firstly, If anyone knows of any decent resources for learning details like I'm asking about, can you tell me plzthx. I'm happy to do a lot of reading.

Here's a handful of GPU questions I'm having trouble finding answers to. I thought it'd be easier to ask these in bulk rather than multiple questions. I hope that's OK.

I asked on Khronos (https://forums.khronos.org/showthread.php/13413-A-pile-of-technical-GPU-questions-sorry-)), but they didn't have a category for it and it didn't get any response.

I'm really asking about standard-practice in immediate-rendering GPUs (Nvidia/ATI/maybe Intel).

1. Terminology
Is there a standard terminology for GPU shading components yet? What’s the best way to refer to:

• The element responsible for a single texel output (eg CUDA core). (= Lane? Unit?)
• The block of elements (above) whose instructions are performed together (SIMD). (= Core?)
• The component responsible for managing tasks and cores. (= Thread dispatcher?)

I will use lane and core for the rest of this uberquestion.


2. Memory addressing
Is GPU access to graphics memory ever virtual (ie, via page tables)?

Can the driver/GPU choose to move resources to different parts of physical memory (eg to avoid contention when running multiple applications)?


3. Per-primitive user data
GPUs don’t support per-primitive(or per tesselation-patch etc) data (eg, per-triangle colors/normals) yet, right? Is there any technical reason why? Implicit per-primitive data is required by cores (interpolation constants and flat values). This seems to be a common request, and data does seem to be being wasted.


4. ROP texel ordering
How is the order preserved when sending finished texels to ROPs (render-output-units)? Where/how do out-of-order texels queue when the previous primitive hasn’t been fully processed by the ROPs.


5. TMUs and cores
Can any lane/core use any TMU (texture-mapping unit) (assuming it has the same texture loaded) or are they grouped somehow? Is there a texture-request queue or is there some other scheduling method?


6. Identical texture metadata
For two textures with identical metadata in the same memory heap, is switching a TMU between textures necessarily any more complex then simply changing the TMU’s texture pointer offset (ignoring resulting cache misses).

7. Data "families"

There seem to be many data “families” available to core lanes:

• Per-lane:
  1. Private lane variables. (Read/Write).
  2. Lane location/index (differentiating lanes within a core). (Read-only).
  3. Derivatives (per pair/quad?). (Read/Write(ish)).
• Per-core (read-only):
  1. Per-primitive(or patch, etc) constant data. Interpolation constants etc.
  2. Draw-call-constant data (uniforms, descriptor set data).
• RAM-based stuff (TMU, buffer array data, input attachments, counters, etc).

Does that make sense?

Are B1 and B2 are stored in the same area? Are they stored per-core or shared between cores somehow? They’re often identical between many cores, but IIUC other cores can be performing different tasks.

How does the task-manager/thread-dispatch write to each core's B1/B2? In bulk / all-at-once, or granularly? Are these writes significant performance-wise? (kinda technical but related to a shader-design issue I have).

Thanks for all input.

GPUs don’t support per-primitive(or per tesselation-patch etc) data (eg, per-triangle colors/normals) yet, right?

You could do it via a geometry shader couldn't you?

That shouldn't be necessary in most cases. For normals using the screen space derivatives of the position usually works well enough. Furthermore, both DirectX and OpenGL support "flat"/"nointerpolation" for vertex attributes. In such cases, the "provoking vertex" determines the value for the entire primitive (see https://www.khronos.org/opengl/wiki/Primitive#Provoking_vertex). You may need to duplicate a few vertices, but not all of them.

Per-primitive user data

Not an expert on the topic myself, but here is a series of blog posts you may find useful, if you haven't seen it yet: link.

That shouldn't be necessary in most cases. For normals using the screen space derivatives of the position usually works well enough

Lane, SIMD, Core, Package is understandable by everyone

Nvidia is a guess. AMD publishes full details on their site.

Not needed.

For the vertex stage, this is meaningless, but on the other hand, GPUs support (and have been supporting for some years) the current primitive ID (such as gl_PrimitiveID) in any stage that deals with primitives. That ID plus a shader buffer into which you index, and there you go.

Not an expert on the topic myself, but here is a series of blog posts you may find useful, if you haven't seen it yet: link.