[Skin] GPU Accelerated loading of fanart/images (1 Viewer)

[DJBlu]

Re: AW: GPU Accelerated loading of fanart/images

Does it also improve speed on ATI cards?

Should do yes.

 

[tourettes]

Non pow 2 textures

Looks like Nvidia's texture compression tool is able to use non pow 2 textures. The tool can be downloaded from: NVIDIA Texture Tools 2: Open Source GPU-Accelerated Compressor

It also supports CUDA, and with CUDA enabled texture packing it is approx 9x faster on my dev PC than with the CPU based one. When running make sure that you are writing the textures into a folder where your user account has write access (by default the user wont have any write access to the binary /program files folder).

As a test I was able to create a DDS file from JPEG that has 4272x2848 as the dimensions. Shouldn't be pow 2

nvcompress.exe -bc3 "\\source\test.jpg" c:\test.dds

And with no CUDA available it might require -nocuda paramater to be used (Intel, ATI).

Please test if you are able to create non pow 2 textures with that since it would be much better to be able to use textures in that way.

 

[azzuro]

hi, for ATI user, is Compressonator ! for compress texture, not valid in photoshop !
but ATI SDK for integrate directly in App ( i think in Moving pictures or directly in MePo)

Cdt

 

[Jay_UK]

Hi there,

I tried the nVidia nvcompress, but it doesn't seem to like the jpg format?? (It errors saying supported format)

J.

 

[Sebastiii]

Hi,

You must take the x86 of Nvidia Compressor version even on x64 Windows, i have attach and adapt a batch to copy to jpg folder and convert all in one.
I have put a line to delete all jpg in directory maybe you should comment out this line
Thanks,
Seb.

 

[Inker]

I have experimented with this before, as said above, no code changes are required (strickly speaking).
I have a patch laying around that hcanges the texturepacker to pack things as dds instead of png. But I decided not to pursue it because while packed skin files are loaded faster (about 150ms before to about 35ms after per packed texture) it doesnt really matter because they are loaded once per application start only anyways.

The other graphics, are things like fanart. Those get loaded/unloaded on the fly, so the should benefit. Nothing is stopping skinners that use alot of such large images to supply them as dds, or convert them to dds in their installer. So MePo shouldn't interfere here.

The last thing, are dynamically downloaded/created images, like movie-specific fanart etc. Here we have to question filesize/time to convert these images. DDS files are vastly larger than most jepgs, so for users with 100s of movies, and a few fanart per movie, maybe large poster files, we could be taking gbs of data. And to convert them, is MePo responsible to do that, or the plugins? Should it be handled in the background? I think this should be up to plugin-devs to decide, as they know best. If they are converted on first load, this will slow things down alot for the first time.

To sum up, IMO:
- packed graphics doesnt benefit noticably at all
- static images of skins should be handled by the skinners
- plugin-devs are the only ones that can know for what images their plugin may benefit. It should be up to them to save them as such (its simple to write a file as dds) as they may also reference them in their database or handle cleaning up. So they have to know whats going on.
- In the end, Mediaportal is fully ready to support dds images. It's more a matter of educating skin/plugin-devs.

Edit: heres some quick code to convert an image to DDS and save it to the disk for consequent loading. I'm sure Nvidia texture tools etc. are faster/higher quality, but this is to get an idea if someone wants to write code.

    private static void SaveAsDDS(Bitmap Image, string filename)
    {
      using (var iStream = ConvertImageToStream(Image))
      {
        Format fmt = Format.A8R8G8B8;
        var info = new ImageInformation();

        var texture = TextureLoader.FromStream(GUIGraphicsContext.DX9Device,
                                         iStream, (int)iStream.Length,
                                         0, 0, //width/height -> auto
                                         1, //mipslevels
                                         0,
                                         fmt,
                                         GUIGraphicsContext.GetTexturePoolType(),
                                         Filter.None,
                                         Filter.None,
                                         0,
                                         ref info);
        TextureLoader.Save(filename, ImageFileFormat.Dds, texture);
        texture.SafeDispose();
      }
    }

    private static MemoryStream ConvertImageToStream(Bitmap imageToConvert)
    {
      var ms = new MemoryStream(imageToConvert.Width * imageToConvert.Size.Height * 4);
      imageToConvert.Save(ms, ImageFormat.Bmp);
      ms.Seek(0, SeekOrigin.Begin);
      return ms;
    }

 

[Jay_UK]

Hi there,

I tried the x86 version and it now generates the dds files, but it is not using CUDA.

It looks like it is a long winded route to get CUDA enabled for jpg on x64 using x86 software. (although I could be wrong) :O

But at least we have got around the pow 2 issue

Thanks,

J.

 

[Sebastiii]

I have experimented with this before, as said above, no code changes are required (strickly speaking).
I have a patch laying around that hcanges the texturepacker to pack things as dds instead of png. But I decided not to pursue it because while packed skin files are loaded faster (about 150ms before to about 35ms after per packed texture) it doesnt really matter because they are loaded once per application start only anyways.

The other graphics, are things like fanart. Those get loaded/unloaded on the fly, so the should benefit. Nothing is stopping skinners that use alot of such large images to supply them as dds, or convert them to dds in their installer. So MePo shouldn't interfere here.

The last thing, are dynamically downloaded/created images, like movie-specific fanart etc. Here we have to question filesize/time to convert these images. DDS files are vastly larger than most jepgs, so for users with 100s of movies, and a few fanart per movie, maybe large poster files, we could be taking gbs of data. And to convert them, is MePo responsible to do that, or the plugins? Should it be handled in the background? I think this should be up to plugin-devs to decide, as they know best. If they are converted on first load, this will slow things down alot for the first time.

To sum up, IMO:
- packed graphics doesnt benefit noticably at all
- static images of skins should be handled by the skinners
- plugin-devs are the only ones that can know for what images their plugin may benefit. It should be up to them to save them as such (its simple to write a file as dds) as they may also reference them in their database or handle cleaning up. So they have to know whats going on.
- In the end, Mediaportal is fully ready to support dds images. It's more a matter of educating skin/plugin-devs.

Edit: heres some quick code to convert an image to DDS and save it to the disk for consequent loading. I'm sure Nvidia texture tools etc. are faster/higher quality, but this is to get an idea if someone wants to write code.

    private static void SaveAsDDS(Bitmap Image, string filename)
    {
      using (var iStream = ConvertImageToStream(Image))
      {
        Format fmt = Format.A8R8G8B8;
        var info = new ImageInformation();

        var texture = TextureLoader.FromStream(GUIGraphicsContext.DX9Device,
                                         iStream, (int)iStream.Length,
                                         0, 0, //width/height -> auto
                                         1, //mipslevels
                                         0,
                                         fmt,
                                         GUIGraphicsContext.GetTexturePoolType(),
                                         Filter.None,
                                         Filter.None,
                                         0,
                                         ref info);
        TextureLoader.Save(filename, ImageFileFormat.Dds, texture);
        texture.SafeDispose();
      }
    }

    private static MemoryStream ConvertImageToStream(Bitmap imageToConvert)
    {
      var ms = new MemoryStream(imageToConvert.Width * imageToConvert.Size.Height * 4);
      imageToConvert.Save(ms, ImageFormat.Bmp);
      ms.Seek(0, SeekOrigin.Begin);
      return ms;
    }

Hi,
Thank you for explanation and part of code yep aftre conversion a lot of space is take but if we have a speedup it's cool
Seb.

 

[matejdro]

The last thing, are dynamically downloaded/created images, like movie-specific fanart etc. Here we have to question filesize/time to convert these images. DDS files are vastly larger than most jepgs, so for users with 100s of movies, and a few fanart per movie, maybe large poster files, we could be taking gbs of data. And to convert them, is MePo responsible to do that, or the plugins? Should it be handled in the background? I think this should be up to plugin-devs to decide, as they know best. If they are converted on first load, this will slow things down alot for the first time.

That is what i think:

1. It should be optional, so people can turn it on only if they have enough disk space to run it.
2. DDS files should be made by whatever downloads the image, so either plugin (MovingPictures) or mediaportal (default movie library).
3. They should be converted right after download. If user wants to convert fanart to DDS after he already downloaded it in other format, it should be done in background when it won't interrupt or slow down user. For example when computer is idle. Otherwise do it at really low priority, so there are no slowdowns.

 

[GrandDK]

Nice with the guide for implementing the DDS to Moving Pictures. Is it also possible to follow the same steps with My tv series?

Edit: tried it out and indeed it does feel faster and with cuda to do the encoding of the files it didnt take me more than a couple of minutes to change them all.

1 thing though it only seems to utilize Backgrounds and posters so the only view working is list. Anyone know what line in sql I need to edit to make the rest of the .dds files used?