problems with GeForce 7300 GT

[HaikuBot]

Can't boot haiku on my PC without safe-mode option "use fail-safe video mode". I can't run a resolution of 1680x1050 on my PC and so I'm using Vesa instead.

Graphic Card - PCI-E MSI GeForce 7300 GT 256Mb.

"listdev" and "syslog" in attachments.

[rudolfc]

Hi,

Could you grab the file nvidia.settings from the source (nvidia kernel driver) and place that in your home folder, and disable the acceleration engine?

If you do that and reboot without using failsafe video, the driver will attempt to run without using hardware acceleration for the desktop. Does that work?

Bye! Rudolf.

[HaikuBot]

Hello.

I put it in home directory and disabled acceleration. Unfortunately, does not work, says same as before "No signal" then "Input not supported".

[rudolfc]

Can you enable 'full logging' in the nvidia.settings file, reboot, grab the resulting driver logfile from your home folder and upload it here?

(the file remains intact if you are able to blindly fall back to KDL and type 'reboot'. If you then use failsafe video mode you should find the logfile from the previous boot.

Thanks in advance!

Rudolf.

[HaikuBot]

log file

[HaikuBot]

I hope it helped you.

[rudolfc]

Good morning :-) Good you posted that last thing, I did not get notified of the added logfile by itself.

Anyhow: you have a widescreen panel 1680x1050 on head2, and a VGA screen on head1 according to the log. The mode you are actually setting when starting Haiku is 1280x1024 in 32bit color.

The log seems OK. During this bootup, you did not disable the acceleration engine BTW.

A few questions:

• do you have indeed two screens connected?
• if you specify failsafe mode, do you also specify 1280x1024? or is this the default resolution that will be used then?
• if you don't specify failsafe mode: do you see the icons screen or does the monitor shut-off in the beginning of that bootup-phase?

Things you can try:

• modify the settings file for the next items (one by one)

pgm_panel true (could help) and after a next failed boot maybe try: switchhead true (not likely the problem)

-does your digital screen have a VGA connector? try using it via that connector. You could try both connectors on the gfx card: the VGA one and the DVI one using a DVI to VGA adaptor. Would it work then?

Bye!

Rudolf.

[HaikuBot]

Greeting again :) I have good news.

With "pgm_panel true" and "switchhead false" doesn`t work. But when i try boot with "true" for both variable, Haiku booted sucessfull.

Thanks for help. Close ticket, please.

Good Luck.

[stippi]

I would keep the ticket open until the driver doesn't need tweaking via the settings like this. IMHO, it should work out of the box.

[rudolfc]

Hi again HaikuBot,

I have some questions left, can you help out please? Can you delete the driver's logfile and reboot with the working settings? Please upload the logfile resulting from that so I get a bit more info about what's going on...

And please answer these questions: -How many monitors are connected? just one, or two? (connect each monitor using just one cable please)

• are you using a DVI cable or a VGA cable for the monitor(s)?

Thanks! (good to hear you have a picture BTW :-)

@ Stippi:

Hi Stephan!

In theory you are right of course. But in practice this is unreachable. There will always be systems that won't run Haiku: whatever the reason. Anyhow, let's leave this ticket open for now awaiting at least a better understanding of what's going on. Once that's known, and the driver has been updated for the best results possible, it needs to be enough. Even though not every system out there might work out of the box..

example:

the Kernel VESA call is not always succesfull. I've seen cards that don't work in VESA mode though they say they should... Solution: a manual tweak (select lower resolution) is nessesary to bootup the system succesfully. I don't think we can have a full list of all cards in the world, combined with all possible BIOS versions, combined with all monitors to see if we need to fallback to a lower mode because it's known that a certain combination won't work as it should.. :-/

Bye!

Rudolf.

[HaikuBot]

I think hurried with my conclusions.

It works when display connected or via VGA cable or via DVI, but when connected both cabels, Haiku does't boot.

Also when connected via DVI list of resolutions in Screen-preflet is correct (for widescreen monitor), but when connected via VGA screen in resolutions list do not contains values for widescreen monitor.

And one more thing:

"~> ls /dev/graphics/ 
10de_0393_010000  vesa"

I think there must be "nv" instead of "vesa" if suppose driver works.

But one pleases now I can use 1680x1050. :)

Replying to rudolfc:

• if you specify failsafe mode, do you also specify 1280x1024? or is this the default resolution that will be used then?

Yes, I specify 1280x1024, by default it 1024x768.

• if you don't specify failsafe mode: do you see the icons screen or does the monitor shut-off in the beginning of that bootup-phase?

Yes, i see all boot icons, monitor is shutting down after last icon (rocket).

Replying to rudolfc:

I have some questions left, can you help out please? Can you delete the driver's logfile and reboot with the working settings? Please upload the logfile resulting from that so I get a bit more info about what's going on...

As you can read above, I maked wrong conclusions, it works in VESA.

-How many monitors are connected? just one, or two? (connect each monitor using just one cable please)

One monitor, 22 inches.

• are you using a DVI cable or a VGA cable for the monitor(s)?

Both.

P.S: sorry for my bad english.

[anevilyak]

Replying to HaikuBot:

And one more thing:

"~> ls /dev/graphics/ 
10de_0393_010000  vesa"

I think there must be "nv" instead of "vesa" if suppose driver works.

No, "vesa" is always there. 10de_0393_010000 is the node published by the nvidia driver (10de is nvidia's PCI vendor ID, 0393 is your card ID). So it is indeed the nvidia driver being used here.

[HaikuBot]

Replying to rudolfc:

During this bootup, you did not disable the acceleration engine BTW.

I too was surprised when looked log. But in "nvidia.settings" file, acceleration engine is disable (it comment-out).

Replying to anevilyak:

No, "vesa" is always there. 10de_0393_010000 is the node published by the nvidia driver (10de is nvidia's PCI vendor ID, 0393 is your card ID). So it is indeed the nvidia driver being used here.

But why there no logs in home dir? (in nvidia.settings full-logging is turned on )

[anevilyak]

Replying to HaikuBot:

But why there no logs in home dir? (in nvidia.settings full-logging is turned on )

Where are you putting nvidia.settings? It should be in ~/config/settings/kernel/drivers/

[rudolfc]

Hi,

Thanks for the update. Another question please: Did you tweak the driver's sourcecode by any chance?

I don't have an explanation why I see switchhead set to true in the new logfile while the corresponding activating logline is missing!

This shouldn't happen...

Other things I see:

• the acceleration engine is apparantly working OK, as you did not disable it.
• On this boot only the DVI cable was connected. Thanks.

About the switchhead parameter: As I don't see the driver responding to this parameter, I'd say you can disable the parameter again. Would you test that for me please to be sure it indeed has no influence?

Thanks.

@ Stephan: Stephan, could we have a compiling problem here with variable sizes in shared info or something??

Bye!

Rudolf.

[rudolfc]

HaikuBot:

Another strange thing: apparantly the driver does not export the acceleration hooks, or exports them without mentioning. Either case is impossible if the driver has been compiled correctly.

So did you tweak the driver? I am very curious... If you did, please delete it and re-checkout the correct source, recompile, and redo the test...

Otherwise I can't draw any valid conclusions I'm afraid.

Thanks in advance for any info you might have!

Bye!

Rudolf.

[rudolfc]

Stephan,

Can you tell me if you disabled the use of the acceleration engine in the app_server? I now see the same thing in my own logs: acceleration engine hook messages aren't written.

Please tell me what's going on: I am unable to further test the acceleration engine if you disabled the use of it. If you did: since when did you disable it, and when will you re-enable it again?

Thanks for any info you might have..

Rudolf.

[anevilyak]

Hi Rudolf,

That was disabled in hrev30278, with accompanying explanation.

[HaikuBot]

Sorry, it was my fail, in previos log with "switchhead 1", I inadvertently left first line from old log (when deleting entries from old sessions). Here new one clean log. And not, im did not tweak drivers source, my knowledges in writing drivers field negligible.

[rudolfc]

Hi again,

@ anevilyak: Hmm, I was already beginning to suspect that. Back then I read the doublebuffereing was gone, but I did not think he'd actually disable accelerated drawing!

I'm curious if that won't create scrolling and moving difficulties on AGP or even old-style PCI cards. I'll test that I think. If it works smoothly, then I'm impressed by the app_server software drawing code and/or whatever combination is responsible.

My personal setup with not use this doublebuffering (that's dead slow if no acceleration is available for one thing). But I would without any doubt use hardware accelerated drawing! This is the reason it never came to me stephan disabled accelerated drawing along with the doublebuffering..

I'm still curious if we get accelerated drawing back or not BTW!

@ Haikubot:

Thanks for the new log and explanation. The log looks normal now we know accelerated drawing isn't performed by the app_server anymore, combined with your explanation.

So, you can now use the driver without any tweak? Do I get that right? If so, the only remaining thing might be the acc engine if it were actually used by the app_server. Though I am under the impression that it only fails on G72, so not your G73.

Please tell me if you still use tweaks?

Bye!

Rudolf.

[stippi]

Hi Rudolf,

there are several things which led me to disable the acceleration engine:

• On my two computers which have native drivers, Haiku worked much smoother when acceleration was disabled. Haiku uses a lot more blending operations than BeOS did. So it needs to read the frame buffer a lot more. This is insanely slow. Using a frame shadow buffer in main memory and performing write operations on the frame buffer only is much faster.

• I do not really want to go back to the 90ish style user interface look and use no gradients and thereby less B_OP_OVER for text rendering for example.

• When dragging icons or dragging the selection rect in Tracker, it performs alpha blending. It flickers in BeOS when stuff redraws underneath, not in Haiku.

• When repainting windows, Haiku uses double buffering, which means a whole lot less flickering in all sorts of situations, especially when repainting.

• I cannot believe that when something feels slower on a fast computer, that it doesn't also feel slower on a slow computer. For the way in which the Haiku app_server currently works, using acceleration made it feel slower. It may be a problem of how it uses the acceleration, but I have no time or motivation to investigate. And blending will still feel slower.

• I don't like the BeOS accelerant API. It is totally inflexible. Instead of performing commands with frame buffer coordinates, it should instead allow me to specify frame buffer (and offscreen!) memory addresses.

• Eventually, the app_server should use 3D acceleration to do window compositing and use a lot less CPU, because there wouldn't be anymore redraws because of exposing previously covered up window regions.

• This task is way too big for me to tackle right now. On all my computers, Haiku feels reasonably fast without any acceleration, including one pretty slowish computer. I see much more pressing needs in Haiku, like MediaKit encoding and the like.

• If you want to figure out what I am doing wrong in the Haiku app_server which triggers weird lock ups of the NVidea driver when acceleration is used, please help analyze the app_server code. It is all pretty well written and should be easy to follow. There are only very few classes involved with repainting. It's DrawingEngine, HWInterface and AccelerantHWInterface. One needs to know that there is one DrawingEngine per Window, and one global AccelerantHWInterface instance. So there might be issues with locking when using acceleration. It does use locking, but it may use the wrong kind. I have no idea.

I hope you have a better understanding now of why I think I did the right thing for the time being.

[rudolfc]

Hi Stephan

Thanks for your response/clarification. I'll test Haiku on a PCI card to see what happens when moving windows around or scrolling. About these lockups: What gfx cards do you have there from nVidia? Do you have cardID's or at least Gxx number or something?

A question: If I setup a function in the acc engine that fetches a chunck of main memory and copies it in the card memory, would that make you use acc again? (I am curious if I can speedup overlay this way for instance.. ;-)

I guess you also want the other way around: a chunk of gfx mem back to main mem..

Would these two functions combined with the current acc functions be enough? Would you say the current functions can be deleted from the drivers? (Even without knowledge of the inner workings of the app_server: I can hardly believe that the current blit and fill function are useless...(!). I mean if I scroll down in a text you can use that right? And when I move a window: the same? If not, why not?)

BTW Currently I am in the process of changing providers, so my mail is very uncertain atm. Once that's completed, we could take this subject to regular mail. Would that be better?

Bye!

Rudolf.

[HaikuBot]

Replying to rudolfc:

So, you can now use the driver without any tweak? Do I get that right?

Yep, when connected via DVI only.

[axeld]

Stippi, about acceleration in general on older systems: unlike new systems, they have, in today's standards, an insanely limited memory bandwidth. So many things, most notably moving windows around, or scrolling, can still be done a lot faster using the hardware acceleration than you could do via software.

This is where we might want to improve our acceleration usage (if possible) - this will definitely be faster on "slow" machines. The other stuff isn't so bad when ignored.

[rudolfc]

Hi guys,

Haikubot, And what if you connect your monitor _only_ with the VGA cable (so disconnect the DVI cable): would it work without a tweak then as well?

Hi Axel,Stephan,

Do we have a small (command line) tool to measure the RAM read/write access bandwidth for graphicscards? I remember a tool that did 8/16/32 bit transfers to measure the speed if I am correct. (Write combining had different optimation results for different size accesses)

I also remember that on AGP this is very limited (for the CPU accessing gfx ram): writing was faster than reading due to the fastwrites feature AGP supports. In effect, reading went at PCI bus speed (133Mb/sec). Writing was in practice around 4 times faster with FW support I think?

I also remember that on my first PCIe cards using this tool the write speed was lower, and the read speed was still around 133Mb/sec (I think I tested both a GF6600 and a 4300 or so: the latter was an AGP card with PCIe bridge onboard). Probably some settings weren't enabled by default ('legacy PCIe mode') and reading could be slow because the GPU's weren't designed to give you access to their RAM fast. They were designed to do these things fast if done by the GPU - not the CPU.

I would like to test with my current system to get an estimate on this. In other words: are the current systems indeed much faster accessible on Haiku or is it still a slow connection?

Bye!

Rudolf.

[rudolfc]

Info update:

Since R30783 acceleration with the nvidia driver using G72 cards (Geforce 7300, 7400 and 7500) is fixed. Testable with old Haiku versions: pre- R30278.

Bye!

Rudolf.

[rudolfc]

Hi,

I could locate the old benchmark tool I have here, fortunately it works on Haiku as well. I tested with a G72 (GF7300) on my system: (FSB probably 1066Mhz) This is a PCIe V2 system. Don't know the busrevision a G72 has btw.

~/rudolf> GfxBusBench-0.7 --allsizes GfxBusBench 0.7 CPU: Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz, Clock: 2.67 GHz, FSB: 0 MHz. Screenmode: 800x600x32, framebuffer address: 0x90000800

Write 64-bit: 1315.46 MB/s (3955.08 MB in 3.01 s) Write 32-bit: 1319.26 MB/s (3991.70 MB in 3.03 s) Write 8-bit: 1308.87 MB/s (3955.08 MB in 3.02 s) Read 64-bit: 5.66 MB/s (18.31 MB in 3.24 s) Read 32-bit: 4.41 MB/s (14.65 MB in 3.32 s) Read 8-bit: 1.11 MB/s (5.49 MB in 4.97 s)

On my old P4-2800 with AGP at 4x and FW enabled: write 64/32/8 bit: 670Mb/sec read 64: 10Mb /sec read 32: 5Mb/sec read 8: 1.25Mb/sec.

I remember on my old PCIe system (V1 bus) with my GF6600 that writing was much slower than with AGP+Fw.

Anyhow, reading is the real problem, and must always be done with 64bit reads for 'optimum performance'.

The measuring tool was written by: GfxBusBench 0.7 © 2005 by Christian Packmann <Christian.Packmann@…>

Unfortunately I don't have the sources as I would love such a tool in Haiku by default!!

Bye!

Rudolf.

[HaikuBot]

Hello. Sorry for long respond. I tested Haiku with acceleration and without (with DVI only and VGA only cables), it works fine.

[pacman]

Replying to axeld:

Stippi, about acceleration in general on older systems: unlike new systems, they have, in today's standards, an insanely limited memory bandwidth. So many things, most notably moving windows around, or scrolling, can still be done a lot faster using the hardware acceleration than you could do via software.

This is only generally true for PCI cards, which will often be limited to 40-60 MB/s write speed or less. On very bad motherboards this may drop to 20 MB/s or so, if the PCI implementation is buggy.

On AGP cards, you generally get 200+ MB/s write speed unless AGP is improperly configured. With write combining and fast writes, 200 MB/s is pretty much the lower bound (but 130MB/s has been observed on one of Rudolfs systems, a TNT-1/AGPx1 on Intel 400 BX). These low values only happen on cards so old that they will run only in very low resolutions anyway, which negates the effect from the low bandwidth. Most AGP cards can easily write 400-1000 MB/s, which is enough bandwith even for higher resolutions. Note: this only goes for writes, reads are insanely slow on AGP. 13 MB/s is the fastest I've ever seen for that; 5 MB/s seems to be normal.

With 200 MB/s write, you can push 60 full 1024x768 32-bit screen updates per second; I think this should be enough for most scenarios (you'll rarely need full screen updates).

One thing: to reach the maximum bandwith, write combining has to be properly configured. Without WC, write speeds depends on operand size, and there are drastic differences between using 64/32/8-bit operands. The relationships between WC/FW combinations and write speeds are a bit... strange. The only way to find optimum settings will be testing on many different machines - speeds can be influenced by hardware bugs/suboptimal implemenation of AGP specs by mainboard or graphics card manufacturer.

I have some older GfxBussBench results from my own and Rudolfs machines lying around in the GfxBusBench sources; I'll see that I dust that off as soon as I find the time. I'm willing to donate GfxBusBench to Haiku (as Rudolf already stated, it runs without changes) if there's interest. There might be a need to rework the command line parameters or such, but the core should be reliable.

This is where we might want to improve our acceleration usage (if possible) - this will definitely be faster on "slow" machines. The other stuff isn't so bad when ignored.

As long as support for PCI and AGPx1 cards is desired, yes. For all other cards, correct configuration of write combining and AGP fast writes should basically always give sufficient bandwith for working without hw acceleration.

[rudolfc]

Hi there Christian! Long time no speak, good to hear from you again :-)

As said, I find your tool a handy one to have. Hopefully Axel or Stephan replies on this tool.. I mean, I can probably put it in svn, but I don't know if I'm supposed to do such things?

BTW: I tested your tool on my new system and got these results:

GeForce 7300 (G72):

Write 64-bit: 1315.41 MB/s (3955.08 MB in 3.01 s) Write 32-bit: 1319.40 MB/s (3991.70 MB in 3.03 s) Write 8-bit: 1308.66 MB/s (3955.08 MB in 3.02 s) Read 64-bit: 5.66 MB/s (18.31 MB in 3.24 s) Read 32-bit: 4.42 MB/s (14.65 MB in 3.32 s) Read 8-bit: 1.10 MB/s (5.49 MB in 4.97 s)

My old GeForce FX 6600 (NV43) ((id 140) which was very slow on the first PCIE system I had!!):

Write 64-bit: 2507.81 MB/s (7543.95 MB in 3.01 s) Write 32-bit: 2507.94 MB/s (7543.95 MB in 3.01 s) Write 8-bit: 2281.85 MB/s (6848.14 MB in 3.00 s) Read 64-bit: 7.63 MB/s (27.47 MB in 3.60 s) Read 32-bit: 5.76 MB/s (21.97 MB in 3.81 s) Read 8-bit: 1.44 MB/s (5.49 MB in 3.82 s)

And another GeForce FX 6600 (NV43): (id 141)

Write 64-bit: 1631.66 MB/s (4907.23 MB in 3.01 s) Write 32-bit: 1633.97 MB/s (4907.23 MB in 3.00 s) Write 8-bit: 1625.91 MB/s (4907.23 MB in 3.02 s) Read 64-bit: 7.30 MB/s (27.47 MB in 3.76 s) Read 32-bit: 5.56 MB/s (21.97 MB in 3.95 s) Read 8-bit: 1.38 MB/s (5.49 MB in 3.97 s)

I also tested a GF8500 in VESA mode and got speeds like id140: 2300Mb/sec.

Reading remains dead slow these days. I hate that. :-/

Bye!

Rudolf.

[rudolfc]

Hi Haikubot,

Sounds like we can close this ticket. Do you agree?

Bye!

Rudolf.

[HaikuBot]

Hi Rudolf.

Sure, close ticket. And thanks for help.

With best regards HaikuBot.

[rudolfc]

Thanks,

Closing :-)

Bye!

Rudolf.

[rudolfc]

Hi once again pacman / Christian,

I'm pasting a response from Axel here concerning the sources of your GFX benchmarking app:

(axel wrote:) We have some at src/tests/system/benchmarks, but there are other locations, too. I guess we can just put it there for now, and clean up this mess one day (later) :-) (end axel).

So if you have write access you can put the code up there. Otherwise you could mail it to me and I'll try to do that.

Thanks a lot in advance!!

Rudolf.