[Libre-soc-bugs] [Bug 91] Design and implement texturing opcodes for 3D graphics

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sun Sep 20 15:47:16 BST 2020


https://bugs.libre-soc.org/show_bug.cgi?id=91

--- Comment #14 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
Wait, I have an even better idea.

Instead of having three sepatare instructions to replace a texture unit
(bilinear interpolation, coordinate transform, LOAD from texture), you would be
better off with a single instruction.

You add a custom instruction SAMPLE which does all the three mentioned things
together. Maybe you can drop out the coordinate transform as a separate
instruction, perhaps, if you find it necessary.

So a SAMPLE instruction need all the inputs that I mentioned previously. As a
result, it produces a bilinearily interpolated RGB(A?) sample from a texture.
Such an instruction would be a great fit to your architecture. It does a lot of
work in a single instruction, so that reduces the instruction issue bottleneck
and the pressure on registers. It would also be beneficial if there are 2-6
units for handling SAMPLE instructions, because it will have long latency. That
would enable several SAMPLE instructions to be in flight at the same time.

It would work great with a texture cache that I previously described.

You can add this to that bug tracker.

Here is an even better variation:

A SAMPLE instruction takes as inputs:
- a pixel format of the texture
- the address of the texture in memory
- texture pitch
- (x,y) sample coordinates, floating point, in the texture native coordinate
space

The result is an RGB(A) sample.

Then, you also need a separate instruction to help computing the (x,y) sample
coordinates, because they likely need to be converted to texture coordinate
space.

Some textures (maybe all textures) are tiled on triangles (the texture has
finite site, but it is tiled to get an infinite texture in botx x and y axis).

To support that option, the instruction for transforming into texture
coordinates can take as inputs the (logical) texture width and height, and then
perform the modulo operation on final coordinates (texture space) to produce
the tiling effect.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the libre-soc-bugs mailing list