0
\$\begingroup\$

I have a question which I hope is not out of the scope of this branch of the exchange network and is a fair question (to be fair I have provided a block diagram on what I have so far) on the "basics" of how to implement a per/pixel shader block on an FPGA provided with the three components below. I have been able to create the core with the blocks in the main box but right now it is a wireframe design.

Can any guidance be provided as to what goes into a shader from a conceptual standpoint and is it feasible to try to create a shader from the resources on the board provided below? Does coloring proceed shading?

Please advise.

Block Diagram enter image description here

Block Details enter image description here

Behavioral Simulation enter image description here

\$\endgroup\$
6
  • 1
    \$\begingroup\$ What expectations do you on performance with a low performance FPGA vs other options. e.g. what are your performance acceptance criteria? \$\endgroup\$ Jun 16 '18 at 21:42
  • \$\begingroup\$ With regards to the performance I have only considered space. I see many schematics but I tend to try to get lost in translating to a simple idea in my mind. I would consider using some sort of look up table based shader. The only space requirements I can consider are DRAM at 4GB (34gigabits of storage) for frame buffering memory which I am using a peripheral memory as compared to the on-chip Block Rams which significantly hider my resolution to under my desired res of 512X512 at a realistic refresh rate. \$\endgroup\$
    – Vahe
    Jun 16 '18 at 21:53
  • \$\begingroup\$ vimeo.com/13983760 \$\endgroup\$ Jun 16 '18 at 22:07
  • \$\begingroup\$ I guess where I need the most help is where to start from a hardware standpoint. \$\endgroup\$
    – Vahe
    Jun 16 '18 at 22:14
  • \$\begingroup\$ Always use triangles for most efficient mapping. You are showing 20yr old technology , today hardware has 222M Transistors 660M tris /second 64 Gflops 128 bit color 1600 x 1200 16:1 aniso filtering \$\endgroup\$ Jun 17 '18 at 3:46
1
\$\begingroup\$

This pipeline doesn't map triangles, but looks at each vertex in isolation, so it cannot do more than draw a wireframe.

You can probably color these pixels differently by inserting a block between the line generator and the frame buffer that, for each pair of coordinates received, runs a small program/state machine that decides what value to write to the framebuffer.

At this point however all 3D information is lost already (the line generator doesn't interpolate Z values, even though it could probably be extended to do so with little extra cost).

For useful shaders, you probably also want to reverse the rotation (so the shader has access to world coordinates), which requires another matrix multiplication block or a separate state.

For lighting, we need to run triangles rather than vertices through the pipeline so we can determine the normal vector (which would be underspecified otherwise), which is a considerable change, but should still be possible with the existing framework.

The other thing that is missing in the current pipeline is a Z buffer.

\$\endgroup\$
3
  • \$\begingroup\$ My apologies, I forgot to mention that I mapped quads rather than triangles to make the object look less crowded in wireframe. If problematic I can render a triangle primitives instead. Where I am lost really is interpolation per pixel (the actual shader). There is so much to the math that it leads me to conclude is it possible to design a phong (like) shader on my FPGA? As to the point on Z-Buffer I just purchased a 4GB SODIMM SDRAM to connect to my FPGA board to increase storage. The max storage I can get is 512(9bits horiz)*512(9bits vertical)*512(9bits color)*256(8 bit depth). \$\endgroup\$
    – Vahe
    Jun 16 '18 at 22:43
  • 1
    \$\begingroup\$ Your math is wrong: Framebuffer is 2D, not 3D. So you can use 1024x1024x24 bit for RGB data and 1024x1024x32 bit for the Z buffer and have still quite some room to spare, e.g. for textures. \$\endgroup\$
    – Turbo J
    Jun 17 '18 at 7:44
  • \$\begingroup\$ @Vahe, you can also use quads there, but normals calculation would probably still look at three points only for simplicity. The interpolation happens in screen space (as you can see in the pipeline, the line generator works on screen coordinates), but the coordinates are then mapped back into world space to get texture coordinates. The actual shader is called on the coordinates generated by the interpolation block, if the pixel is actually visible (so you'd probably have a FIFO with coordinates for which the shader should be run). \$\endgroup\$ Jun 17 '18 at 17:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.