1 / 17

Status – Week 272

Status – Week 272. Victor Moya. Vertex Shader. VS 2.0+ (NV30) based Vertex Shader model. Multithreaded?? Implemented with a FP array (3DLabs P10). Dynamic branching. No texture/vertx buffer load. No vertex kill. Vertex Shader. Shader Model.

zander
Download Presentation

Status – Week 272

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Status – Week 272 Victor Moya

  2. Vertex Shader • VS 2.0+ (NV30) based Vertex Shader model. • Multithreaded?? Implemented with a FP array (3DLabs P10). • Dynamic branching. • No texture/vertx buffer load. • No vertex kill.

  3. Vertex Shader

  4. Shader Model • Mono/Multithreaded Shader based in NV30 instruction set. • A Shader is a stream processor: • Input Stream => Input Register Bank • 16 registers in a Vertex Shader • 12 registers in Pixel Shader • Output Stream => Output Register Bank • ~16 registers in Vertex Shader • ~4 registers in Pixel Shader • Constant Memory/Register Bank • Up to 256 in Vertex Shader

  5. Shader Model • Instruction Cache/Memory • Up to 256 in Vertex Shader • 1024 in Pixel Shader • Shared between different processors (?) • Temporary and Auxiliary Registers • 16 (Vertex Shader), 32/64 (Pixel Shader) • Address Registers • Condition Code Register • Boolean Register • Loop counters • etc.

  6. Shader Model • Multithreaded: • numThreads: Number of streams that the shader can store. Includes idle and loading/unloading threads. Structures affected: Input and Output register banks. • numActiveThreads: Number of active (in execution) threads. Structures affected: temporary and auxiliary registers. PC table (in the Simulator Box). • Constant/Parameter Memory and Instruction Cache/Memory shared between all the threads. It is also shared between different Shaders (but this isn’t provided with the current model).

  7. Test Model • Three boxes: • Loader: gets commands (input stream, new programs and parameters) from a file. • Fetch: fetch instructions from a Shader program memory. • Decode/Execute: decodes and executes instructions, takes into account dependencies. • Writer: receives output stream and writes it in a file.

  8. Test Model • Wires: • Command: sends commands read from the input file to the fetch box. Latency varies for each kind of command and the data size. • New Shader Program: loads new instructions. • New Shader Parameters: loads new parameters in constant memory. • New Input: sends a new input (Vertex Input 16 4D registers). • Sync: for synchronization between Loader and Fetch (execution of a Shader Program depends from the Shader Output with the dynamic branch model). Latency 1.

  9. Test Model • Wires: • Instruction: Fetch send new instructions to Decode/Execute. Instruction EXIT marks end of Shader Program (Decode/Execute send Output to Writer). Latency 1. • NewPC: Fetch recieves control flow changes from Decode/Execute. Latency 1. • Execute: Drives execution latency for each instruction. Variable latency (1 – 5?). • Output: Decode/Execute sends the Shader Program result for the current output to the logger box (Writer). Latency constant but greater than 1 (4 or 5?).

  10. Test Model • Instruction Set: • Encoding in 128 bits. See file. • Emulation: • Separate library: ShaderEmulator.

  11. ShaderEmulator • Performs the functional emulation of the shader: • Instruction (static) management and execution. • Keeps the shader state. • Implementation: • Support for differnt MODELS?: VS1, VS2, PS1, PS2. • How to implement models? Different classess? Switch/case? • Where to keep structures related with control flow? Ex: stack, PC table.

  12. ShaderEmulator • Interface: • ShaderEmulator(numThreads, numActiveThreads, shaderModel) • LoadShaderProgram(code) • ResetShaderState(numThread) • ReadShaderState(numThread, data) • LoadShaderState(numThread, data) • ExecuteShaderInstruction(numThread, PC)

  13. ShaderInstruction • Decoded shader instruction. • What to do with shader models? Invalid instructions in different models. • Interface: • ShaderInstruction(code) • Different functions/attributes to get decoded information from the instruction (input registers, output registers, mask, swizzle, condition codes, etc.).

  14. ShaderExecInstruction • Stores a instance of an instruction that is being executed. • Carries information about the execution: • ShaderInstruction: decoded instruction. • PC: instruction memory address. • state: decode/execution/writeback/locked/… • result: result of the instruction. • startCycle: cycle in which the instruction was fetched. • Other statistics?

  15. ShaderExecInstruction • Implementation: • Avoid dynamic creation of objects. • Static pool. • Created at fetch, destroyed at decode/execute (writeback). • Can be managed by the own ShaderExecInstruction class? (static).

  16. Test Model

  17. Code Management • Directory structure: • /emu (or /emulator): functional emulation classes and functions. • /sim (or /simulator): simulation classes and functions. • /support: support functions (IO, Types, etc.).

More Related