Memory on graphics card

[kadambi]

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?

[agd5f]

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.

[glisse]

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 ;)

[kadambi]

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?

[kadambi]

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

[Alex W. Jackson]

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.

[kadambi]

Thanks, I guess I'll wait!!

Question to agd5f:

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

[agd5f]

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/log/?h=modesetting-gem

It also includes kernel modesetting.

[kadambi]

Yes:
http://cgit.freedesktop.org/mesa/drm/log/?h=modesetting-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?

[agd5f]

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.

[kadambi]

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?page=news_item&px=NzMxOA

[agd5f]

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

[Obscene_CNN]

LIM EMS lives again!!!!!

[nanonyme]

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? :)

[Obscene_CNN]

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. :D That used Vesa bios calls I believe though.

http://en.gentoo-wiki.com/wiki/Using_Graphics_Card_Memory_as_Swap

it was marginally faster

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

[agd5f]

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? :)

Any time you want to use the CPU to read or write to something in vram; for example software rendering for unsupported operations.

[nightmorph]

Any time you want to use the CPU to read or write to something in vram; for example software rendering for unsupported operations.
But for normal usage, say for playing hardware-accelerated 3D games or desktop work etc., the graphics card does use all its available memory, right? For both the open-source drivers and Catalyst?

I've got a 512MB X1950 Pro (R500) and in a couple of days a 512MB HD 4550 (R700) will arrive. These are for normal desktop usage; no software-only stuff. I'm not limited to 256MB video RAM for these cards, am I? Doesn't the GPU use all available graphics memory unless you're trying to do something clever like any of the aforementioned scenarios?

[agd5f]

But for normal usage, say for playing hardware-accelerated 3D games or desktop work etc., the graphics card does use all its available memory, right? For both the open-source drivers and Catalyst?

Catalyst yes, open source not yet. The kernel memory manager work that's going on now is needed to address this.

I've got a 512MB X1950 Pro (R500) and in a couple of days a 512MB HD 4550 (R700) will arrive. These are for normal desktop usage; no software-only stuff. I'm not limited to 256MB video RAM for these cards, am I? Doesn't the GPU use all available graphics memory unless you're trying to do something clever like any of the aforementioned scenarios?

Lots of things are drawn with software under normal desktop usage.

[zika]

But for normal usage, say for playing hardware-accelerated 3D games or desktop work etc., the graphics card does use all its available memory, right? For both the open-source drivers and Catalyst?

I've got a 512MB X1950 Pro (R500) and in a couple of days a 512MB HD 4550 (R700) will arrive. These are for normal desktop usage; no software-only stuff. I'm not limited to 256MB video RAM for these cards, am I? Doesn't the GPU use all available graphics memory unless you're trying to do something clever like any of the aforementioned scenarios?
On my ATI HD 3650 I get (Xorg.0.log):(II) RADEON(0): Detected total video RAM=524288K, accessible=262144K (PCI BAR=262144K)
(--) RADEON(0): Mapped VideoRAM: 262144 kByte (128 bit DDR SDRAM)

[nightmorph]

Catalyst yes, open source not yet. The kernel memory manager work that's going on now is needed to address this.
Hmm. Well, the work has been progressing rather rapidly; my understanding is that there's a branch or two of GEM/TTM-like stuff now available for checkout, though it's not stable. Besides, for normal 2D usage, including browsing, documents, watching videos, it's not like the full 512MB of the card would be needed.

I've no doubt that sometime soonish we'll have a memory manager that enables the rest of the video RAM. All ya'll upstream folks have been making fantastic progress. Thanks!

[kadambi]

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

Just tested the code on F12. I think this kind of works. There is some corruption, but I don't see the driCannotAllocateTexture messages. So, is the logic in place now. Any other way I can test it?

[agd5f]

So, is the logic in place now. Any other way I can test it?

Not yet. However, with KMS the CPU accessible memory is a shared pool so any client that needs it can access it. Prior to KMS, memory was statically allocated to certain things.