OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Hardware => Topic started by: Dariusz Piatkowski on October 24, 2017, 09:31:45 pm
-
Folks,
I just installed the AN release of the SNAP video drivers here. What I found was both exhilarating and somewhat dissapointing (well, just a tad bit, but read on), so I thought I'd share my experience.
My findings relate to the differences between the IBM/SciTech SNAP drivers (the latest publicly available build being 3.1.8 I believe) and the current SNAP drivers that are shipping with the ANOS, that being 'Build No 506'.
Alright, so ATI X850 XT PE video card here, driving my Samsung 245T panel at 1900x1200 resolution.
OK, good, heck GREAT stuff first. I used to suffer from that annoying OS/2 version of the "Blue Screen of Death"...LOL, meaning, as the GUI comes up and WPS is starting to initialize my system would simply hang. Not a hard hang, CTL-ALT-DEL would allow a re-boot w/o a chkdsk. This would only happen if I ran all 6 cores of my AMD Phenom CPU enabled. Since that made my box un-usable I disabled the 6th core in BIOS and simply used a crippled system with 5 cores only. But hey, at least it worked!!!
Well, I am thrilled to report this issue is now GONE...no longer a problem, I can routinely re-boot using the full 6 cores, no WPS start-up hang, all good! This is a great result. My understanding is that the SNAP drivers had some SMP related issues addressed, so if this was one of them it certainly did the trick.
Alright...so what's the "problematic" piece to report on?
Hmm, the video performance is down. Not sure why that is the case, I will log a ticket for the SNAP team and point to a few things I'm seeing, but in short, take a look at the before & after Sysbench 0.9.5d results:
1) old IBM/SciTech SNAP drivers
Graphics
BitBlt S->S copy : 9175.950 Million pixels/second
BitBlt M->S copy : 293.762 Million pixels/second
Filled Rectangle : 22804.327 Million pixels/second
Pattern Fill : 3514.758 Million pixels/second
Vertical Lines : 173.654 Million pixels/second
Horizontal Lines : 1342.758 Million pixels/second
Diagonal Lines : 69.059 Million pixels/second
Text Render : 853.040 Million pixels/second
-----------------------------------------------------------------------
Total : 1145.656 PM-Graphics-marks
Direct Interface to video extensions - DIVE
Video bus bandwidth : 1123.420 Megabytes/second
DIVE fun : 3834.609 fps normalised to 640x480x256
M->S, DD, 1.00:1 : 3831.759 fps normalised to 640x480x256
-----------------------------------------------------------------------
Total : 1432.589 DIVE-marks
2) new AN SNAP drivers
Graphics
BitBlt S->S copy : 12437.376 Million pixels/second
BitBlt M->S copy : 58.650 Million pixels/second
Filled Rectangle : 46704.301 Million pixels/second
Pattern Fill : 3507.515 Million pixels/second
Vertical Lines : 173.718 Million pixels/second
Horizontal Lines : 1267.768 Million pixels/second
Diagonal Lines : 57.530 Million pixels/second
Text Render : 859.766 Million pixels/second
-----------------------------------------------------------------------
Total : 1033.508 PM-Graphics-marks
Direct Interface to video extensions - DIVE
Video bus bandwidth : 223.803 Megabytes/second
DIVE fun : 763.788 fps normalised to 640x480x256
M->S, DD, 1.00:1 : 763.845 fps normalised to 640x480x256
-----------------------------------------------------------------------
Total : 285.501 DIVE-marks
In particular, the 'BitBlt M->S copy' and DIVE performance is severely down. In terms of application impact that is making my FF so slow that I can literaly see the page re-draw...OK, we are not talking here line at a time, but you can see the refresh whereas before it was lighting fast.
The drivers claim that write combining is enabled but in the GRAPHICS.LOG I see there is a failure report of some type, so there is something here that probably needs further review.
That's all for now. I would love to hear from anyone else who's using the AN SNAP drivers on their system and what you are seeing?
-
What is the error in graphics.log ?
-
Hi Roderick,
What is the error in graphics.log ?
Here is a quick snippet, but I've attached the full log to the post as well:
GA_enumerateDevices: Found 1 PCI/AGP display devices
Global options for all devices:
Force VBE Fallback ...... Off
Force VGA Fallback ...... Off
Allow non-certified ..... On
Disable write combining . Off
Use BIOS for LCD panel... Auto
Shared AGP memory size... 4096 KB
Use system memory driver. Off
Disable DDC detection.... Off
Virtual Display.......... Off
Loading driver for device 0 (radeon.drv)
---------------------------------------------------------
Partially mapped graphics memory: 0x08000000 instead of 0x10000000 bytes
You may not see all available memory due to memory mapping limitations
Attempting to enable write combining, base = 0xD0000000, length = 0x08000000 ... Success!
Attempting to disable caching for MMIO, base = 0xFE9F0000, length = 0x00004000 ...
Failed: UNKNOWN ERROR!
Loading chipset filters...done.
Loading splash screen...done.
Graphics device configuration:
Manufacturer......... ATI
Chipset.............. Radeon X850 Series
Bus Type............. PCI Express
Memory............... 131072 KB
DAC.................. ATI Internal 24 bit DAC
Clock................ ATI Internal Clock
Memory Clock......... 400 MHz
Default Memory Clock. 400 MHz
Maximum Memory Clock. 400 MHz
Driver Revision...... 3.2, Build 29
Driver Build......... May 2 2017
Certified Version.... Not Certified
Graphics device options:
Invert .................. Off
Rotation ................ Off
Flipped ................. Off
Prefer 16 bit per pixel.. On
Prefer 32 bit per pixel.. On
PCI bus mastering........ On
Hardware acceleration.... Full
-
...and here is the matching section from the IBM_SNAP driver initialization:
GA_enumerateDevices: Found 1 PCI/AGP display devices
Global options for all devices:
Force VBE Fallback ...... Off
Force VGA Fallback ...... Off
Allow non-certified ..... On
Disable write combining . Off
Use BIOS for LCD panel... Auto
Shared AGP memory size... 4096 KB
Use system memory driver. Off
Disable DDC detection.... Off
Virtual Display.......... Off
Loading driver for device 0 (radeon.drv.Sep.25.2006.13.01.08)
---------------------------------------------------------
Partially mapped graphics memory: 0x08000000 instead of 0x10000000 bytes
You may not see all available memory due to memory mapping limitations
Attempting to enable write combining, base = 0xD0000000, length = 0x08000000 ... Success!
Attempting to disable caching for MMIO, base = 0xFE9F0000, length = 0x00004000 ... Success!
Loading chipset filters...done.
Loading splash screen...done.
Graphics device configuration:
Manufacturer......... ATI
Chipset.............. Radeon X850 Series
Bus Type............. PCI Express
Memory............... 131072 KB
DAC.................. ATI Internal 24 bit DAC
Clock................ ATI Internal Clock
Memory Clock......... 400 MHz
Default Memory Clock. 400 MHz
Maximum Memory Clock. 400 MHz
Driver Revision...... 3.2, Build 29
Driver Build......... Sep 25 2006
Certified Version.... 1.60
Certified Date....... Sep 25 2006
Graphics device options:
Invert .................. Off
Rotation ................ Off
Flipped ................. Off
Prefer 16 bit per pixel.. On
Prefer 32 bit per pixel.. On
PCI bus mastering........ On
Hardware acceleration.... Full
-
Out of curiosity, I tested on my old T42 with ATI Mobility Radeon 7500 and Pentium M 1.6Ghz
eCS with Snap build for T42, Ver 2.3, build 419.
Graphics
BitBlt S->S copy : 204.195 Million pixels/second
BitBlt M->S copy : 30.545 Million pixels/second
Filled Rectangle : 927.106 Million pixels/second
Pattern Fill : 927.278 Million pixels/second
Vertical Lines : 12.047 Million pixels/second
Horizontal Lines : 451.019 Million pixels/second
Diagonal Lines : 14.393 Million pixels/second
Text Render : 242.816 Million pixels/second
---------------------------------------------------------------
Total : 133.654 PM-Graphics-marks
Direct Interface to video extensions - DIVE
Video bus bandwidth : 167.531 Megabytes/second
DIVE fun : 572.116 fps normalised to 640x480x256
M->S, DD, 1.00:1 : 571.994 fps normalised to 640x480x256
-----------------------------------------------------------------------
Total : 213.790 DIVE-marks
ArcaOS with Snap v3.19, build local (506)
Graphics
BitBlt S->S copy : 205.285 Million pixels/second
BitBlt M->S copy : 42.508 Million pixels/second
Filled Rectangle : 933.017 Million pixels/second
Pattern Fill : 931.745 Million pixels/second
Vertical Lines : 12.027 Million pixels/second
Horizontal Lines : 481.276 Million pixels/second
Diagonal Lines : 15.136 Million pixels/second
Text Render : 238.063 Million pixels/second
---------------------------------------------------------------
Total : 141.224 PM-Graphics-marks
Direct Interface to video extensions - DIVE
Video bus bandwidth : 166.894 Megabytes/second
DIVE fun : 569.617 fps normalised to 640x480x256
M->S, DD, 1.00:1 : 569.564 fps normalised to 640x480x256
-----------------------------------------------------------------------
Total : 212.895 DIVE-marks
For reference, ArcaOS with Panorama, 16 bit depth (others at 32 bit),
Graphics
BitBlt S->S copy : 69.600 Million pixels/second
BitBlt M->S copy : 70.938 Million pixels/second
Filled Rectangle : 145.558 Million pixels/second
Pattern Fill : 102.522 Million pixels/second
Vertical Lines : 10.434 Million pixels/second
Horizontal Lines : 27.892 Million pixels/second
Diagonal Lines : 1.011 Million pixels/second
Text Render : 42.929 Million pixels/second
---------------------------------------------------------------
Total : 31.340 PM-Graphics-marks
Direct Interface to video extensions - DIVE
Video bus bandwidth : 167.064 Megabytes/second
DIVE fun : 570.280 fps normalised to 640x480x256
M->S, DD, 1.00:1 : 570.440 fps normalised to 640x480x256
-----------------------------------------------------------------------
Total : 213.187 DIVE-marks
As you can see, the ArcaOS supplied Snap was slightly faster, though this was basically a virgin install. DIVE seems consistent, eve with Panorama.
I also accidentally ran the Snap test on ArcaOS at 16 bit depth, pretty well doubled the score excepting DIVE.
Graphics
BitBlt S->S copy : 536.218 Million pixels/second
BitBlt M->S copy : 81.518 Million pixels/second
Filled Rectangle : 2308.661 Million pixels/second
Pattern Fill : 2306.782 Million pixels/second
Vertical Lines : 24.461 Million pixels/second
Horizontal Lines : 948.665 Million pixels/second
Diagonal Lines : 18.745 Million pixels/second
Text Render : 242.202 Million pixels/second
---------------------------------------------------------------
Total : 265.277 PM-Graphics-marks
-
A little bit off topic but has anyone tried to use snap or panorama to drive a hdmi monitor?
Several video cards now have DVI-D and HDMI outputs and no VGA I was wondering if it was possible to have a hdmi monitor driven by one of those cards.
-
Hi Dariusz
Using an ATI X550 with the AN SNAP I see the same error in the graphics.log
Loading driver for device 0 (radeon.drv)
---------------------------------------------------------
Attempting to enable write combining, base = 0xD0000000, length = 0x08000000 ... Success!
Attempting to disable caching for MMIO, base = 0xFEA30000, length = 0x00004000 ...
Failed: UNKNOWN ERROR!
Loading chipset filters...done.
Loading splash screen...done.
Compared with the eCS SNAP 3.1.8 build 505 (log section pulled from an old backup) on eCS2.2beta2
Loading driver for device 0 (radeon.drv.Sep.25.2006.13.01.08)
---------------------------------------------------------
Attempting to enable write combining, base = 0xD0000000, length = 0x08000000 ... Success!
Attempting to disable caching for MMIO, base = 0xFEA30000, length = 0x00004000 ... Success!
Loading chipset filters...done.
Loading splash screen...done.
I can only guess that whatever has been changed within SNAP causes the error.
Just for fun I ran the sysbench tests:-
Graphics
BitBlt S->S copy : 430.345 Million pixels/second
BitBlt M->S copy : 305.949 Million pixels/second
Filled Rectangle : 7580.586 Million pixels/second
Pattern Fill : 1778.032 Million pixels/second
Vertical Lines : 56.506 Million pixels/second
Horizontal Lines : 223.633 Million pixels/second
Diagonal Lines : 51.134 Million pixels/second
Text Render : 602.398 Million pixels/second
-----------------------------------------------------------------------
Total : 402.639 PM-Graphics-marks
Direct Interface to video extensions - DIVE
Video bus bandwidth : 1175.934 Megabytes/second
DIVE fun : 4016.503 fps normalised to 640x480x256
M->S, DD, 1.00:1 : 4016.782 fps normalised to 640x480x256
-----------------------------------------------------------------------
Total : 1501.114 DIVE-marks
Not overly impressive - especially the PM-Graphics-marks
Sorry, I do not plan on installing the older SNAP with SMP problems to see what the differences are. ArcaOS with AN SNAP seems a little slower than eCS2.2beta2 with eCS SNAP *but* the AN SNAP has, so far, always booted to a working Desktop unlike previous versions of SNAP which are very prone to hanging when the Desktop is starting.
Regards
Pete
-
Looking further, I see I also get the same error about disabling caching for mmio with the ArcaOS supplied Snap, but not the older one. Though it doesn't seem to affect performance for me.
-
Yeah, I am not sure what the MMIO is about, but here at least there is a very real performance impact.
Sure, when comparing across different configurations what I am seeing in my 'slow' setup may not seen all that bad...however, the old IBM SNAP driver was pretty much able to keep up with my Win7Pro box which happens to have the very same Phenom II X6 cpu and ATI X850 XT PE video card in there (but in a different motherboard), so a fair comparison, and I for one was always impressed that my old OS/2 box was holding up to the Win stuff.
In my troubleshooting I did investigate the potential aspect of having 6 CPU cores enabled vs the old 5 core setup, this however had no impact on driver loading, same LOG entry, same performance results (+/- the CPU extra power contribution).
Anyways, I did log a ticket for the AN/SNAP folks, see => https://mantis.arcanoae.com/view.php?id=1505 (https://mantis.arcanoae.com/view.php?id=1505), the Mantis system appears to be down at the moment (I can not reach it) but I do not suspect they will be able to look at this anytime soon, I think Rich is busy on some type of dynamic resolution changing process (I do not know this first-hand, just picking up the stuff from the "ether"...LOL).
Alright, thanks for the feedback you guys. The next step on my search for the "Holy Grail" was to re-try the dual-head configuration. The AN SNAP drivers though still are running into the same problem as the IBM ones, which is declaring the monitor EDID to be broken, subsequently, as best as I can tell only the 'Head 0' drivers get loaded. This will have to wait.
ivan,
My Samsung 245T panel has HDMI connection on it, but I have not tried it. Will give it a go tomorrow and report-out. As it happens, playing with the SNAP drivers hasn't been the most fun event, I did manage to mess up my INI files badly enough that I needed to recover from a backup to get back to a working PMMAIL, FIREFOX and PSI install. Not sure what it was, however, PSI would produce a trap entry showing a SYS3175 in REGISTRY.DLL.
Ah, one more thing, given that we are speaking of other video driver/hardware related stuff: who has a working dual-head configuration? What are you using, can you post your GRAPHICS.LOG contents?
I am asking this last question because the SNAP readme clearly states that even the ATI hardware will only support DVI for a single display and anything else needs to use RGB. Indeed, my ATI card has two DVI connectors, I ran DVI to my primary but used a DVI=>RGB adapter to my secondary. I did end up seeing the following in my GRAPHICS.LOG file, however the 'head 1' panel never produced anything on-screen.
Configuration for head 0:
Monitor configuration:
Manufacturer... Samsung
Model.......... SyncMaster
Max Resolution. 1920x1440
Max HScan...... 81 KHz
Max VScan...... 75 Hz
Features....... DPMS Wide
LCD panel detected:
Width: 1920
Height: 1200
Graphics mode information (DFP):
...and the matching entry for head 1:
Configuration for head 1:
Monitor configuration:
Manufacturer... Samsung
Model.......... SyncMaster
Max Resolution. 1920x1440
Max HScan...... 81 KHz
Max VScan...... 75 Hz
Features....... DPMS Wide
Graphics mode information (CRT):
-
A little bit off topic but has anyone tried to use snap or panorama to drive a hdmi monitor?
Several video cards now have DVI-D and HDMI outputs and no VGA I was wondering if it was possible to have a hdmi monitor driven by one of those cards.
I have a monitor that uses a DVI to HDMI converter cable, using an old Dell X600PRO card via DVI output and Snap 3.18.
Panorama should work with the HDMI output if the VESA BIOS on the card or motherboard supports it, most should.
-
A little bit off topic but has anyone tried to use snap or panorama to drive a hdmi monitor?
Several video cards now have DVI-D and HDMI outputs and no VGA I was wondering if it was possible to have a hdmi monitor driven by one of those cards.
I have a monitor that uses a DVI to HDMI converter cable, using an old Dell X600PRO card via DVI output and Snap 3.18.
Panorama should work with the HDMI output if the VESA BIOS on the card or motherboard supports it, most should.
I was going to post this. It depends on the computer (or graphics card) BIOS.
Also, if you have already thrown your HDMI in the trash to use DisplayPort, then that works on my Lenovo M93p tiny with eComStation and Panorama graphics.
-
Hi Dariusz
Where is sysbench 0.9.5d available? - I only see 0.9.5c on http://www.os2warp.org/Sysbench/
Regards
Pete
-
Hey Pete!
...Where is sysbench 0.9.5d available? - I only see 0.9.5c on http://www.os2warp.org/Sysbench/...
Hmm...good question...I remember working with Trevor a few years back on some fixes, may have had something to do with either my HPFS386 fs, or maybe it was CPU speed related, so I'm thinking it may have been a test release version? Although I thought he did eventually make that available...I could have sworn I've see it out in the "wild"...LOL!
I looked for the ZIP on my system (in case I saved it) but I did not find it. I can ceratinly ZIP-up the contents of the directory and send it your way...I do not think there was a specific install program...
-
Hi
I have no records of sysbench 0.9.5d on the OS2World news archive, last one I have news from was 0.9.5c on May 2008 . If someone has it please upload it to hobbes.
Regards
-
SYSBENCH095D:
http://www.os2warp.org/sysbench/sysb095d.zip
-
Looking at the DIVE results, is there something wrong with the measurement? I measured the M93p tiny
Direct Interface to video extensions - DIVE
Video bus bandwidth : 7282.561 Megabytes/second
DIVE fun : 27175.091 fps normalised to 640x480x256
M->S, DD, 1.00:1 : 25132.707 fps normalised to 640x480x256
-----------------------------------------------------------------------
Total : 9516.640 DIVE-marks
Is it really that much faster than an accelerated ATI card?
-
Probably, here I get the same DIVE speed with Panorama and accelerated Snap, so I guess it is just memory speed.
-
Probably, here I get the same DIVE speed with Panorama and accelerated Snap, so I guess it is just memory speed.
...I did a whole wack more testing, consistently though I found that even though the graphics.log entries claim that write combining is turned on the performance tells a different story.
So just to be sure I disabled write combine with "gaoptions", re-booted, re-ran the test. The Sysbench results are the same, so on my system at least there is no difference...and that implies that whatever the drivers think they are doing to successfully enable write combining, it is not actually getting done.
Here is something else to consider, I am having a hell of a time with the CONFIG.SYS VIRTUALADDRESSLIMIT entry. Previously with the SciTech drivers I used to run VIRTUALADDRESSLIMIT=3072, with this same setting I can not boot to a workable system, meaning, I continue to get the following error message whenever I attempt to start most of my programs:
LIBC Error: Couldn't register process in shared memory!
In particular, my networking is down entirely, like it doesn't even start up, "ping" goes nowhere, etc, etc.
Lowering the value to VIRTUALADDRESSLIMIT=2048 finally resulting in a working system. Now the graphics.log actually shows the full 256MB of video card ram, previously it only recognizes 128MB and complains that all of memory may not be available.
I'm curious, what are you guys setting your VIRTUALADDRESSLIMIT to?
-
Hey Neil!
Looking at the DIVE results, is there something wrong with the measurement? I measured the M93p tiny
Direct Interface to video extensions - DIVE
Video bus bandwidth : 7282.561 Megabytes/second
DIVE fun : 27175.091 fps normalised to 640x480x256
M->S, DD, 1.00:1 : 25132.707 fps normalised to 640x480x256
-----------------------------------------------------------------------
Total : 9516.640 DIVE-marks
Is it really that much faster than an accelerated ATI card?
OMG!!!...seriously, those M->S values are "to die for"...that's smoking fast, what are the non-DIVE test results?
My big complaint is that with such poor M->S values, on my 1920x1200 display I am literally seeing the Firefox (as well as other apps) frame window draw first and I can actually catch the inside of the window being drawn...sure it goes by fast, but the fact that I can actually preceive it is very distracting...so can not be faster then 1/30 secs. given typical human visual perception.
The old SciTech drives produced instant udpates, in my cases, the matching M->S scores were nearly 5-6x faster.
Neil, what video hardware are you running? Maybe it is time for me to drop my trusty ATI X850 XT PE card and move on? LOL
-
I'm curious, what are you guys setting your VIRTUALADDRESSLIMIT to?
While under eCS 2.x, I always used 3072, I found that made ArcaOS unstable. Using 2816 the OS is stable but both SeaMonkey and Thunderbird are very crashy, often just vanishing, sometimes writing a trp file with the crashes in the JavaScript engine, rather allocating memory or doing garbage collection. I'm going to decrease it to 2560 and keep decreasing by 0x100H perhaps to your 2048.
Today I decided to reboot to eCS 2.1, where the VIRTUALADDRESSLIMIT is still set to 3072 and SeaMonkey and Thunderbird have been stable.
The main difference seems to be the kernel, so I guess I'll also try downgrading the kernel later.
-
To Neil:
Direct Interface to video extensions - DIVE
Video bus bandwidth : 7282.561 Megabytes/second
Is it really that much faster than an accelerated ATI card?
This VBB value is typical for latest Intel built-in video with a proper set of caching mode for LFB.
We need somebody with such processor and ATI card to know what is faster (I am curios too).
And it will be necessary to test this issue on real applications not only Sysbench. I am using SNAP with ATI x850 and when I switch my comp to Panorama for tests, I recognize dramatic decreasing of scrolling speed (for example, any help file in NewView). Probably, on latest Intel built-in video, such decrease will not happen.
To Dariusz:
LIBC Error: Couldn't register process in shared memory!
I'm curious, what are you guys setting your VIRTUALADDRESSLIMIT to?
Pre Arca SNAP has a bad habit - it is mapping ALL memory available on a video card into address space (if I am not wrong, even twice).
It looks absolutely senseless - just a waste of address space.
Fortunately, there is a way to "fix" this. "gaoption vidmem 8" reduces size of mem to be mapped by SNAP to 8M (it is sufficient for 1280x1024x16M)
I always use VIRTUALADDRESSLIMIT = 3072 (/CACHE:262144 for JFS.IFS)
-
I'm curious, what are you guys setting your VIRTUALADDRESSLIMIT to?
I have been using 2560, but 3072 seems to work just as well. With less than 2560 (2048), I start to run out of shared memory space, after a couple of days. I do use the CLAMD.EXE, supplied by RPM/YUM, from netlabs-rel, and it uses close to 1 GB of upper shared memory space. Not using ClamD.EXE doesn't change anything, except I can use a smaller number for VIRTUALADDRESSLIMIT.
LIBC Error: Couldn't register process in shared memory!
This error seems to have nothing to do with VIRTUALADDRESSLIMIT. It happens when I load DLLs high (I can't even run my system, if I don't do that with AOO, and FF). Take either one of those programs, open, and close, any combination, twice, and I start to get that message with anything that uses LIBC. Other things keep on working properly, but it takes a re-boot to get the problem solved (temporarily).
FWIW, I use the Quick Start feature with AOO, and that helps because it keeps the DLLs loaded, rather than unloading them, witch causes the problem. Firefox is another story. It will either crash, or I need to close it, at least once per day, so the longest that I can go, without a re-boot for the LIBC problem, is 2 days.
FWIW, I had to quit using eCS, because simply closing a program, with DLLs loaded high, would crash the system, about every second try, and trying to run AOO, and FF, at the same time, using DLLs loaded low, was impossible. At least the new ArcaOS kernel doesn't crash the system, when the problem happens.
-
Hi All
Looking in my config.sys I see the ArcaOS installation set VIRTUALADDRESSLIMIT=1536 which seems to work fine here - however, I do not leave Seamonkey running when I am not using it and I never use the AOO QuickStart feature.
On my eCS2.1 and 2.2b2 installations on the same hardware I see that I have VIRTUALADDRESSLIMIT=3072. I think it may be something to do with the AOO Draw app - will have to test how that works in ArcaOS.
Regards
Pete
-
Hey OS4User,
To Dariusz:
LIBC Error: Couldn't register process in shared memory!
I'm curious, what are you guys setting your VIRTUALADDRESSLIMIT to?
Pre Arca SNAP has a bad habit - it is mapping ALL memory available on a video card into address space (if I am not wrong, even twice).
It looks absolutely senseless - just a waste of address space.
Fortunately, there is a way to "fix" this. "gaoption vidmem 8" reduces size of mem to be mapped by SNAP to 8M (it is sufficient for 1280x1024x16M)
I always use VIRTUALADDRESSLIMIT = 3072 (/CACHE:262144 for JFS.IFS)
Alright, happy to give this a go, let me explain my calculation, hopefully no mistakes:
So (for your 1280x1024 resolution):
1) 1280x1024 = 1310720 pixels
2) 16M colours means 32bit colour depth, that's 4 bytes/pixel
3) 1310720 pixels * 4 bytes/pixel = 5242880 bytes, which is approx 5 MB
If you assume 24bit colour depth, thus 3 bytes/pixel, the above result changes to 4 MB, am I understanding this correctly?
If yes, than the appropriate sizing for my 1920x1200 @ 32bit colour depth is:
1) 1920x1200 = 2304000 pixles
2) 32 bit colour depth, that's 4 bytes/pixel
3) 2304000 pixels * 4 bytes/pixel = 9216000 bytes, which is approx 9 MB
Since I ultimately want to have this setup as a dual-head display I will double up the 9MB allocation and give it a little extra 'room'...therefore, the required SNAP command is: 'gaoption vidmem 24', which is what I executed...so let's see what a re-boot brings??? lol
-
Hey Doug!
I'm curious, what are you guys setting your VIRTUALADDRESSLIMIT to?
I have been using 2560, but 3072 seems to work just as well. With less than 2560 (2048), I start to run out of shared memory space, after a couple of days. I do use the CLAMD.EXE, supplied by RPM/YUM, from netlabs-rel, and it uses close to 1 GB of upper shared memory space. Not using ClamD.EXE doesn't change anything, except I can use a smaller number for VIRTUALADDRESSLIMIT...
Yeah, similar to how I got to my 3072 setting. I used to run FF full-time, multiple windows, multiple tabs...and I never shut down my machine, up 24x7, or at least as long as OS/2 itself is willing to stay up and running. I found that the higher I cranked this value up the more stable the system would be.
LIBC Error: Couldn't register process in shared memory!
...This error seems to have nothing to do with VIRTUALADDRESSLIMIT. It happens when I load DLLs high (I can't even run my system, if I don't do that with AOO, and FF). Take either one of those programs, open, and close, any combination, twice, and I start to get that message with anything that uses LIBC. Other things keep on working properly, but it takes a re-boot to get the problem solved (temporarily).
FWIW, I use the Quick Start feature with AOO, and that helps because it keeps the DLLs loaded, rather than unloading them, witch causes the problem....
My only experience with the impact this value has had is due to AN SNAP driver change. I can absolutely confirm that the only way for me to get a working environment (other than WPS coming up fine and some (most?) of the core OS/2 stuff working) is to lower this value. Subsequently, for now, the only way I can have a working system is by setting this to 2048.
Worth noting is the following:
1) I run HPFS386 with a 64M cache
2) my ATI X850 XT card comes equipped with 256M ram, which apparently is causing the drivers to consume that much of the actual system memory - making the change to limit this to 24M, re-boot coming up next
3) AOO Quick Start feature is executed upon start-up
4) I have about 19 apps in my XWP start-up folder, most of these are utility type things, such as: CPUMonitor, lSwitcher, dSync, Win 95 Key, SetTime, Xit, CAD-Popup, UPS Monitor, DskMon, Web/2, PSI, Privoxy, etc
Not sure if that makes for a 'heavy load' on a system, but I would hope not since most of these are small memory foot-print type apps.
-
There's
SET SNAP_MAXVRAM_32MB=Y
in my config.sys. Pretty sure the SNAP documentation explains this.
-
There's
SET SNAP_MAXVRAM_32MB=Y
in my config.sys. Pretty sure the SNAP documentation explains this.
according to SNAP documentation SET SNAP_MAXVRAM_32MB=Y is not the same with "gaoption vidmem 32"
what is mentioned in your C:\OS2\DRIVERS\SNAP\CONFIG\GRAPHICS\graphics.log ?
-
Andi,
There's
SET SNAP_MAXVRAM_32MB=Y
in my config.sys. Pretty sure the SNAP documentation explains this.
...but as OS4User pointed out, and I agree, I think these two ways of controlling the video memory allocation are different.
I did both, the result is that I see the following in graphics.log:
Video memory limited to user supplied value of 32MB
Attempting to enable write combining, base = 0xD0000000, length = 0x02000000 ... Success!
Attempting to disable caching for MMIO, base = 0xFE9F0000, length = 0x00004000 ...
Failed: UNKNOWN ERROR!
Loading chipset filters...done.
Loading splash screen...done.
The Screen dialog now only shows 32Meg as the total memory for the video card, and CLI 'gaoption show' gives this:
Global options for all devices:
Force VBE Fallback ...... Off
Force VGA Fallback ...... Off
Allow non-certified ..... On
Disable write combining . Off
Use BIOS for LCD panel... Auto
Video Memory Limit....... 32 Mb
Shared AGP memory size... 4096 Kb
Use system memory driver. Off
Disable DDC detection.... Off
Enable AGP FastWrite..... Off
Maximum AGP data rate.... 8X
Virtual Display.......... Off
Bottom line here is that:
1) I can successfully boot with VIRTUALADDRESSLIMIT = 3072
2) ...but that made me greedy, because I miss my bigger HPFS386 cache, so I went back to playing with the sizing and was able to increase the cache size from 64M to 128M however I needed to drop to VIRTUALADDRESSLIMIT=2048 to make that happen
At this point in time I think I got the hang of the SNAP driver's memory allocation scheme and how it impacts the remainder of the system memory.
-
I did both, the result is that I see the following in graphics.log:
from snapos2.pdf:
SET SNAP_MAXVRAM_32MB=Y
...
Alternatively, you can use the gaoption “vidmem” option to not only limit the amount
of video memory reported, but also the amount mapped into the physical memory space.
Here is the mistake - it has to be written into the virtual memory space but not into physical memory space, but the rest looks like true.
Indirect confirmation is in your log :
Attempting to enable write combining, base = 0xD0000000, length = 0x02000000 ... Success!
So the set of LFB aperture is indeed 0x02000000 bytes = 32M.
I believe you will have the same even without SET SNAP_MAXVRAM_32MB=Y, but with “vidmem” only.
2) ...but that made me greedy, because I miss my bigger HPFS386 cache
You can use Theseus to analyze free System Memory to set HPFS386 cache as big as possible.
(System->Kernel Information->System Object Summary)
I have about 180M free system memory after system booted - it looks sufficient.