Posts: 26,215
Joined: Oct 2003
Reputation:
187
The sourcecode that we use in the texture packer is in SVN as well - see MakeDDS. It uses squishlib which (in my experience) gives very slightly better quality than the nvidia tools. I suspect you'd have to measure the difference rather than see it though.
Posts: 72
Joined: Nov 2009
Reputation:
0
I sometimes have 'pop-in' type effects on wall views, such as the one in Xperience.
I was wondering if using .dds instead of the .tbn files would help, or would even work?
All of my movies have a movie.tbn file, which in most cases is a 1000x1500px JPG, although I expect XBMC caches at a lower res than that.
Cheers,
Sean.
Posts: 126
Joined: Jan 2010
Reputation:
0
2010-01-21, 21:53
(This post was last modified: 2010-01-21, 22:01 by IceNine.)
Well I have finally gotten to the point where I am ready to try this. I wanted to make things easy on myself in the future, so I downloaded and compiled the nvidia texture tools on my ION machine (took a while for me to figure out how to get it running, it doesn't like Karmic, then had to get CUDA support because compressing on the Atom took *forever*), then I wrote a little script that would automatically find any .tbn files in the Fanart folder and convert them to .dds, then move them to a different folder.
I want to keep the originals in case I want to move off of .dds files, but I wanted to move them out of that folder so that whenever I would add anything new, the script would only convert the new ones.
Since I'm really not much of a linux user before this, it was all a large learning experience. If anyone is trying to do this same kind of setup I should be able to help with any problems you might have, I figure I have run into them all by now.
Based on arco's videos, I am looking forward to the performance increase this should get me. I'll keep everyone posted, this could really breathe new life into XBMC on low power ION machines.
As a followup to the start of this thread, have there been any further developments in the XBMC code for integrating .dds support? Any future plans for this that might be realized in the next major release? I know it would be great to have this kind of thing integrated into the core so the fanart and possibly the other thumbnails as well are using the .dds format to put more cycles into the GPU. I know that not all GPU's are anywhere the same performance level, but they are optimized to handle this kind of thing, so decompression of an image should be something a GPU can handle a lot more easily than a CPU.
Posts: 126
Joined: Jan 2010
Reputation:
0
2010-01-21, 23:17
(This post was last modified: 2010-01-21, 23:24 by IceNine.)
Well I got all my fanart converted to .dds format and the speed difference is amazing! There is a size increase (the .dds files take up about 4x as much space as the original .tbn files), but the speed increase is more than just noticeable; it's like a whole different machine. I did some cpu usage tests remotely and scrolling through my movies on Aeon65's Multiplex view uses literally about half the cpu power with .dds files than it did with .tbn files. Scrolling through at full speed before pretty much maxed out the cpu, now it goes a little over half usage. Coverflow view works quite a bit better as well, with no thumbnail lag.
I would say that this endeavor of .dds format fanart is more than worth it for anyone running a low cpu-power machine such as an ASRock or Acer Aspire.
EDIT:
Upon closing inspection, it seems that all my .tbn fanart files have been recreated. XBMC still seems to be loading the .dds files; is it expected behavior for the original .tbn files to be recreated?
Posts: 26,215
Joined: Oct 2003
Reputation:
187
That's probably expected.
Note that of particular interest is the time to convert from tbn to dds. It was 7 seconds or so on my dev machine for a 1080p image for instance.
Posts: 126
Joined: Jan 2010
Reputation:
0
2010-01-22, 16:07
(This post was last modified: 2010-01-22, 20:05 by IceNine.)
Well I did some benchmarks for you this morning on a 1920x1080 jpg, with and without CUDA acceleration on my ION machine.
CUDA Enabled: 10.300 seconds
CUDA Disabled: 701.500 seconds
CUDA Disabled, using -fast option: 22.300 seconds
Obviously if this ever makes it as a full-blown feature in XBMC and the .dds compression is done internally some sort of CUDA acceleration will be needed for machines such as the ION. It would probably benefit anyone with an nVidia card since CUDA should be as fast if not faster than CPU anyway.
Is there anything else I can do on my end that might help this project along? If none of the devs have an ION machine to test on I'd be happy to run some code for you or give you any information I have gotten through this whole endeavor.
Also: If XBMC is recreating the .tbn fanart, even when <useddsfanart> is on, does this mean that if I had .dds files for all my current stuff but I added something new, would XBMC use the .tbn file for the new thing until I made the .dds file or would it act like it couldn't find the fanart at all?
Posts: 126
Joined: Jan 2010
Reputation:
0
2010-01-22, 19:55
(This post was last modified: 2010-01-22, 20:06 by IceNine.)
Ok, here is some more real world usage information I have been able to do today. I saw the feature request in Trac for this, so I am trying to help as much as I can.
1280x720 image compression:
CUDA enabled: 4.640 seconds
CUDA disabled: 327.470 seconds
CUDA disabled, using -fast option: 10.010 seconds
This is the same image used in the 1080 tests, rescaled to 720. I tried multiple images, and complexity and content doesn't seem to change the compression times significantly.
When I am playing a video in XBMC and run some compressions, with CUDA enabled the compression interferes with playback, but with CUDA off the video plays fine.
Keep in mind I am only using the nVidia Texture Tools for these tests (which use squishlib now also, at least in the Linux versions) on my ION machine. I did a test on a Core2 windows machine and got a similar result to yours, so without CUDA or some other kind of acceleration a moderately powerful CPU will be needed to be able to use this. With CUDA turned off compression takes up one thread of one core of the CPU, which is probably why it doesn't interfere with playback. If the tool was multi-threaded compression would probably be faster.
Posts: 399
Joined: Jul 2009
Reputation:
0
why was the zip file removed from the first post?
Posts: 239
Joined: Nov 2009
Reputation:
1
bleze
Senior Member
Posts: 239
what about posters/covers. would help on scrolling instead of those placeholders showing up when scrolling fast