It the same can't pass 256mb barier of extendent GPU memory and just die the same.
Which mean that :
1). It is not x5000 related (both x5000/20 and x5000/040 have that issue). It also happens on Tabor.
2). pattern there are: x5000 and Tabor do not have "dma-hack" inside of graphics.library (and they fail), while x1000 and sam460 do have (and they didn't fail). That can be it, or can be not, but wild guess that remapping of memory between CPU and GPU are works when "dma-hacked" routines is used, and didn't when not. Maybe inside of RadeonHD some routines used , from which remapping is taken for granted as it happens to returns from "dma-hack" graphics.library, but its done something different when graphics.library is without "dma-hack". I can be wrong of course, but pattern is here.
So will create bug-report with all the info to RadeonHD now.
Is anyone with X1000 can use "toggledma" binary, and disable DMA, and then do the same tests with 300,600,900, etc ?
But be 100% sure that you disable DMA. I do not have x1000, so i do not know how to use that "toggledma", and how to check if it was enabled/disabled , so be sure you know what and how to do.
By that way, we try to understand if DMA is related somehow or not.
BTW, if you want to check how much free memory you have, you can also use the new X-Dock RadeonMemory DockApp (which displays WB memory and Extended Memory).
A last question : is Hans aware of all this ? Or will you have to analyze everything by yourself alone ?
"toggledma" was just some experiment for beta-testers, so i already got from 2 betatesters confirm that toggle it off didn't change a thing, and filling of GPU memory past 256mb barier still continue to works without crash on x1000 with or without dma, which mean that is not dma itself which is made it works.
Quote:
BTW, if you want to check how much free memory you have, you can also use the new X-Dock RadeonMemory DockApp (which displays WB memory and Extended Memory).
That one very ugly by look, so i also now use zzd10h's "Gfxdock" minidock, it also show pretty info-window in realtime (you can set via tooltype time of "realtime" refresh, but by default its already realtime enough):
(press open in new tab for fullsize):
Quote:
A last question : is Hans aware of all this ? Or will you have to analyze everything by yourself alone ?
Yep, Hans aware now, and it was him who ask me to test with "toggledma".
In brief, and as far as i understand Hans's last answer, he think that its "paging" kick in while shouldn't. At least, that can be logical explain why we crash exactly on 256mb barier. I.e. on 255.5 we didn't crash, but on 256.5 we already crash.
At first i think that it can be graphics.library's fault (i.e. x5000 optimized parts), but then as i wrote in that ticket : all RadeonRX which i tried do not have that issue on my x5000, everything works fine, i can fill up to 4gb of GPU memory without crash. What mean that its issue exactly of RadeonHD. Imho at least, but seems logical to assume that.
@All Hans fix that bug ! Its currently in beta-test, but i can say for sure that it fixed, and i am able to play in RCTW Reborn in full details on x5000 with RadeonHD, as well as by my test tool i can fill as much GPU memory i want now, as well as some games on which i works now want more than 256mb of GPU memory and they works too now.
That one was really important bug, relief that it sorted out.
That's great news. Thank you very much Roman for the work you did on investigating this issue and your peristance, and of 'course thank you Hans for fixing the issue and the hard work you are doing.
@All There is video of Huno's RCTW Reborn port running on full possible details, hi-quality, 1920x1080x32 on that latest beta of RadeonHD : you can see there at begining i spawn from top-bar dockie from gfxdock an info about used system and GPU memory , so you can see that once everything loads it take about 800MB of GPU data, and didn't crashes anymore, yahoo: