Author Topic: SNAP drivers and video speed - IBM vs AN release differences...  (Read 2223 times)

Neil Waldhauer

  • Sr. Member
  • ****
  • Thank You
  • -Given: 6
  • -Receive: 17
  • Posts: 303
    • View Profile
    • Blonde Guy
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #15 on: October 28, 2017, 03:30:49 pm »
Looking at the DIVE results, is there something wrong with the measurement? I measured the M93p tiny

Code: [Select]
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?
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 91
  • Posts: 1176
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #16 on: October 28, 2017, 06:23:39 pm »
Probably, here I get the same DIVE speed with Panorama and accelerated Snap, so I guess it is just memory speed.

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 12
  • -Receive: 7
  • Posts: 307
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #17 on: October 29, 2017, 02:44:19 am »
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?


Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 12
  • -Receive: 7
  • Posts: 307
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #18 on: October 29, 2017, 02:49:33 am »
Hey Neil!

Looking at the DIVE results, is there something wrong with the measurement? I measured the M93p tiny

Code: [Select]
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

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 91
  • Posts: 1176
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #19 on: October 29, 2017, 03:10:38 am »
Quote
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.

OS4User

  • Full Member
  • ***
  • Thank You
  • -Given: 5
  • -Receive: 4
  • Posts: 123
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #20 on: October 29, 2017, 07:38:38 am »
To Neil:


Code: [Select]
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)

Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 38
  • Posts: 938
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #21 on: October 29, 2017, 07:45:36 am »
Quote
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.

Quote
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.

Pete

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 27
  • Posts: 548
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #22 on: October 29, 2017, 04:10:21 pm »
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

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 12
  • -Receive: 7
  • Posts: 307
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #23 on: October 29, 2017, 05:04:56 pm »
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

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 12
  • -Receive: 7
  • Posts: 307
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #24 on: October 29, 2017, 05:15:32 pm »
Hey Doug!

Quote
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.

Quote
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.

Andi B.

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 12
  • Posts: 323
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #25 on: October 29, 2017, 05:52:54 pm »
There's
Code: [Select]
SET SNAP_MAXVRAM_32MB=Y
in my config.sys. Pretty sure the SNAP documentation explains this.

OS4User

  • Full Member
  • ***
  • Thank You
  • -Given: 5
  • -Receive: 4
  • Posts: 123
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #26 on: October 29, 2017, 06:17:33 pm »
There's
Code: [Select]
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 ?

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 12
  • -Receive: 7
  • Posts: 307
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #27 on: October 30, 2017, 01:55:08 am »
Andi,

There's
Code: [Select]
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.


OS4User

  • Full Member
  • ***
  • Thank You
  • -Given: 5
  • -Receive: 4
  • Posts: 123
    • View Profile
Re: SNAP drivers and video speed - IBM vs AN release differences...
« Reply #28 on: October 30, 2017, 07:47:01 am »
I did both, the result is that I see the following in graphics.log:

from snapos2.pdf:
Code: [Select]
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 :
Code: [Select]
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.