Announcement

Collapse
No announcement yet.

Memory on graphics card

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Memory on graphics card

    I looked around for this problem and couldn't find any solutions. On my X800 Fedora 9 (radeon 6.8.0) box, I see this message

    (II) RADEON(0): Detected total video RAM=262144K, accessible=262144K (PCI BAR=262144K)
    (--) RADEON(0): Mapped VideoRAM: 262144 kByte (256 bit DDR SDRAM)


    Fair enough. It is a 256 MB PCIE card.

    However on the Fedora 10 X1650 AGP card, the mapped memory seems half:

    (II) RADEON(0): Detected total video RAM=524288K, accessible=262144K (PCI BAR=262144K)
    (--) RADEON(0): Mapped VideoRAM: 262144 kByte (128 bit DDR SDRAM)

    I see the same on my FreeBSD 6.3 system with ATI 9250 256 MB AGP card which showed the mapped videoRAM to be 128 MB. I replaced the card with ATI 9550 AGP 256MB card and it showed the right mapped videoRAM (256 MB).

    After some google search, I came across several posts mentioning that it is PCI_BAR that is setting the range and the actual memory is still 512MB and not half.

    So, I uploaded 4 512x512x64 RGBA textures into the ATI X1650 512MB card (on the Fedora 10 system). 4 such textures take 256 MB memory and a 512MB card should be able to handle it.

    But I got a "driallocatetexture 636", which means there isn't enough memory, which led me to suspect that the driver is seeing only 256MB memory. Right?

    Any ideas?

  • #2
    The maximum PCI bar size is 256 MB and is is further limited to the size of the BAR on the device. Thus the largest framebuffer you can map and access from the CPU is the maximum BAR size on your device (256 MB or less). The rest of the vram is accessible by the GPU only. As such it's possible to store things in the non-CPU accessible region, it just get complicated to access if you need to get to the data from the CPU.

    Comment


    • #3
      Originally posted by agd5f View Post
      The maximum PCI bar size is 256 MB and is is further limited to the size of the BAR on the device. Thus the largest framebuffer you can map and access from the CPU is the maximum BAR size on your device (256 MB or less). The rest of the vram is accessible by the GPU only. As such it's possible to store things in the non-CPU accessible region, it just get complicated to access if you need to get to the data from the CPU.
      It's also for such case that memory manager would be usefull

      Comment


      • #4
        Originally posted by agd5f View Post
        The maximum PCI bar size is 256 MB and is is further limited to the size of the BAR on the device. Thus the largest framebuffer you can map and access from the CPU is the maximum BAR size on your device (256 MB or less). The rest of the vram is accessible by the GPU only. As such it's possible to store things in the non-CPU accessible region, it just get complicated to access if you need to get to the data from the CPU.
        OK, How do I do it? :-) How can I upload these large textures?
        I tried with fglrx and it worked fine, even though I get the same PCI_BAR message

        Any pointers?

        Comment


        • #5
          To further clarify, I just need to upload data to the GPU. There aren't any data transfers between CPI and GPU after that.

          Comment


          • #6
            As I understand it, currently with the free driver (radeon/radeonhd) you can't use VRAM more than 256MB, period. This will (only) change once a memory manager is implemented in the driver.

            Comment


            • #7
              Thanks, I guess I'll wait!!

              Question to agd5f:

              Is mem manager being worked on? If so, where can I follow the development?

              Comment


              • #8
                Originally posted by kadambi View Post
                Thanks, I guess I'll wait!!

                Question to agd5f:

                Is mem manager being worked on? If so, where can I follow the development?
                Yes:
                http://cgit.freedesktop.org/mesa/drm...odesetting-gem

                It also includes kernel modesetting.

                Comment


                • #9
                  Originally posted by agd5f View Post
                  Yes:
                  http://cgit.freedesktop.org/mesa/drm...odesetting-gem

                  It also includes kernel modesetting.
                  So, I just got a ATI x1950 512MB card and installed Fedora 10 hoping this would work since KMS works on F10.

                  Well, It still doesn't seem to see beyond 256MB. I tried my code and I get the same message about dri not able to allocate textures.

                  So, I assume memory manager is still not in place?
                  Last edited by kadambi; 12-05-2008, 04:57 PM.

                  Comment


                  • #10
                    Originally posted by kadambi View Post
                    So, I just got a ATI x1950 512MB card and installed Fedora 10 hoping this would work since KMS works on F10.

                    Well, It still doesn't seem to see beyond 256MB. I tried my code and I get the same message about dri not able to allocate textures.

                    So, I assume memory manager is still not in place?
                    The memory manager is in place, we just aren't using the memory outside the BAR yet. It's a bit tricky since that memory cannot be accessed by the CPU, so if sw needs to access it it has to be migrated somewhere it can be mapped or accessed. Don't worry, we'll get there eventually.

                    Comment


                    • #11
                      OK, I got F11 which was released couple of days ago. It still says in dmesg that the accessible memory on card is 256MB.

                      I assume there is still some work to be done?

                      Would this fix the issue?

                      http://www.phoronix.com/scan.php?pag...item&px=NzMxOA

                      Comment


                      • #12
                        The logic for dealing with non-CPU accessible memory still needs to be added. It's on the todo list.

                        Comment


                        • #13
                          LIM EMS lives again!!!!!

                          Comment


                          • #14
                            Originally posted by agd5f View Post
                            The logic for dealing with non-CPU accessible memory still needs to be added. It's on the todo list.
                            Hmm, does it happen often then that you have to access the memory directly with CPU instead of being able to deal with stuff through GPU? Got an example use case for the interested reader?

                            Comment


                            • #15
                              I have a case that I have actually used once. I used the video mem as a swap file to speed up an 8GB process in a machine that had just 2GB of RAM. That used Vesa bios calls I believe though.

                              http://en.gentoo-wiki.com/wiki/Using...Memory_as_Swap

                              it was marginally faster

                              In the future with OpenCL fast access to all video card ram will become more important.

                              Comment

                              Working...
                              X