status week 272
Skip this Video
Download Presentation
Status – Week 272

Loading in 2 Seconds...

play fullscreen
1 / 17

Status – Week 272 - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Status – Week 272' - zander

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
vertex shader
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.
shader model
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
shader model1
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.
shader model2
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).
test model
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.
test model1
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.
test model2
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?).
test model3
Test Model
  • Instruction Set:
    • Encoding in 128 bits. See file.
  • Emulation:
    • Separate library: 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.
  • Interface:
    • ShaderEmulator(numThreads, numActiveThreads, shaderModel)
    • LoadShaderProgram(code)
    • ResetShaderState(numThread)
    • ReadShaderState(numThread, data)
    • LoadShaderState(numThread, data)
    • ExecuteShaderInstruction(numThread, PC)
  • 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.).
  • 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?
  • 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).
code management
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.).