Status week 272
This presentation is the property of its rightful owner.
Sponsored Links
1 / 17

Status – Week 272 PowerPoint PPT Presentation


  • 62 Views
  • Uploaded on
  • Presentation posted in: General

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.

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


Status week 272

Status – Week 272

Victor Moya


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.


Vertex shader1

Vertex Shader


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.


Shaderemulator

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.


Shaderemulator1

ShaderEmulator

  • Interface:

    • ShaderEmulator(numThreads, numActiveThreads, shaderModel)

    • LoadShaderProgram(code)

    • ResetShaderState(numThread)

    • ReadShaderState(numThread, data)

    • LoadShaderState(numThread, data)

    • ExecuteShaderInstruction(numThread, PC)


Shaderinstruction

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


Shaderexecinstruction

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?


Shaderexecinstruction1

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


Test model4

Test Model


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


  • Login