BeBits - Haiku AGP busmanager - Talkback

BeBits

Haiku AGP busmanager

Talkback

Go back to the Haiku AGP busmanager page

Post a new Talkback comment!

TNT2 M64 working

By kraton. - Posted on April 13, 2006 - 11:59:19 (#19452)
Current version when comment was posted: 0.02

Works out of the box without any tweenings on my TNT2 M64

By rudolfc - Posted on April 11, 2006 - 17:44:32 (#19423)
Current version when comment was posted: 0.02

Hi there,

Sorry for missing this message.. Anyway, please try the new busmanager V0.02. There was an issue with it concerning order of programming components that might fix your problem.

If this is not the case, try to disable SBA, and after that try slower AGP speeds (via agp.settings).

Generally, this kind of error has to do with connection loss between the graphicscard and the main system, which can be caused by incorrect negotiated settings for signal strengths (for example). This is a hardware feature that's done at power-up, possibly influenced by some BIOS settings: It's outside the AGP busmanager reach.

Good luck!

Rudolf.

By whaka - Posted on November 20, 2005 - 05:05:44 (#18400)
Current version when comment was posted: 0.01

Hi,this driver doesn't work fine with Dano i use an geforce fx 5200 128MB when i add this driver the tracker crash the icons and deskbar are completly strange i can't explain exactly what happend it's so strange it's a big graphic bug (i'm fench and i don't speak very well english so i'dont always find my words sorry)

mobo : tyan tiger 230T (bi cpu) bi P!!! tualatin 1,26 Ghz

chipset via apollo pro 133a

ram 512 MB

i use the last haiku TNT/GF nVidia driver they works fine on Dano

By rudolfc - Posted on June 10, 2005 - 07:55:32 (#16850)
Current version when comment was posted: 0.01

Hi,

You're actually right: that is if you used BeRoMeter to test the speed. Activating AGP seems to reduce some unaccelerated speeds a bit. Don't know why, and I don't know the inner workings of BeRoMeter.

I guess it's in the end a thing of 'balance' between all things.

Anyway, the speedup should only be noticable for apps using the CPU to send bitmaps heavily to the graphicscards. Examples are video output using both bitmap and overlay, and 3D output where the 3D load is not too heavy compared to actually sending frames (like GLteapot).

---

With nVidia driver 0.49 the acc commands are fetched via real AGP transfers (no scatter-gatter via GART/APERTURE though). This actually speeds up acceleration a bit, but it's not very noticable yet. I saw a 10% speedup using 3D, and also a (even bigger) speedup for one function BeRoMeter tests.

Unfortunately, some other functions BeRoMeter tests drop in measured speed. Some will be that 'balance' thing, while at least one probably is a BeRoMeter measuring fault (variable rollover).

-------

If you can get any info about that single register that needs to be set to let newer cards fall-back to the old way, please feel free to post it here or to mail me: I'd LOVE that missing piece of info!!

Best regards,

Rudolf.

Same Problem Here

By Moriarty - Posted on June 10, 2005 - 03:37:39 (#16849)
Current version when comment was posted: 0.01

Hey all...

I have had no noticeable change in speed on my system, and it seems that the newer the version of Zeta I am using, the slower it gets...

I have a GeForce 5200 FX w/128 on my board - an Intel i865 chipset based board by Foxcomm... It supports SBA and FW, and 8x operation, but after applying the patches, I still don't see anything different...

Any ideas on this one? I use this same card under Linux, Windows XP, and other operating systems (Plan 9, QNX Neutrino, Solaris 9, FreeBSD) with no problems - and, when I go into the BIOS and actually disable the more advanced features of the chipset (like SBA and FW) I DO see the card speed drop... So, it does seem like my motherboard is setup correctly, as well as other things... All of my other hardware, like the NIC and the sound card are all name brand items, and I have flawless performance from them as well... The FX 5200 card is currently on a P4 1.6Ghz system with 512 MB DDR RAM; Previous uses of this card with Rudolf's software were on a P3 850Mhz system with Intel i815 chipset, 4x AGP slot, 512 MB PC133 Memory, and even on this configuration, I noticed no apparant change between the upgrades as compared to before...

Also, for what it's worth, I am using this system as I write this, and it is running off of a SATA IDE drive with 160 GB capacity... No access problems here either... The only problem is if I use Thomas' Replacement IDE driver, then I am unable to boot...

I would like to try out the 3D driver as well - I have no motherboards left in my posession that can use the old GeForce 2 card I have (due to MB voltages, physical slot restrictions, etc.) - I still don't understand exactly why my GeForce FX card won't work - I mean, the Mesa code is Mesa code, and for some reason, I seem to recall from a website years ago that the more modern cards (like the NV30+) simply need a register set and they will drop back to an earlier way of doing the display processing...

Just my two cents worth - Please feel free to send me comments or questions at moriarty@americamail.com

Thanks!

Brian

TNT2

By rudolfc - Posted on November 16, 2004 - 06:54:50 (#14760)
Current version when comment was posted: 0.01

Cool :)

So, does that card have FW capability according to the nVidia driver? Mine hasn't unfortunately, so while the busmanager works OK with it, there is no speed gain at this time.

Bye!

Rudolf.

By Double_S - Posted on November 14, 2004 - 22:10:58 (#14746)
Current version when comment was posted: 0.01

It works on a VIA Apollo Pro+ (693/596) combined with a NVidia TNT2 !

GLteapot for benchmarking

By rudolfc - Posted on November 14, 2004 - 20:40:45 (#14743)
Current version when comment was posted: 0.01

Hi,

I think things are probably just fine (try disabling AGP and recheck the FPS: it should drop further).

You have to be very carefull not to resize the teapot window, or change the setup, or change the movement, or change the colorspace or you can't compare results anymore!
(try it AFTER you tested dropping to PCI mode and you'll see ;-)

Hope this helps.

Bye!

Rudolf.

Slow-up after installing B*ne...

By tuishimi - Posted on November 9, 2004 - 16:34:34 (#14689)
Current version when comment was posted: 0.01

Configuration:
Soyo K7VME, 1.75 gHz, 256MB ram, NVidia FX 5200 128MB VRam.

Scenario:
After fresh BeOS R5.0.3 install w/agp busman (and Athlon patch, of course) I was getting between 140 and 180 FPS when running Teapot.

This morning I installed Be, Inc's beta networking and now I am seeing no more than 130 FPS with Teapot, and sometimes it dips below 100FPS.

Any thoughts? Should I check to see if the driver is still loading properly? (I have to enable kernel logging output, no?)

Mike

to Big Lebowski

By rudolfc - Posted on August 23, 2004 - 13:50:33 (#13952)
Current version when comment was posted: 0.01

Hi,

2D acc indeed will not improve, and indeed benchmarking will show slightly vari-ing results normally.
The GLteapot should gain some speed though, but it's sometimes hard to see due to the ever changing speed.

The best benchmarking app outthere that I know of is indeed running quake2 in software rendering mode, using timedemo. You should definately see a nice speedup here. :-)

Best regards,

Rudolf.

No performance increase

By Big Lebowski - Posted on August 9, 2004 - 13:09:51 (#13787)
Current version when comment was posted: 0.01

System AOpen AX4B-533 motherboard (845E)
Celeron 1.7, 768 MB RAM
NV17 (Geforce 4 MX 440)
Beos Max 3.1b1
AGP busman + Haiku NV driver 0.22

GLTeapot shows same sort of frame rate as 0.10 driver, no AGP (around the 46 fps mark).

BeRometer (the only graphics benchmark I could find on BeBits) gives (not significantly) worse results with AGP busman, but I'm not sure how accurate this benchmarking is.

With AGP
Lines Flushed 29978
Lines Unflushed 55581
Strings Flushed 301
Strings Unflushed 614
Ellipses Flushed 7987.3
Ellipses Unflushed 9689
Ellipses Unflushed Filled 12903
Rectangles Flushed 37674
Rectangles Unflushed 67070
Rectangles Unflushed Filled 135351
Polygons Flushed 15687
Polygons Unflushed 20789
Polygons Unflushed Filled 4333

Without AGP
Lines Flushed 33099
Lines Unflushed 64257
Strings Flushed 308
Strings Unflushed 658
Ellipses Flushed 7926
Ellipses Unflushed 9577
Ellipses Unflushed Filled 12821
Rectangles Flushed 38333
Rectangles Unflushed 67087
Rectangles Unflushed Filled 137811
Polygons Flushed 17879
Polygons Unflushed 24397.43
Polygons Unflushed Filled 4320

Maybe a more demanding test (Quake2), or lowering CPU clock speed would show different results.

from nv.accelerant.0.log
AGP: STRAPINFO2 contains $80c0d43f
AGP: attempting to enable fastwrite support..
AGP: STRAPINFO2 now contains $80c0d43f
AGP: AGP capable device #1:
AGP: device is a hostbridge, subclass ID is $00
AGP: vendor ID $8086
AGP: device ID $1a30
AGP: bus 0, device 0, function 0
AGP: this device supports AGP specification 2.0;
AGP: AGP 2.0 1x mode is available
AGP: AGP 2.0 2x mode is available
AGP: AGP 2.0 4x mode is available
AGP: fastwrite transfers are supported
AGP: sideband adressing is supported
AGP: 32 queued AGP requests can be handled.
AGP: listing settings now in use:
AGP: max. AGP queued request depth is set to 1
AGP: the AGP interface is disabled.
AGP: AGP capable device #2:
AGP: (this is the device this accelerant controls)
AGP: device is a graphicscard, subclass ID is $00
AGP: vendor ID $10de
AGP: device ID $0171
AGP: bus 1, device 0, function 0
AGP: this device supports AGP specification 2.0;
AGP: AGP 2.0 1x mode is available
AGP: AGP 2.0 2x mode is available
AGP: AGP 2.0 4x mode is available
AGP: fastwrite transfers are supported
AGP: 32 queued AGP requests can be handled.
AGP: listing settings now in use:
AGP: max. AGP queued request depth is set to 1
AGP: the AGP interface is disabled.
AGP: end of AGP capable devices list.
AGP: activating AGP mode...
AGP: listing settings now in use:
AGP: AGP 2.0 4x mode is set
AGP: fastwrite transfers are enabled
AGP: max. AGP queued request depth is set to 32
AGP: the AGP interface is enabled.
AGP: graphics card AGPCMD register readback $1f000114

It may not be what I had hyped in my own mind, but I thank you Rudolf for your continuing Haiku/BeOS development. Your work has benifited hundreds, and I owe you a beer!

To tuishimi

By topical - Posted on August 2, 2004 - 14:52:06 (#13700)
Current version when comment was posted: 0.01

I just posted in the Radeon TalkBack that FW are not used in your case as the graphics card or motherboard doesn't support it.

Re: thinkpad r50p and ati

By topical - Posted on August 2, 2004 - 14:50:44 (#13699)
Current version when comment was posted: 0.01

I don't think that FW are used. AFAIK, FW can only be used in combination with Write Combining, but as the VESA driver doesn't enable Write Combining, FW is implicitely disabled.

Seems to be working...

By tuishimi - Posted on August 2, 2004 - 14:34:47 (#13697)
Current version when comment was posted: 0.01

Since my last post my BeOS system died. So I stuck my old P2B-D MoBo back in and got her up and running and of course installed the driver again... but Teapot doesn't seem any different and, unfortunately, I did not record frame rates for (or even run) Quake2 to see if there was an improvement on my (now) slower PC. :/ But does this look about right...

...is this good or bad, and do I have FW? :/

KERN 'app_server'[25]: agp_drv V2: init_hardware called
KERN 'app_server'[25]: agp_man: bus module: init
KERN 'app_server'[25]: agp_man: found 2 AGP capable device(s)
KERN 'app_server'[25]: agp_drv V2: init_driver called
KERN 'app_server'[25]: agp_man: get_nth_agp_info called with index 0
KERN 'app_server'[25]: agp_man: get_nth_agp_info called with index 1
KERN 'app_server'[25]: agp_man: get_nth_agp_info called with index 2
KERN 'app_server'[25]: agp_drv V2: enabling AGP
KERN 'app_server'[25]: agp_man: enable_agp called
KERN 'app_server'[25]: agp_drv V2: AGP cmd readback: $1f000302.
KERN 'app_server'[25]: agp_drv V2: uninit_driver called
KERN 'app_server'[25]: Radeon - init_hardware: Version: 3.2.7.2
KERN 'app_server'[25]: Radeon - Radeon_FindRom: Signature: RG6
KERN 'app_server'[25]: Radeon - Radeon_FindRom: found ROM @0xc0000
KERN 'app_server'[25]: Radeon - Radeon_CardDetect: found supported device
pci index 2, device 0x1002/0x5144
KERN 'app_server'[25]: Radeon - Radeon_FindRom: Signature: RG6
KERN 'app_server'[25]: Radeon - Radeon_FindRom: found ROM @0xc0000
KERN 'app_server'[25]: Radeon - Radeon_MapDevice:
KERN 'app_server'[25]: Radeon - Radeon_MapDevice: old PCI command state:
0x00000087
KERN 'app_server'[25]: Radeon - Radeon_MapDevice: physical address of
memory-mapped I/O: 0xd6000000-0xd607ffff
KERN 'app_server'[25]: Radeon - Radeon_GetPLLInfo: ref_clk=2700, ref_div=
60, xclk=16600, min_freq=12000, max_freq=35000 from BIOS
KERN 'app_server'[25]: Radeon - Radeon_GetMonType:
KERN 'app_server'[25]: Radeon - Radeon_GetMonType: BIOS reports CRT on
primary and N/C on secondary port
KERN 'app_server'[25]: Radeon - Radeon_GetMonType: Effective routing:
CRT on primary and N/C on secondary port
KERN 'app_server'[25]: Radeon - Radeon_DetectRAM: 32 MB DDR SGRAM
found
KERN 'app_server'[25]: Radeon - Radeon_UnmapDevice:
KERN 'app_server'[25]: Radeon - probeDevice: found Radeon 7200 / Radeon /
ALL-IN-WONDER Radeon; ASIC: r100
KERN 'app_server'[25]: Radeon - probeDevice: making /dev/graphics/
1002_5144_010000
KERN 'app_server'[25]: Radeon - Radeon_ProbeDevices: 1 supported devices
[...snip some stuff...]
KERN 'app_server'[25]: Radeon - Radeon_FindRom: Signature: RG6
KERN 'app_server'[25]: Radeon - Radeon_FindRom: found ROM @0xc0000
KERN 'app_server'[25]: Radeon - Radeon_MapDevice:
KERN 'app_server'[25]: Radeon - Radeon_MapDevice: old PCI command state:
0x00000086
KERN 'app_server'[25]: Radeon - Radeon_MapDevice: physical address of
memory-mapped I/O: 0xd6000000-0xd607ffff
KERN 'app_server'[25]: Radeon - Radeon_GetPLLInfo: ref_clk=2700, ref_div=
60, xclk=16600, min_freq=12000, max_freq=35000 from BIOS
KERN 'app_server'[25]: Radeon - Radeon_GetMonType:
KERN 'app_server'[25]: Radeon - Radeon_GetMonType: BIOS reports CRT on
primary and N/C on secondary port
KERN 'app_server'[25]: Radeon - Radeon_GetMonType: Effective routing:
CRT on primary and N/C on secondary port
KERN 'app_server'[25]: Radeon - Radeon_DetectRAM: 32 MB DDR SGRAM
found
KERN 'app_server'[25]: Radeon - Radeon_UnmapDevice:
KERN 'app_server'[25]: Radeon - probeDevice: found Radeon 7200 / Radeon /
ALL-IN-WONDER Radeon; ASIC: r100
KERN 'app_server'[25]: Radeon - probeDevice: making /dev/graphics/
1002_5144_010000
KERN 'app_server'[25]: Radeon - Radeon_ProbeDevices: 1 supported devices
KERN 'app_server'[25]: Radeon - open_hook: name=graphics/
1002_5144_010000, flags=2, cookie=0x013dda68
KERN 'app_server'[25]: Radeon - Radeon_MapDevice:
KERN 'app_server'[25]: Radeon - Radeon_MapDevice: old PCI command state:
0x00000086
KERN 'app_server'[25]: Radeon - Radeon_MapDevice: physical address of
memory-mapped I/O: 0xd6000000-0xd607ffff
KERN 'app_server'[25]: Radeon - Radeon_MapDevice: restrict frame buffer
from 0x 8000000 to 0x 2000000 bytes
KERN 'app_server'[25]: Radeon - Radeon_MapDevice: physical address of
framebuffer: 0xd8000000-0xd9ffffff
KERN 'app_server'[25]: create_mtr(0x1a4, d8000000, 02000000, 1)
KERN 'app_server'[25]: Radeon - Radeon_MapDevice: mapped frame buffer
@0x30400000
KERN 'app_server'[25]: Radeon - Radeon_InitDMA: Non-local memory
2000000@fe000000 (graphics card address)
KERN 'app_server'[25]: Radeon - createDMABuffer:
KERN 'app_server'[25]: Radeon - createDMABuffer: aligned_phys=0x02400000
KERN 'app_server'[25]: create_mtr(0x1a6, 02400000, 00080000, 1)
KERN 'app_server'[25]: destroy_mtr(0x1a6)
KERN 'app_server'[25]: create_area_gen error -2147483643 ( 0, 5, 1)
KERN 'app_server'[25]: create_mtr(0x1a7, 02400000, 00080000, 1)
KERN 'app_server'[25]: Radeon - initGART:
KERN 'app_server'[25]: Radeon - initGART: GART_ptr=0x32580000,
GART_phys=0x02710000
KERN 'app_server'[25]: Radeon - Radeon_InitDMA: GART=0x32500000
KERN 'app_server'[25]: Radeon - mem_init: start=0, len=2000000, block_size
=400, heap_entries=32768
KERN 'app_server'[25]: Radeon - open_hook: returning 0x00000000
[...another cut...]
KERN 'app_server'[25]: Radeon - setupCPRegisters: CP buffer address=
fe000000
KERN 'app_server'[25]: Radeon - setupCPRegisters: CP read pointer buffer==
fe040000
KERN 'app_server'[25]: Radeon - setupCPRegisters: CP buffer size mask=15
KERN 'app_server'[25]: Radeon - SET_DISPLAY_MODE: width=1024, height=
768
KERN 'app_server'[25]: Radeon - PROPOSE_DISPLAY_MODE: wished:
KERN 'app_server'[25]: Radeon - PROPOSE_DISPLAY_MODE: H: 1024 1040
1136 1312 (v=1024)
KERN 'app_server'[25]: Radeon - PROPOSE_DISPLAY_MODE: V: 768 769 772
800 (h= 768)
KERN 'app_server'[25]: Radeon - PROPOSE_DISPLAY_MODE: clk: 78750
KERN 'app_server'[25]: Radeon - PROPOSE_DISPLAY_MODE: got:
KERN 'app_server'[25]: Radeon - PROPOSE_DISPLAY_MODE: H: 1024 1040
1136 1312 (v=1024)
KERN 'app_server'[25]: Radeon - PROPOSE_DISPLAY_MODE: V: 768 769 772
800 (h= 768)
KERN 'app_server'[25]: Radeon - PROPOSE_DISPLAY_MODE: clk: 78750
KERN 'app_server'[25]: Radeon - SET_DISPLAY_MODE: independant ports: 1
KERN 'app_server'[25]: Radeon - SET_DISPLAY_MODE: scrolling disabled
KERN 'app_server'[25]: Radeon - mem_alloc: size=1024, tag=0x01495af8
KERN 'app_server'[25]: Radeon - mem_alloc: block_id=1, offset=0
KERN 'app_server'[25]: Radeon - mem_alloc: size=3145728, tag=0x01495af8
KERN 'app_server'[25]: Radeon - mem_alloc: block_id=2, offset=400
KERN 'app_server'[25]: Radeon - Radeon_CalcCRTCRegisters: crtc_pitch=128
KERN 'app_server'[25]: Radeon - Radeon_CalcPLLDividers: freq=7875
KERN 'app_server'[25]: Radeon - Radeon_CalcPLLDividers: dot_clock_freq=
7875, pll_output_freq=15750, ref_div=60, feedback_div=350, post_div=2

Outstanding work!!

By Caz - Posted on July 29, 2004 - 02:22:17 (#13640)
Current version when comment was posted: 0.01

This driver is superb addition to any BeOS system and you should be commended for your work, of course FastWrites support is needed to get the full benefit, but if your chipset supports this mode what a massive difference it makes. Even so having an agp driver allows future enhancements to be available too.

I had tried your agp driver before you released it on BeBits and it worked fine, but didn't really do any benchmarks etc..

I have done many tests over the years, testing the same code across different OS's which allow direct access to the framebuffer, and i couldn't understand why some graphics drawing apps i made weren't performing the same across OS's. I can now see that no matter how hard i tried i couldn't speed up my graphics drawing code on BeOS anymore as the bandwidth wasn't there.

Thanks

Caz

By rudolfc - Posted on July 26, 2004 - 10:14:16 (#13573)
Current version when comment was posted: 0.01

Hi,

So you have another example of a ATI card working with FW as long as the ATI driver is not installed. Thanks for letting me know.

I guess this repeating stuff is indeed coming from the B/W compatibility driver/add-on trying some things.

AFAIK it's not meaning something is wrong. I can't tell you more about the B/W (or VESA) way of doing things, as I never looked real close at that yet.

Best regards,

Rudolf.

thinkpad r50p and ati

By dudenz - Posted on July 25, 2004 - 18:53:43 (#13569)
Current version when comment was posted: 0.01

hi.

on my thinkpad r50p and ATI Mobility Fire Gl T2 this fastwrites thing works obviously.

KERN 'app_server'[24]: agp_drv V2: init_hardware called
KERN 'app_server'[24]: agp_man: bus module: init
KERN 'app_server'[24]: agp_man: found 2 AGP capable device(s)
KERN 'app_server'[24]: agp_drv V2: init_driver called
KERN 'app_server'[24]: agp_man: get_nth_agp_info called with index 0
KERN 'app_server'[24]: agp_man: get_nth_agp_info called with index 1
KERN 'app_server'[24]: agp_man: get_nth_agp_info called with index 2
KERN 'app_server'[24]: agp_drv V2: enabling AGP
KERN 'app_server'[24]: agp_man: enable_agp called
KERN 'app_server'[24]: agp_man: max AGP 4x speed allowed (agp.settings)
KERN 'app_server'[24]: agp_drv V2: AGP cmd readback: $1f000314.
KERN 'app_server'[24]: agp_drv V2: uninit_driver called
KERN 'app_server'[24]: 3dfx_v4: init_hardware - Enter - PCI 3dfx-driver: May 26 2000 12:35:09
KERN 'app_server'[24]: +++ probe_devices: 0 supported devices
KERN 'app_server'[24]: +++ uninit_driver

(but unfortunately it is all in black and white, because somehow my ATI seems to make some problems...)

but also,I have got a question:
now that I deinstalled the nonworking ATI-driver and bootet just with the agp-busmanager and the fakedriver the following lines are repeated 9 times:

KERN 'app_server'[24]: VGA_MAP_MAP_NTH(0) out of 2
KERN 'app_server'[24]: trying to set 0x002fb184 to 0x30374000 + 0x00000000
KERN 'app_server'[24]: create_pci_area: pci_bus1_dev0_func0_reg0 mapping at 0x30374000
KERN 'app_server'[24]: trying to set 0x002fb18c to 0x38374000 + 0x00000000
KERN 'app_server'[24]: create_pci_area: pci_bus1_dev0_func0_reg2 mapping at 0x38374000
KERN 'app_server'[24]: returning the mangled pcii info

(some nubers vary from entry to entry a bit)
Is that supposed to be right? or is there something wrong? does that come from Black/White mode?

thanks for your work and efforts.
dudenz

Hangs with FW - No speed up on Radeon 9000

By zittergie - Posted on July 25, 2004 - 17:31:49 (#13567)
Current version when comment was posted: 0.01

Hi,

I'm using an ABIT NF7-S (nvidia2 chipset) and a radeon 9000 Using BeOS 5.0.3
The only way to use the AGP busmanager for me is to enable block FW.

I've run the Quake2 timedemo 1 and the results with or without are just the same: 51.7 frames.

On Phos I get 54.6 frames BTW

'BE the difference that makes a difference' - JEWEL

nasty sounding 'FW override'

By rudolfc - Posted on July 25, 2004 - 11:39:52 (#13559)
Current version when comment was posted: 0.01

Hi,

Just for completeness, I want to make a remark about my previous post here about a system with ATI card that had a BIOS setup option called 'FW override'.

After further testing by this user, it turns out that enabling this indeed adds FW capability in the normal, expected way. That is, the busmanager sees the option, and enables it quite normally.

This user, and someone else reporting here, both have FW up and running, but _only_ without running the ATI driver: so in B/W or VESA mode.

This theoretically means, that the trouble with the ATI driver for those cards must be in that driver, and not in the fact AGP has been setup.

OK, that's it. Let's wait and see what Thomas finds out about all this stuff before drawing final conclusions. :-)

It has been interesting at least, to see all this feedback with this first step in adding AGP support in BeOS. I think we learned a lot from it already..

Best regards,

Rudolf.

transam117 / ogl speedup

By rudolfc - Posted on July 24, 2004 - 09:37:31 (#13546)
Current version when comment was posted: 0.01

Hi again,

You will find that the 'software rendering' method in quake2 speeds up (over here 125% in AGP2x +FW, 140% in AGP4x +FW). software 'openGL' will not in quake2 however.

The reason for this is that the main bottleneck for scenes this complicated is the CPU, not the graphicscard bus throughput.

Speedup is not just as high as the comms speedup done by FW, because apart from transferring data, other tasks are done as well: like rendering a scene. So the actual speedgain is depending on the 'mix active' on CPU load and bus throughput. (There will probably be more to it, but you get the picture ;-)

The GLteapot however, will probably speedup (a bit), because here the mix is different: we have a relatively simple scene to render here, so the bus throughput comes into play again as being a bottleneck.

BTW: Thanks for your comments! I think the stuff we wrote is important for others probably as well (including myself :) to gain better insight in how things are both in theory and in praxis.

Rudolf.

SD/ weird bug / nVidia

By rudolfc - Posted on July 24, 2004 - 09:31:01 (#13545)
Current version when comment was posted: 0.01

Hi again SD,

This weird bug may indeed be related to AGP. You could try to shutoff SBA, set a lower map AGP speed, or if need be, disable FW. I know of a VIA system that did not work with AGP4x +FW, but did in AGP2x+FW. Strange graphical trouble was existing there as well.

About nVidia:
If you run the nVidia driver and you enable full logging there, it will extensively log the AGP old settings, options, and new settings done. It will log using normal Enlish as well (more or less ;-)

So if you want to see if FW is on, look at the nv.accelerant.0.log, and search for 'agp'. (it's all in one 'burst' in the file)

Rudolf.

By trasnam - Posted on July 24, 2004 - 03:54:47 (#13542)
Current version when comment was posted: 0.01

Hey, thanks for all of the information about AGP, as well as mentioning what you are working on next. Sorry if I got carried away in my reply, as I know everything I said only applied to my experience with Windows. If I get a chance this weekend, I'll rip my 9700 Pro out of my other computer and put it in this computer that supports fastwrites. I do want to see if I get better framerates with Quake 2, or software OGL in general for that matter. Also, I want to see how stable it is. Yes, I testified as to what I know in Windows, but I shouldn't have spoken as if I knew what performance in BeOS would be like, all without actually trying it.

Thanks for all of your hard work, as AGP in BeOS is definitely a big step towards greater things. Keep up the fantastic work.

By SD - Posted on July 24, 2004 - 03:26:23 (#13541)
Current version when comment was posted: 0.01

Dunno if it is really related to AGP-Kit, but it gone after i removed both manager and driver.

Computer always started in 640*480 * 72.8 Hz mode.
I could set this first workspace back to any supported res (1024*768*32*75Hz in use here), but it always had reset it back to 640*480 at next restart. Also Tracker hanged for some time at shutdown (won't to quit immediately, rather).

nVidia/Guillemot 0x10de CardID 2d

By SD - Posted on July 24, 2004 - 03:12:40 (#13540)
Current version when comment was posted: 0.01

Starts ok with all enabled in agp driver with previous Hiku-nVidia driver (0.1 ?)
With new driver (0.22) works stable also with fw_unhide true.
agp_man: bus module: init
agp_man: found 2 AGP capable device(s)
+++ making /dev/graphics/nv4_010000
+++ probe_devices: 1 supported devices
+++ uninit_driver
+++ making /dev/graphics/10de_002d_010000
+++ probe_devices: 1 supported devices
+++ uninit_driver
mtrr_intel::std_ops(1)
init_mtrrs_intel()
done init_mtrrs_intel
Using cpu/mtrr/intel/v1
Calling sync_mtrrs()
sync_mtrrs()
Calling isr
sync_mtrrs() done
Done calling sync_mtrrs()
Done init_mtrs()
create_mtr(0x268, d4000000, 02000000, 1)
mtrr_intel::std_ops(2)
agp_man: get_nth_agp_info called with index 0
agp_man: get_nth_agp_info called with index 1
agp_man: get_nth_agp_info called with index 2
agp_man: enable_agp called

fastwrites / transam117

By rudolfc - Posted on July 23, 2004 - 20:48:06 (#13538)
Current version when comment was posted: 0.01

Hi there,

Thanks for your explanation. I was asking because I always like to learn more ;-)

Anyway, here's the deal with the whole AGP thingy concerning speed.

1.you have transfers to the graphicscard done by the main system (CPU) to the graphicscard;
2.you have transfers from the graphicscard to main system done by main system;
3.you have transfers to the graphicscard done by the graphicscard (GPU);
3.you have transfers from the graphicscard to main system done by graphicscard.

OK, AGP can only be used in 3. and 4., but NOT in 1. and 2. AGP means that the acceleration engine (and the acceleration engine _only_) starts a AGP transfer to or from the main system (RAM). These transfers run in for instance AGP8x speed/mode. This scheme is devices for the sole purpose of accelerating 3D to the max.

If you have setup for instance AGP8x, then 1. and 2. are STILL done in standard PCI mode. Hence, AGP brings no acceleration whatsoever here. 1. and 2. are all operations _apart_ from 3D acceleration. So this is everything unaccelerated. 2D acceleration is merely moving data around in the graphics memory of the card WITHOUT any transfer on the bus connecting the card to the system.
Unaccelerated things are every bit of data that has to be moved from the system to the card memory (video bitmaps or overlay bitmaps, or pictures that need to be shown, new data that has to be shown if you scroll down a text window, etc)

OK: you guessed it: BeOS cannot use 3. and 4., but only 1. and 2.

So, now you think: why the hell did Rudolf came up with this stuff anyway, if we can't use it.

Well, there are two reasons, A and B:
A. Fastwrites. Actually, the correct name is PCI fastwrites. So what is that? It's a method to speedup 1. Howso? It uses the AGP speed set, to clock data in 'PCI mode' to the graphicscard. This means in AGP8x mode, it gets accelerated by a factor of 8 (on large chunks of data).
Now, _this_ is going to help us, no? Yes: indeed. This is what I talk about when I start about quake2 fps in software rendering mode for example.

How about 2.? Aha: well, no speedup trick is possible here. This means that this will remain using standard PCI transfers, and will not benefit from AGP. Unless the driver would be updated to issue AGP transfers by the acc engine on request of the system, instead of the system fetching the data itself as it is now.
What would benefit? Only captured video on a video-in port on a graphicscard.

===

Keep in mind that 1. and 2. is how BeOS works. If this is speedup, by setting some AGP mode, it will work instantaniously.

3. and 4. however require a rewrite of the driver for it to gain any use. And a rewrite of the app_Server, to place all kinds of bitmaps in main mem, and instruct the card's engine to fetch it there.

OK. But I just said that 3.and4. are only meant for 3D. Yes, you are right. But theoretically we could use it for all 'unaccelerated' stuff as well, if such a rewrite was done. However, in the 'real world' outthere, this is not used. AFAIK. I can imagine this, seeing that AGP (3. and 4.) tends to make trouble a lot more often than those PCI transfers, 1. and 2. once FW is not used for 1., there's no single problem remaining that could cause trouble. Except accelerated 3D of course. And of course if a mistake is made in setting up the acc engine for 2D issuing some AGP transfer (while AGP gives trouble of course on that specific hardware).

This is the main reason trouble normally starts with AGP (windows) if one starts to play a 3D game...

======

OK, I have a B. for you as well: (we just had A.).
The second reason for me to setup this AGP stuff is that I will be starting experiments with accelerated 3D for nVidia shortly. Using MESA, utahGLX and DRI. Currently I am trying to learn openGL, and I am looking at the linux code for those 'projects'. Testin g will come at some point during that, and it would be nice if I can use AGP transfers, even if I can't use the GART and AGP aperture yet (you can also directly adress main mem, instead of using that GART/aperture scheme).

Note however: I am a newbe here (as I was before with these drivers I did ;-), so I cannot say anything about success or failure chances I have. Just wish me luck...

Rudolf.

rudolfc - Regarding fastwrites

By trasnam - Posted on July 23, 2004 - 19:56:17 (#13537)
Current version when comment was posted: 0.01

Alright, here is what I know about fast writes and ATI Radeons. Fast writes is only supported on Radeon 8500's and better (with the exception of the 8500 DV, which can't do fast writes). In most cases (at least with 3D in Windows), the performance increase is minimal, if at all, and system instability usually follows as a result. The one exception (that I know of personally) is the Radeon 9600, which seems to be more stable and perform better with fast writes on.

If you search on tech forums about ATI Radeons, it is repeated over and over again, that turning on fast writes will result in little performance gain, if any on most Radeons that support it. Here is one such link I just found with a quick search: http://www.techimo.com/forum/archive/index.php/t-112826.html . Now, this lack of performance increase may just be in 3D games or what have you (I never really checked 2D performance), so perhaps it doesn't apply here to BeOS whatsoever. If that is the case, I am sorry to cause any confusion to anyone.

As for stability, I think it is usually due to a faulty motherboard chipset, however it seems that some of the instability is indeed due to the way the Radeons handle fast writes. As I've aforementioned, the only Radeon I found pretty stable with fast writes was the 9600. I have in no way tested every Radeon, so take that as you will.

Oh yeah, something else regarding fast writes (not specific to any GPU manufacturer). I realize it is supposed to be markedly faster having them than without. I think that was more relevant in the past though, however, when memory bandwidth wasn't as high and AGP would starve for bandwidth with other shared devices. Today, there is a lot more memory bandwidth, especially with innovations like TwinBank, so in a lot of cases, I don't think there is a HUGE benefit to having fast writes on, one way or the other. Yes, with fast writes, there is a definite latency loss, as you don't have an additional read/write operation in system RAM. Yes, this is beneficial. However, I don't think that difference will mean much with newer systems and the exorbitant amount of memory bandwidth they have available. I realize not all people have newer systems, so yes, I think fast writes do have their place.

Rudolf, I hope I addressed your question, even if I ranted somewhat. I realize you probably know more about computer hardware than I ever will, but I'm just reporting what I know from experience, and what I have heard from third parties regarding issues with Radeons.

Radeon again..

By rudolfc - Posted on July 23, 2004 - 18:15:42 (#13536)
Current version when comment was posted: 0.01

Hi,

One more remark: From Thomas I get that it's in fact the acceleration engine on those cards that get's stuck: it's starting a command it never finishes. (might be IGP only, I don't know).

The first command the app_server issues BTW is the background color (blue) AFAIK. Maybe the driver does some internal RAM clearing or something before that also. Or something else..

This means that I expect those cards to work if you disable the acceleration engine: I personally find it inteesting to know if that is the case.

If so, this underlines that this engine in the current, very advanced, setup that Thomas does (which I do not use because of lack of spec, but I admire it anyway ;-) gets in trouble because something in there is using AGP transfers for example that Thomas perhaps is not aware of.

For instance: if this happens in PCI mode they simply get aborted. When AGP is active they would be honored, but can fail because the AGP GART is not setup yet. Also, when they don't fail because they adress memory space _outside_ the AGP aperture (that's related to the GART and also not yet setup), they can still fail because it's very possible that memory cache coherency is not automatically taken care of.

Seeing the fact that Thomas uses engine microcode that noone knows the meaning of (outside of ATI that is and maybe more important parties for them), I can imagine some fault in there that cannot be fixed.

One other track to follow would be the circular engine command buffers the ATI driver maintains in main mem: it's interesting to check out no AGP transfer would be used to fetch that: that's not the plan as AGP was not enabled before.

OK, These are my two cents. They may be wrong, but anyway these are things I would at least consider if I would be working on fixing this fault.

All in all, I am _very_ interested in what Thomas or other people find out about this stuff. I mean, apparantly also the AGP spec is not adhered to completely in setting up that 'simple' AGP command register, as Thomas told me.

Greetings!

Rudolf.

old matrox driver

By rudolfc - Posted on July 23, 2004 - 18:04:06 (#13535)
Current version when comment was posted: 0.01

BTW,

In those syslogs I repeatedly see info about the gx00.driver. This is Mark Watson's (by now very old) version of the matrox driver: that is of no use anymore and can safely be deleted...

Not that is has anything to do with the Radeon problems.

Rudolf.

tFW/transam117

By rudolfc - Posted on July 23, 2004 - 18:00:32 (#13534)
Current version when comment was posted: 0.01

Hi,

On what info is your remark based? Every card that supports FW will _automatically_ benefit from the increased bandwith on BeOS: _unless_ the cards frameRAM is not mapped in virtual memory using MTRR WC (writecombining).

If WC is not used, that is the worst bottleneck of the two things we are talking about here, if not, it's the bus throughput: which is directly influenced with FW.

AGP transfers have nothing to do with it on BeOS as it is, as this is only usefull for 3D acc, and BeOS is also not designed to have the framebuffer in main RAM so the card engine would be able to fetch it via AGP transfers.

SO, all in all: FW is the _only_ 'feature' that specificly requires _nothing_ from the card to have a speed effect, _apart_ from the MTRR WC feature.

Radeon cards being unstable with this feature is something else of course: but that would mean it should be unstable _also_ in VESA mode with FW enabled. Because altough there's no speed increase (MTRR WC not on then), FW transfers _are_ definately in use then for _every_ byte that's transferred to the graphicscard on BeOs!

Rudolf.

ATI RADEON 8500

By kraton. - Posted on July 23, 2004 - 17:48:55 (#13531)
Current version when comment was posted: 0.01

Yes rudolf is right it is working ok in vesa mode.
But not with the radeon 4.1 nor the other 3.1 Radeon drivers.
Anyway here is my last syslog. So I wait for news about a new Radeon driver or else, and set FW to true. thx all for help.

KERN 'app_server'[17]: agp_man: found 2 AGP capable device(s)
KERN 'app_server'[17]: get_module(bus_managers/agp/v0): wake failed
KERN 'app_server'[17]: agp_drv V2: init_driver called
KERN 'app_server'[17]: agp_man: get_nth_agp_info called with index 0
KERN 'app_server'[17]: agp_man: get_nth_agp_info called with index 1
KERN 'app_server'[17]: agp_man: get_nth_agp_info called with index 2
KERN 'app_server'[17]: agp_drv V2: enabling AGP
KERN 'app_server'[17]: agp_man: enable_agp called
KERN 'app_server'[17]: agp_man: max AGP 4x speed allowed (agp.settings)
KERN 'app_server'[17]: agp_drv V2: AGP cmd readback: $1f000314.
KERN 'app_server'[17]: agp_drv V2: uninit_driver called
KERN 'app_server'[17]: kprof_load_image called way too early
KERN 'app_server'[17]: KERNEL: driver gx00.driver does not have wake_driver and

By trasnam - Posted on July 23, 2004 - 17:11:33 (#13530)
Current version when comment was posted: 0.01

Your syslog looks fine. With the last 3 hex digits of 314 for the AGP cmd readback, you have fast writes and sidebanding enabled, along with AGP transfers at AGP 4x (version 2.0 AGP).

However, I strongly suggest that you set block_fw to true in agp.settings, due to the fact that Radeon cards see ZERO performance benefit from it being enabled due to the way they are designed. An unstable system is the only thing that can/will result. All other ATI cards will see a performance benefit from this being on, but just nothing in the Radeon family.

After block_fw is set to true, you should get an AGP cmd readback of 1f000304. I believe this is the best you are going to get and remain stable.

I am basing my response on the Radeon 8500 you mentioned from previous posts, so if you are currently talking about a different card that is non-Radeon, then my advice may not be correct.

By rudolfc - Posted on July 23, 2004 - 16:47:02 (#13528)
Current version when comment was posted: 0.01

Hi,

This syslog is nice: your system supports max AGP 4x mode, SBA and FW. That's all up and running with that syslog.

If with that syslog your system did not crash without the ATI driver, but it _did_ crash _with_ that ATI driver, then there definately _must_ be an error in the ATI driver!

Maybe Thomas initiates AGP transfers without him actually knowing it for your card... If it were a nVidia, with the setting you have now it would work fully OK, _and_ have the graphics speedup...

Please reelay this to Thomas if you want.

Thanks.

Rudolf.

PS: There's nothing more I can do: if VESA mode runs OK with the syslog you posted now, then AGP is in fact up and running OK.

Bye!

ATI 8500 with intel 845E motherboard

By kraton. - Posted on July 23, 2004 - 15:38:35 (#13526)
Current version when comment was posted: 0.01

I have a 2x and 4x ATI AGP-Graficcard
and my intel 845G motherboard supports 4x AGP too.
so it should work, but it wont. I´m able to run the driver with 1xAGP,false,false,false only. Is there hope for future support of my card if i send you more feedback rudolf?

So i´ll send you my newest syslog(Is this part enough or do u need more frome the syslog???)I was just trying 8x to see if the system automatically changes to 4x and it does:

KERN 'app_server'[17]: agp_man: found 2 AGP capable device(s)
KERN 'app_server'[17]: get_module(bus_managers/agp/v0): wake failed
KERN 'app_server'[17]: agp_drv V2: init_driver called
KERN 'app_server'[17]: agp_man: get_nth_agp_info called with index 0
KERN 'app_server'[17]: agp_man: get_nth_agp_info called with index 1
KERN 'app_server'[17]: agp_man: get_nth_agp_info called with index 2
KERN 'app_server'[17]: agp_drv V2: enabling AGP
KERN 'app_server'[17]: agp_man: enable_agp called
KERN 'app_server'[17]: agp_man: max AGP 8x speed allowed, using max 4x (agp.settings)
KERN 'app_server'[17]: agp_drv V2: AGP cmd readback: $1f000314.
KERN 'app_server'[17]: agp_drv V2: uninit_driver called
KERN 'app_server'[17]: kprof_load_image called way too early
KERN 'app_server'[17]: KERNEL: driver gx00.driver does not have wake_driver and suspend_driver
KERN 'app_server'[17]: kprof_load_image called way too early
KERN 'app_server'[17]: KERNEL: driver mga.driver does not have wake_driver and suspend_driver
KERN 'app_server'[17]: kprof_load_image called way too early
KERN 'app_server'[17]: KERNEL: driver radeon2 does not have wake_driver and suspend_driver
KERN 'app_server'[17]: Radeon - init_hardware: Version: 4.1.0.0
KERN 'app_server'[17]: Radeon - Radeon_FindRom: Signature: R200
KERN Last message repeated 2 times
KERN 'app_server'[17]: Radeon - Radeon_FindRom: found ROM @0xc0000
KERN 'app_server'[17]: Radeon - Radeon_CardDetect: found supported device pci index 2, device 0x1002/0x514c
KERN 'app_server'[17]: Radeon - init_driver:
KERN 'app_server'[17]: Radeon - Radeon_FindRom: Signature: R200
KERN Last message repeated 2 times
KERN 'app_server'[17]: Radeon - Radeon_FindRom: found ROM @0xc0000
KERN 'app_server'[17]: Radeon - Radeon_MapDevice: device: 010000
KERN 'app_server'[17]: Radeon - Radeon_MapDevice: old PCI command state: 0x00000087
KERN 'app_server'[17]: Radeon - Radeon_MapDevice: physical address of memory-mapped I/O: 0xe1000000-0xe100ffff
KERN 'app_server'[17]: Radeon - Radeon_GetPLLInfo: ref_clk=2700, ref_div=12, xclk=25000, min_freq=20000, max_freq=35000 from BIOS
KERN 'app_server'[17]: Radeon - Radeon_DetectRAM: 64 MB DDR SGRAM found
KERN 'app_server'[17]: Radeon - Radeon_UnmapDevice:
KERN 'app_server'[17]: Radeon - probeDevice: found Radeon 8500 / 8500LE / ALL-IN-WONDER Radeon 8500; ASIC: r200
KERN 'app_server'[17]: Radeon - probeDevice: making /dev/graphics/1002_514c_010000

Should it work???

USB, AGP, Radeon IGP - no effect here

By SD - Posted on July 23, 2004 - 14:01:24 (#13524)
Current version when comment was posted: 0.01

Tried to switch this option ON/OFF in my R40e (BeOS MAX + BONE + USB.patches).
No difference, all works fine.
So in your case, boyz, i suspect Zeta's usb stack, especially their ehci driver. removing that driver helped to solve lot of problems - with scanners. with usb sticks and card readers etc.

llama, cool!

By trasnam - Posted on July 23, 2004 - 13:49:04 (#13523)
Current version when comment was posted: 0.01

Hey, I saw that setting in my BIOS too, but figured "well, changing that to off couldn't possibly fix my problems." I'll be sure to try that later on today and report back. Kind of makes sense, considering I was having problems with the OHCI part of USB a great deal of the time. Hopefully turning legacy USB off brings back the stability that was hit or miss before.

By SD - Posted on July 23, 2004 - 13:44:42 (#13522)
Current version when comment was posted: 0.01

this is NOT legacy options.
Rather opposite:)
Actually that options is BIOS built-in USB disks "driver". If you allow it, you can boot from USB mass storage. But that option made lot of problems for me before, even for mouse and keyboard.
Also, please post your notice to Radeon talkback.
Maybe other radeons problems are realated to similar problems, too.

It's working!

By llama - Posted on July 23, 2004 - 13:40:38 (#13520)
Current version when comment was posted: 0.01

My IGP chipset is now working fully accelerated! After talking to SD on beshare he suggested I turn of legacy usb support in bios. After that the driver works fine! Thanks everyone for all your help in getting this going! I'm a happy man :-)

Cheers,
llama

Re:MAX - offtopic

By SD - Posted on July 23, 2004 - 11:53:18 (#13516)
Current version when comment was posted: 0.01

really offtopic - contact me at beshare server (use Unizone program if in Windows) - my nickname is fyysik there.

Installing MAX

By llama - Posted on July 23, 2004 - 02:09:33 (#13515)
Current version when comment was posted: 0.01

Hey SD,
A bit off topic I know, but how did you manage to install MAX on your R40e? If I use the standard boot floppy image it loads all icons then sits there with a blank screen. If I use the replacement ide boot image it doesn't boot. Is there a trick to it? (btw, the old version of MAX loads up until the EULA but then my keyboard and mouse lock up so I can't go any further)

Dano installs fine however. I really want to get this driver working! I know it must work cos we have the same laptop :-)

Cheers,
llama

transam117 - try MAX definitely

By SD - Posted on July 23, 2004 - 00:42:11 (#13514)
Current version when comment was posted: 0.01

It is only system which appeared to work flawlessly on my laptop (with IGP card, btw).

Only difference from standard BeOS MAX is USB.patches (from beshare) - to allow USB storage by Siarzhuk to work.



	Comment Pages: << prev \| 1 \| 2 \| 3 \| next >>













			Recent Downloads - # 661 Total Downloads - # 351 Total Views - # 69 User Ratings - # 5




			Video Drivers




			1. BePodder - 9.80 2. QEMU - 9.68 3. ScummVM - 9.57 4. cpu_fix - 9.42 5. Jukebox - 9.40 6. libdl.so - 9.40 7. Haiku AGP busm... - 9.35 8. vim6 - 9.31 9. Beezer - 9.26 10. HandBrake - 9.25




			1. BeOS 5 Perso... - 13,534 2. Realtek RTL8... - 13,074 3. Ati Radeon G... - 12,511 4. Ensoniq Audio... - 7,530 5. ATI Rage 128... - 7,426 6. USB Joystick... - 5,632 7. Broadcom 440x... - 5,396 8. USB Serial dr... - 4,700 9. S3 Trio 64 v2... - 4,697 10. Intel Extreme... - 4,457




			You are not logged in. Login


	Unless otherwise noted, everything is copyright © 1999-2009 Haikuware. All Rights Reserved. For more legal trivia, take a gander at our Legal Stuff page and our Privacy Statement.