Timeline for Do shader compilers typically know not to look up unused texture channels?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 10, 2015 at 1:10 | comment | added | v.oddou |
for the first question, the filtering is not impacted by memory layout. check this statement vec3 clr(ram[x], ram[x+1], ram[x+1]) versus vec3 clr(ram[x], ram[x+w], ram[x+w+w]) with w=total texture mem size / numchannels. These 2 statements symbolizes channels fetching to compose one vector color with 2 different memory layouts, 1=interleaved, 2=separated. The computations on the filtering happens on clr style variables, and therefore not impacted by where its components comes from.
|
|
| Sep 10, 2015 at 1:02 | comment | added | v.oddou | from eecg.toronto.edu/~myrto/gpuarch-ispass2010.pdf apparently a typical cache line is 32 bytes, so if you have a single channel texture, one fetch will burst read 32 pixels at once. these pixels will be cached so neighbors can profit. It is very advantageous to diminish your texture depth/channels/dimensions as much as you can to reduce bandwidth requirements. So if you can make your textures single channel-ed, it is much better. | |
| Sep 9, 2015 at 11:59 | comment | added | TenFour04 | Do you know how linear interpolation for texture filtering is done if the channels are interleaved? And does a single or double channel texture still get fetched with 4 bytes per pixel? | |
| Sep 9, 2015 at 11:57 | vote | accept | TenFour04 | ||
| Sep 9, 2015 at 7:10 | history | answered | v.oddou | CC BY-SA 3.0 |