[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 11:12:14 BST 2020


--- Comment #13 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
A texture unit has read-only access to the memory. All textures are basically
just a huge array of constants. I think you don't need to monitor that by the
OoO unit, because there is absolutely no need to monitor constants. Even if a
texture gets corrupted, there is no problem: it's just one pixel having a wrong
color. Nobody notices that.

You need to have at most one texture unit per core. In your case, it will be
exactly one texture unit, for simplification.

A texture unit can be pipelined or not pipelined. A non-pipelined unit would
accept a SIMD request to produce about 8 samples.

The inputs for a request are:
- texture address,
- texture width and height in pixels, pitch,
- pixel format,
- (x,y) sample coordinates, x8 for 8 samples
- optionally, a transformation matrix for x,y coordinates

In some texture units, all the samples in a single request must be from the
same texture. I think that is not strictly necessary, but it probably reduces
the complexity of the texture unit.

A texture unit usually stores a block of 4x4 pixel data in a single cache line.
The textures in the GPU memory use the same format: 4x4 pixel blocks. Textures
might also use Lebesgue curve. So, there is 16 pixels in a block but it doesn't
have to be in RGBA format. "Pixel format" can be something really crazy. That's
how texture compression works. It reduces memory bandwidth.

The problem of adding a texture unit to your design is to figure out how to
keep it utilized, because shaders don't do texture sampling all the time. When
shaders are doing something else, the texture unit is doing nothing, wasting
What latency should the texture unit have? Should it be a low-latency, SIMD,
non-pipelined design, or a high-latency, pipelined design?

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

More information about the libre-soc-bugs mailing list