Texture Memory management code

  • Aasimon

    Aasimon - 2008-03-18

    I have been playing with Pixie for a little while now and notice that each thread I use to render with seems to allocate its own texture memory and then load the needed texture.

    Am I reading this correctly?

    What is the design theory behind the texture memory management and threading?
    Is there any way to control this behaviour?


    • Okan Arikan

      Okan Arikan - 2008-03-18


         The total texture memory is equal to number of threads * texture memory per thread. This is similar to how PrMan manages threads.

         This however does not mean that each thread does its own texture management. In particular, if one thread loads a texture (or a part of a texture) and another thread needs it, it will be shared so that there will not be duplicate textures in the memory.

         Does this help?


      • Aasimon

        Aasimon - 2008-03-19

        Yes that helps thanks.

        Nother question. How would I go about keeping textures loaded between frames?

        • Okan Arikan

          Okan Arikan - 2008-03-19

              The current version of the code flushes the texture cache at every frame. I can change the code to avoid this but realistically, texture loading overhead should be almost negligible.


          • Aasimon

            Aasimon - 2008-03-20

            I am rendering many fames of animation, so that change to the code would be welcome. :) Thanks.

            As for texture loading overhead. I have been having real trouble with this.

            Set the Scene:
            Windows Vista.
            2x Quad Code Xeons running 4 Pixie threads.
            About 107 Mb of raw tiff files before RiMakeTexture() makes .tx files.
            The Output render is a person's head and torso, 90%+ of every texture is needed in the render.

            At first, I had the problem that after every frame rendered the amount of used memory went up, so my animation sequence would run out of memory and crash. Turned out to be libTiff3.dll !! Every time I opened and closed a file I lost memory!! I fixed this by getting the SVN code and recompiling using VS2005.

            Second problem. Because RiMakeTexture() tiles the Tiffs into 32x32 chunks, every frame rendered, a 2K texture was being opened many many times and the overhead on this was killing the render time. I changed the code to allow RiMakeTexture() to take a "tilesize" param that I just set to 2048. This removed lots of the file opens.

            Third problem. The maximum texture memory is clamped to 100M, which is divided between the threads (25M per thread). Due to the tile size change in problem two the cached textures where thrashing, big time, and upping the amount of times the tiffs where loaded. So I had to change the code to up the maximum texture limit.

            Once I had done all of these changes I got back over 30% of my render time for a single frame.

            14.7s Original Render Time
            8.8s  New Render Time

            I will send you a copy of my changes so you can see what I did.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks