Login at Kodi Home

regnets · 2012-10-25, 09:16

Hi,

i found various references for dds fanart on raspberry pi. The xbmc wiki says that dds fanart isn't working on arm/atv2/ios devices. Some guy in the raspberry pi forums asserts that it is working.

So can i get an official answer?

Also it would be great to know if the dds rendering benefits from a overclocked gpu.

Thank you in advance

Best regards

regnets

**gimli** · 2012-10-25, 09:18

Technical dds fanarts work on the PI.

~~Ned Scott~~ · 2012-10-25, 09:28

The only thing I see on the wiki is a mention specifically about the ATV2, but not about other ARM devices.

regnets · (This post was last modified: 2012-10-25, 09:33 by regnets.)

...but there are some problems?

And i can assume that it contribute to a speedier gui on the raspberry because the cpu don't have to do the jpeg/png uncompression?

Thank you for the fast answer!

@ned: I was sure there was a reference to arm devices. But you are right there is no reference to arm devices.

**gimli** · 2012-10-25, 09:42

Stay with jpeg files, those are well tested. I'm unsure if DDS fanarts have a negative memory impact on the GPU side.

regnets · 2012-10-25, 10:01

I've got a 512 MB Raspberry Pi and will use a 256/256 split, so i think the larger mermory footprint could be negligible. Or do you think the impact will be really great?

**gimli** · 2012-10-25, 10:07

(2012-10-25, 10:01)regnets Wrote: I've got a 512 MB Raspberry Pi and will use a 256/256 split, so i think the larger mermory footprint could be negligible. Or do you think the impact will be really great?

My advise is not using dds fanarts.

regnets · 2012-10-25, 10:10

Ok if you say so, i have nothing to riposte. You are the expert! Thank you!

jmarshall · 2012-10-25, 11:23

@gimli: Does the GPU even support DXTn compression? I was under the assumption that most of these SoCs don't?

**gimli** · 2012-10-25, 11:27

@jmarshall: don't know. At least it worked when i enmabled it.

**popcornmix** · 2012-10-25, 12:35

The GPU has no hardware support for compressed textures. At best it will decompress them when texture is uploaded then use the full size version.
I'd expect dds is best disabled, but it would be useful if someone can try it each way and report which is faster or more stable.

j4nu5 · 2012-10-25, 13:56

i did some testing with dds fanart yesterday. imo the gui seems a little bit faster (tried the fanart view in the video lib), also i didn't look at the cpu usage. i'll do it this evening.

**gimli** · 2012-10-25, 13:59

(2012-10-25, 13:56)j4nu5 Wrote: i did some testing with dds fanart yesterday. imo the gui seems a little bit faster (tried the fanart view in the video lib), also i didn't look at the cpu usage. i'll do it this evening.

Also check "vcdbg reloc" to see the GPU usage.

topfs2 · 2012-10-25, 15:38

(2012-10-25, 11:23)jmarshall Wrote: @gimli: Does the GPU even support DXTn compression? I was under the assumption that most of these SoCs don't?

IIRC no SoC afaik support it, they have different algorithms but not DXTn. My memory is rather fuzzy but s3tc is usually supported on linux with gles and is (if my memory serve me right) DXT1. Another more common, since its used in android, is ETC1-3 (unsure on the number, might be ETC2). Not sure if ETC2 is available on pure linux gles.

(2012-10-25, 09:42)gimli Wrote: Stay with jpeg files, those are well tested. I'm unsure if DDS fanarts have a negative memory impact on the GPU side.

In general DDS, or more importantly the texture and its compression inside it has good memory impact. Usually adds a bit on the processing (needs to decompress at render) but thats usually done in hw so usually almost a noop. Not sure which compression algorithms the PI supports though? S3TC? ETC2?

**popcornmix** · (This post was last modified: 2012-10-25, 17:11 by popcornmix.)

I've found out that the R-Pi does support ETC1 in hardware, and that is 4bpp (so 1/8 size).
It's lossy, so will have some effect on quality. I don't think xbmc supports that though.

Enabling dds means we load the compressed file (which is smaller), but the ARM decodes it to 32bpp before uploading to GPU. I'd be surprised if this is faster.