behold: Rudolf's corner

Moving to another internet provider..

2009-05-11T10:09:00.002+02:00

Hi there,

Currently I am working on moving to another internet provider. This means my Email adresses and homepage will go into oblivion. The locations that is, not the content. :-)

Anyhow, please take note of the mirror site's adress and of this weblog since these two will remain operational.

I'll post more news once it becomes available.

Greetings!

Rudolf.

Something else - Logitech Z680 mod for lower Bass output

2009-01-25T13:00:00.026+01:00

NOTE: If you execute the modification suggested below and you blow-up your set, you are on your own! I can give no warranties of any kind whatsoever...

Hi,

Ever since I can remember I have a Logitech Z680 5.1 audio set which I use to watch movies and listen to my music. It was the top-of-the-line audioset for PC's from Logitech way back, there's a follow-up top-set now: The Z5500.

This (Z680) is an audioset with integrated Dolby digital and DTS decoder and it has a remote as well. You can input audio using 3.5Inch jacks, but also using coaxial or optical cable. You can choose from 3 input signals using the remote so I have the set connected to my stand-alone DVD player, but also to an old stand-alone audio set with CD player.

On the Z680 (one of) the downside(s) is that you cannot set the sub-woofers volume between 0 and 100% in small steps. Instead you can set 0%, and about 60-100%. On the Z5500 this limitation was removed BTW.

A lot of Z680 users including myself found that the 60% setting of the subwoofer is much too loud for most (living) rooms: Neighbours will complain about pictures falling of their walls, and the sound is not optimal for the user him (or her)self either.

So, I decided to take my set apart and modify it to be actually useable. I did two modifications: for one I added a RS232C interface in the hope I could (re)program the set some way. This RS232C interface was there on the board already, it just missed a few components placed though. Unfortunately the set's firmware does not have RS232C connectivity I found out.

The second modification, which is much more low-level, worked like a charm for me. I'll decribe that modification below.

Z680 Modification for a lower bass setting range.

The control POD of the Z680 has all digital inputs and the decoders. After all signal processing is done, the audio channels are converted to analog signals. These analog signals are then transferred to the bass speaker housing via the 15-pins thick black signal cable. In the bass speaker housing sits the analog amplifier that cranks up the signals so you can hear them from the speakers.

This means lowering the bass signal range can be simply done in the control pod at the exiting spot to the amplifier. I just located the signal wire for the sub-woofer speaker and took the wire loose. I then added a simple resistor network which divides the voltage to 1/3rd of the original level, and I attached the signal wire to the output of this divider. (The input of the divider is connected to where the wire was before.)

Since the voltage is now 1/3rd of the original, the current through the speaker is also at 1/3rd of the original which means output power is 1/3 * 1/3 = 1/9th of the original for a specific volume setting.

Now I can set the volume perfectly for my taste!

Photo's and a more detailed description.

Before you start make sure you have the following:
- a screwdriver
- a soldering iron
- soldering tin
- two resistors: one of 1k-Ohm and one of 2k-ohm or there about. 1/8th Watt versions will do nicely.

First, remove mains power and take the Z680 control POD loose from the set and any extra wires. Now remove the four black screws at the backside: make sure you removed them completely (take them out).
After you did this, you can gently pull of the front panel. Please note that a wire sits in between the front panel and the mainboard which will remain in the back part of the housing: so be gently indeed!

Picture 1:

The four black screws removed completely and the front cover removed gently.

You can see the dark-grey ribbon cable that connects the frontcover part with the POD's mainboard. Note that the light-grey ribbon cable will not be there in your case: this cable belongs to the RS232C modification I did.

This RS232C modification is not needed.

Once you have the situation as shown in picture 1 you can pull-off the dark-grey ribbon cable gently so the front-panel part nolonger bothers you while you do the modification. Please note the red wire in this cable as it denotes PIN1 of the connector (has a small triangle pointing at it on the mainboard if you look closely).

OK. Now you should gently pull the mainboard from the back part of the housing. Please note that at the backside of the mainboard there is a soldered connection to the thick black wire that normally connects to the Bass speaker's housing. Lift up the mainboard (including the other boards that sit on it) and gently turn it over.

Once you did that you'll be in the situation of Picture number 2 below.

Picture 2:
mainboard removed from back part of the housing. Again you can see the light-grey ribbon cable that belongs to my RS232C mod.

You'll not have that in your situation.

Below there's a closeup picture (3) of the situation in picture 2. Please note that the area of interest is where the black cable is soldered too. Please note the white characters printed on the board denoting (among others) the analog channels that are outputted on the respective wires:

+8 - +8V 'logic' power supply
G - 'logic' supply ground (return)
SB - ??
G - signal ground
RR - Rear Right speaker channel
RL - Read Left speaker channel
C - Center speaker channel
S - Subwoofer speaker channel - this signal we are going to modify
FR - Front Right speaker channel
FL - Front Left speaker channel
G - Signal ground
G - Signal ground
-18 - -18V analog power supply
G - analog power supply ground (return)
+18 - +18V analog power supply

Picture 3.
The area of interest, specificially the 'S' wire and the two G wires next to each other next to -18V.

Now flip the board so the other side faces up. Now Heat up your soldering iron and remove the brown wire that's soldered to the 'S' connection. Solder the 2K resistor (or 2 1k resistors in series as I did) to the S connection of the board leaving the other end free in the air.

Solder the 1k resistor with one side to the 'G' connection(s) next to the -18 signal as these G connections are closest by. Make ABSOLUTELY SURE you don't connect the -18 with the G next to it by accident! You'll probably blow-up the power supply in your set if you'd turn it on in such a case...

The other end of the 1K resistor needs to be soldered to the free end of the 2K resistor. Also connect the loose brown wire to this point. If you do it as neat as in picture 4 you can leave it as it is: it will fit nicely in the housing this way without making shortcuts.

Picture 4:
The board is flipped over showing the modification done to decrease the subwoofers power level.

The next picture shows the same modification from a different angle. Note BTW that I removed some of the white transparant 'glue' to be able to solder decently..

Picture 5:
Same spot viewed from a different angle.

OK, that's it!

Now put the control POD back together gently, keeping an eye on the modification and where you put the black cable. Re-attach the grey ribbon cable with the red wire at the same spot is was before. make sure all pins are indeed in the connector: no pins should be visible next to the connector's sides!

Gently put the top side on the backside: it should fit perfecly. If it does not, you probably made a mistake somewhere and you should just do it once more.
Put the four black screws in the backside and screw everything back together.

All set? Reconnect mains power and try your set. If it doesn't work remove mains power quickly and trace back all your steps to see if you made any mistakes, maybe it can be fixed.

If all is right it should work without a problem.

Variations:

You could also use other resistor values for more or less attenuation to fit your needs. I suggest to keep the values in the range from 1k to 10k Ohm and not much higher since the impedances of the circuitry around it are 'low' as well. It's said in the electronics that you get the best power-transfer if the impedances match..

Good luck!

Rudolf.

New cards on my block..

2008-05-26T19:30:00.003+02:00

Hi there,

I've not been working on 3D much unfortunately, nor with the 2D driver.
There are some very recent developments however.

I've been in contact with BeOS/Haiku developer Matt Madia lately, and he decided to send me two new gfx cards to 'thank me' for my previous work (as he wrote). The cards are a Geforce 7300LE (G72) and a Geforce 8500GS (G86), both for PCI-E.

Also I'm working on finding the Haiku problem with my driver that makes the acceleration engine inoperable (not yet done). In the meantime I came into possesion of a P3-600/FSB133 Mhz system and a second computercase that's still empty.
Seems I'm going to have to arrange for a PCI-E mainboard now so I can test with the two new cards and fork the nvidia driver to create a second one for the G8x series cards... It will probably be a Asus Intel P35 chipset board with two PCI-e x16 slots, a PCIe x1 slot and some PCI slots so I have maximum flexibility for gfx testing for Haiku/BeOS.

Still, time is and will remain limited in which I'll do this stuff. I'm curious how effective I can make it..

Well, it's fun playing around a bit again, that's for sure!

Matt, big thanks for those cards you sent me!!

Oh, about 3D. Seems there's a newer versioning system used much for Linux these days called git (Mesa3D, the nouveau driver among others). Unfortunately there's no BeOS/Haiku port which makes accessing sources I need for 3D dev hard to do. Still, I could download some stuff using an early windows port and it's an interesting read.

The next step I need to take for 3D is finding out what the exaxt format of the nouveau_vertex structure is, as I need to create and feed those in the NV15's engine. If anyone accidentally knows where to find that info, please advice :-)
And if someone would want to port that versioning system, rest assured I'd be using it to checkout some interesting sources...

Have a look here:
http://git.or.cz/

Bye!

Rudolf.

3D.. testing testing..

2008-02-17T21:44:00.002+01:00

Hi,

Just so you know: every now and then I'm fiddling with 3D support improvement. The high-level interface I wrote about two years ago is 'nothing more' than a new 3D command in the engines. This command is called TCL_PRIMITIVE_3D, and I'm testing it on a NV15.

I already noted some time ago that the command NV11_TCL_PRIMITIVE_3D is responding on my NV15: I can set the colorspace for the back colorbuffer. I can also set the Z buffer range on the card and apparantly most other stuff without hanging the engine. The old 3D command keeps rendering nicely as always so that's good I think.

Just one thing is hanging the engine: setting the 2D window position. Well, I'll leave that disabled for now since it's working anyway on this card.

Tonight I find myself at the spot where I need to actually try to render using the new command. Which means I'll now shut-down the old 3D render command and test the new one. The coming time that is..

I have to admit I'm feeling exited about this. Will I actually be able to get this thing going or not? And: will it improve speed for Q2 and the teapot? And after it works on NV15: could NV20/NV30 be made to work?

Interesting stuff. Anyhow: little time to work in, lots to do. (as usual ;-)

Bye!

Rudolf.

G80 support remains non-existing for now.

2007-10-28T20:55:00.000+01:00

Hi there.

No news about 3D yet. Seemed like I had to add support for more cards to the 2D driver first. I synced the driver against nVidia's april 2007 ID list which meant adding 24 more cards (one extra was reported by a user).

Anyway, some 'bad' news I have I guess:

After testing on a G86 laptop, looking at the logfiles, and looking at the X.org nv driver code I decided to block G80 and higher support in the driver's accelerant.
Since the 2D accelerant is becoming crowded anyway with all those cards with little differences in them, it seems to me we need to create a new, seperate accelerant (and maybe kerneldriver too) for G80 and higher cards.

These cards have new CRTC's, DAC's and accelerant engine I think. It won't do the current driver any good (readability for one) to add support for this more extensive modified hardware.

If anyone is up to the task, I guess it's a good starting point to copy the current nvidia driver and start tweaking that copy to only get G80 and higher support. That would mean a big cleanup to that version of the driver I guess... ;-)

Since I have no hardware to work with (and of course little time) I won't start on this myself now.

This means the current 2D driver just needs to have the ID's added for all new, but pre-G80 cards that are left. And of course this driver could still have some functional gain in the future, like more 2D accelerated functions.

The driver now has version number 0.84.

See you later!

Rudolf.

3D is running OK again over here :-)

2007-09-18T21:31:00.001+02:00

Hi there!

Well, the 3D accelerant Alpha 4.1 is running correctly again over here: just saw the 152fps timedemo2 going well :-)

As it turns out something changed with the compiler (or so) indeed: I had a enumeration list of TVencoders defined inside shared_info: apparantly this list gets (more/less) room assigned to it in shared info with the result that every entry coming after that pointed to 'nothing'. When I released the 3D accelerant compiling both the 2D and 3D driver gave the same result in both: the driver worked. These days however the 2D driver compiles differently, so I had to move this TVencoder list outside shared_info to correct the problem. I only had to do so inside the 2D driver: the 3D driver (originally compiled version) then works correctly again.

Strange. However, I'm glad I nailed it down now. This was irritating me for quite some time. :-)

This means I can have a look at the Linux world now to see XFree's current card ID's (we're much behind I guess) and the 3D nouveau attempts. For 3D I think I'll try to modify a 3d accelerant command to use the high-level interface on the NV15 card here and see what happens.

When I again have some time that is :)

Oh, SVN has the fix of the above described problem now of course.
And: my public Email adress is up again.

Bye!

Rudolf.

Wow, I missed something.??

2007-09-11T21:00:00.000+02:00

Hi,

I was very surprised to learn this week that AMD bought ATI? And on top of that, there's talk of AMD opening up specs (or a opensource driver?) for 3D specs for R500 and up? I didn't expect that!

And Intel is now maintaining it's own opensource 3D driver for Linux?

I knew already, but it's confirmed once again: a lot can happen in a year time! I'm very curious what nVidia is going to do if this ATI thing is going to happen.. (Ok, nothing probably ;-)

Anyway, time will tell, as always.

I'm trying to get my 3D driver going again on my P4-2800 system, but I seem to have a shared_info problem. if I recompile the 2D driver it's no good when 3D runs, while the old compiled 0.80 driver works OK.. What changed in haiku?

As we speak I'm trying to checkout the complete trunk so I can recompile from scratch (or so) to see what happens. If I get it going again I want to give the high-level 3D engine setup a spin (if possible), I want to see what nouveau has come up with in the past one and a half year in this respect.

Mind you, I have just a few hours per week to spend, so nothing might actually happen. Still: I am interested in this.

Oh, I am trying to get my 'public' Email adres up again (the one still listed on my homepage). Might come in handy again.

Until later. :)

Rudolf.

A new age.

2007-06-15T20:10:00.000+02:00

Hi there,

It's been a while since I wrote here. It feels like years have passed..
Thanks everyone for the kind responses you gave me back then, it meant and still means a lot to me.

I'm happy to see Haiku remains being developed towards a first official release, still can't wait to see that day coming. In the meantime I didn't code a single line myself ..

Well, at least I've been able to keep my homepage online, and this will remain so I expect since I could succesfully transfer it from my old provider account to a new one some weeks ago.

Maybe I'll even be able to write a few lines of code for Haiku's drivers in the future. Though I still need to setup my 'old' equipment a bit for that. I guess only time will tell what will come of it.

In the meantime I did not get messages from people wanting to take over driver development, so all hardware remains in my possession for now. I'm curious when we'll see that situation change btw.. :-)

I have to confess that I am looking to the ReactOS site every now and then: maybe you've heard of it: it's a opensource Windows clone running native Windows apps and drivers. It looks like a viable alternate OS to Windows for the future to me. If they don't get 'killed' that is.

Anyhow: I am a Haiku/BeOS fan myself when it comes to coding, and I love the community.

I haven't got more to say at this time, so I'm signing off now. If and when I got some news, you'll no doubt hear of it some way or another. I'm still curious to that higher level 3D engine a bit..

Until next time.

Rudolf.

Oh, my 'public' Email adresses are still off-line and will remain so for the time being. Bye!

It's been fun...

2006-06-01T11:00:00.000+02:00

Hi all.

The time has come for me to make a statement about my future concerning BeOS/Haiku. I owe you that I think, since I've been a very regular contributor to this community upto now.

I've been on holiday for a few weeks in Spain just now, in a tiny place where 'time stood still' so to speak. The old village where I stayed is situated in the mountains. There's nothing much to do there, except enjoying the overwhelming nature, do long walks, think, talk with the people I travelled with, eat a orange here and there, and drink a beer. Much in contrast to my busy 'normal, daily life' back home. And much in contrast to 'normal' holiday 'resorts' I tended to visit. Being in this village has been an experience I will *never* forget, it's changing my life. It's good. I feel it in my heart. I have to follow this new path unfolding before my eyes. It's my destination. It's real life. I love it, I need it.

About my (future) contributions for BeOS/Haiku.

As you all probably know, I've spent most of my freetime on BeOS related development. This means that other aspects of my life have been 'neglected' a lot. I've always felt it deep down and I knew it had to change someday. Well, that day has come.

So, I'll nolonger work on all those drivers much. Maybe even I'll quit alltogether. I'll keep following Haiku progressing towards a full, useable 'replacement' operating system for BeOS though. I really hope it will succeed. I love those systems. They are intuitive and easy to use. They make using computers a breeze. Unlike using Windows or Linux which scare me away and make me feel frustrated.

Here are my suggestions:
- I'll do one more Matrox driver release pending updated TVout support completion for G100 and G200 cards. There's not much work left todo for that.
- I now nolonger support any of the programs and drivers I wrote, apart from maybe tiny patches like adding cardID's and such which virtually cost no time to do.
- For the nVidia driver I might continue to do a bit more work for now though: I'm talking about testing a bit with 3D support for newer cards so the new Linux open DRI driver has an improved chance on success. The efforts I'll do are minimal though: only a few nessesities and only if I can manage this while putting in small amounts of time.
- We (the BeOS/Haiku community) need (a) new maintainer(s) for all stuff I did, including for the nVidia driver. I won't be responsible any longer for these items. I might be able to guide someone a bit though every once and a while.
- I have a few items here that can be given to new maintainers: a VIA Nimble V5 and several Matrox graphics cards.
- nVidia hardware I'll probably need a bit longer for those 'final' 3D tests. Some cards can be given to a new maintainter in a bit of time though: and some I'll keep because I had to purchase them. Unless these will be payed for.
- a General 3D related thought: For 3D support I suggest 'porting' Linux DRI drivers back to Haiku 'in the end', including the new nVidia DRI driver that's in the process of being developed. My nVidia driver is probably best left alone in the end, since it's based on an very old version of MESA. It's just a proof-of-concept, along with a good testing bed for hardware knowledge development (for the new DRI driver 'for instance').

Conclusion.

So, that's about it! It's been a hell of a fun ride! I've given my *very* best efforts to this community, I hope you see that. I don't regret having done that, though it came at a cost. This was a (technical) chapter I needed in my life. it's done now however.

Before continuing life, hopefully finding inner tranquillity; Before continuing life in a much more complete, sensitive, loving and personal way, I need to do some soul searching. So, I'm taking a time-out. I'll probably not respond to Email much.

Thanks for your awesome support people!!

Kind regards, and the very best to you all.

Rudolf.

3D driver Alpha 4.1 / 2D driver 0.80 benchmarks

2006-04-18T10:43:00.000+02:00

As promised, I posted the benchmark results on the nVidia 3D news page for 3D driver Alpha 4.1 combined with 2D driver 0.80. Have a look there for the details. I've placed a link at the left column of this blogger page that will take you there.

About my driver's pages:
I'll try to update them a bit more in the coming time as it's all very much outdated these days. I'll probably take down some stuff and point at Haiku's bugzilla and the Bebits download entries instead, since that's more official anyway and saves me updating efforts at the same time.

That's it for now. Seems I can now work a bit more on the videonode related stuff. See you later !:-)

3D rendering speed now upto twice as fast!

2006-04-07T22:58:00.000+02:00

As some of you already know, 3D rendering speed went up with a factor of 1.4-2.0 on all supported GeForce style cards. TNT2(M64) render 1-4% faster, which is not very impressive compared to the GeForce speedup: but nevertheless noticable in some occasions.

The 3D driver renders at approx. 40% of the Windows driver speed for TNTx style cards, if the Windows driver uses the same setup as our BeOS driver: blits for swapbuffers, 16-bit texturing and disabled retrace-sync. For GeForce style cards, the driver now runs at approx. 30% of the Windows driver speed.

Needless to say I think, is that I am very happy with the big improve in speed we now see. If you compare different cards for speed using Windows, and you put the results of that next to a comparison in speed using BeOS: you'll find that the relative scores are starting to match! In other words, if a certain card performs fastest in Windows, it will now also perform fastest in BeOS..

Hey, what happened?
Well, after finding the results of the delta-speed test I did, I (once again) did a sweep of the engine init code in the 2D driver. Only this time, much more detailed than ever before. And then I found what I needed: just a few tiny bits needed toggling to get the new speeds! Don't really know what they do though.. We had sub-optimal settings, especially for GeForce cards. When you think about it, it could have been expected, as the UtahGLX driver my work is based on was very old: first created probably in the pre-GeForce era.

Anyhow, I did the sweep on all cards I have here, so TNT1, TNT2, TNT2-M64, GeForce2MX, GeForce2Ti, GeForce 4MX440, and GeForce 4MX4000. I am very sure the init setup code is now optimal speedwise. Of course I also looked at degrading quality: but that I didn't see. This combined with the speed comparison against Windows (for all those cards) leads me to believe this should be perfectly OK now.

So, thinking about how the engine's inner workings are: those ROP's in there (parallel raster outputs) are all working already. So two on most cards, and four on the GeForce 2Ti cards. The new speed comparisons on BeOS confirm this (more or less).

Release?
I'll release a new 2D driver asap: probably current SVN version 0.79. I'll also recompile the Alpha4 3D add-on against it and publish the combination as well as Alpha 4.1. Note: the 3D driver has not changed one bit, it's just that the shared_info in the 2D driver was expanded with a new (unrelated) nv.setting: that's why the recompile is needed.

Furthermore I'll publish a new benchmark table with all those results on both Windows and BeOS. Still done with Quake2 timedemo 1 (with sound running), as I always did: you can easily compare it to those old Alpha 2 benchmarking results I published.

The new benchmark table will be on the driver's homepage (3D news page), instead of here though. Just so you know.

So, why are we not yet at 100% of 'Windows' speed?
Well, there are a number of things to account for that.

1. The acceleration engines are still idle at times during rendering, even on the faster CPU systems. This has to do with the bursting nature of those vertices being sent, and can only be fixed by using a higher-level interface to Mesa. Luckily Mesa3.4.2 turns out to have this interface, so I'll try to interface to it for a later Alpha release. This interface sends entire GLbegin()/GLend() sequences in one call to the driver, instead of the current one-triangle-per-call system. Furthermore this higher-level interface is needed for current Mesa as well, so interfacing to that would be a 'translation step' for me: which is good. :-)

Having this higher-level interface in place might very well increase rendering speed with a factor 1.5 or so: even (much) more so on slower CPU systems. Of course I'm guessing a bit about the possible speedgain at this point.

2. on TNT style cards, no more gain is possible: this high-level Mesa interface needs to be translated down to the current low-level hardware interface: sending seperate triangles.

On GeForce style cards however, this higher-level interface Mesa has, is also supported in the hardware!. This means that in theory it's possible to tell the engine what type of primitives we want to render (at GLbegin() time), like seperate triangles, tri-strips, tri-fans, and all other styles GLbegin() supports. The nice thing about this is of course, that we don't need to send seperate triangles to the engine, but just the vertices needed to describe the primitive we want to render (so literally like the app does that sends the commands).

Seems that this would save the driver sending tremendous amounts of redundant vertices: after all, in a real scene a lot of triangles have sides in common.

(Example: a quad. sending seperate triangles means we need to send 6 vertices, while a quad by itself only needs 4 vertices to describe it.)

(Example 2: a cube. There are 8 vertices needed to descibe it. Now break it down in seperate triangles, we'd need 36. Right?)

Well, this would increase rendering speed: can't miss. And the (very) good news is, that we might even be able to get this hardware interface up and running! Thanks to a very new open nVidia DRI driver attempt that is...

How about maximizing effective use of the RAM-datapath-width?
We talked about this a bit: about how fetching a single point (pixel) would waste valuable bandwidth, and how a crossbar memory controller could improve effectiveness by using smaller 'lanes'. Remember? Well, that crossbar controller was invented for GeForce3 and later: so we can't be suffering from that.
No. It turns out that it's like this:
- the hardware already maximises effective use of bandwidth! After all, we are not drawing single pixels, we are drawing 'entire' triangles! These consists of a large number of pixels (most of the time), so the engine can 'auto-optimize' access by doing parallel pixel rendering!
- a crossbar memory controller only comes in handy when you render lots of very small triangles: here the internal engine parallelisation fails (we deal with just one, or a few pixels). So, this crossbar controller is needed for next-generation games, where much more (smaller) triangles make up a scene. Makes all sense now, no?

So, we don't have more bottlenecks than described just now (those two), apart from probably some extra Mesa software overhead caused by the fact that we will 'never' be able to utilize all hardware tweaks and features that could exist in the cards: lack of docs (and time), as ususal.
Personally, I can live with that. I mean, if those two bottlenecks could be fixed, I'd be very satisfied. Ah, I'm glad with what we have already now as well... ;-)

Have fun!

RAM access bandwidth test for 3D in nVidia driver

2006-04-03T22:33:00.000+02:00

I promised to tell you about that 'delta speed test' I did with the 3D driver, which I did to get a better idea about how fast the RAM could be actually accessed by the 3D part of the acceleration engine. I considered this interesting because the 3D driver was rather slow compared to it's windows counterpart.

So how did I test?
It was rather simple, really. In the previous post I did I already 'calculated' some numbers for RAM bandwidth, and bandwidth needed by the CRTC to fetch the data to show us the memory content on the monitor. So I thought, if I can ascertain how much fps is gained by stopping CRTC accesses to the memory, I also know how much fps is theoretically feasable if the engine could use the complete bandwidth.

In a formula
(total RAM bandwidth / needed bandwidth by CRTC access) * (fps without CRTC accessing memory - fps with CRTC accessing memory) = nominal fps rate possible.

The setup
Just modify the 2D driver to enter DPMS sleep mode as soon as the cursor is turned off, and enter DPMS on mode when the cursor is turned back on. DPMS sleep mode in facts sets the CRTC in a 'reset' state since it's not required to fetch any data anymore: we won't be looking at it anyway (monitor is shut off). So this DPMS sleep state gives back the memory bandwidth otherwise used by the CRTC, to the 3D engine.

Since:
- you can start Quake2 from a terminal 'command line', including instructing it to do a timedemo test,
- you see the fps results back on the command line after game quitting and,
- starting Quake2 turns off the driver's hardware cursor, while stopping it turns it back on,
This setup will work nicely.

Result for the Geforce4MX, NV18
(6000 / 225) * (29.9 - 26.3) = 96 fps. (Windows measured value = 119 fps)

Well, for my taste this proves enough already that RAM access is actually OK, and the fault would not be low clocked RAM or something like that. So the reason for slow fps on BeOS should be found somewhere else.

Conclusion
Why is the delta speed with the CRTC test actually OK, while the total rendering speed is much to low? Well, it's interesting to realize that CRTC accesses are spread evenly through time, while 3D engine memory access requests are of a bursting nature.

The conclusion would be that there's some bottleneck in the GPU somehow after all... And with this new knowledge I went to sleep, not knowing yet what to make of this new information.

3D add-on Alpha 4 released..

2006-03-25T21:05:00.000+01:00

Hi,

Well, it's done: Alpha 4 is outthere. I had to do a lot more work than I anticipated, hence the delay. But it's well worth it I think: a lot more bugs were solved. In other words, Quake 1 and 2 showed more rendering errors after all, just less easy to see for someone not much running games (yet :).

The driver entry on bebits contains a list of all errors solved, so just have a look there for the nifty details, or just download Alpha 4 and read the included HTML file (which contains the same list plus updated application running status info).

What can I add to that info?
Well, rendering speed is higher than ever before, although still slow compared to windows and linux closed source drivers. But I mentioned that already as well. I'll try to do a new benchmark using Alpha 4 to give you the current detailed results: that way you can (finally) compare it to old Alpha 2 speeds I once gave.

GPU and RAM speed (overclocking and bottlenecks)
Let's talk a bit about rendering speed and bottlenecks. I spent a lot of time to find out why the speed is so much slower than on Windows and Linux closed-source drivers. I also tried to get NV20 and higher going once more. I did not find the solution to either problem, but I learned more about the cards and windows drivers in the meantime: who knows, it might help one day.

Anyway, one of the things I did was add tweaking options for GPU and RAM clocking speed in the 2D driver. Of course the 3D driver also benefits from this, and that was the intended result.
I did a test on my P4 at 2.8Ghz/533Mhz fsb, using the GeForce 4MX 440. This card has BIOS settings 275Mhz clock for GPU and 400Mhz for RAM. Coldstarting the card revealed that these speeds are actually programmed.
Here's the result of testing GPU speed with RAM speed at default (400Mhz):
GPU speed, Q2 timedemo1 fps in 800x600x16 mode (Alpha 4)
50, 38.8
100, 66.2
150, 78.8
200, 82.8
275, 86.0

I find this interesting, doubing the GPU speed did NOT double the rendering speed. Now look at RAM testing with GPU at default (275Mhz):
RAM speed, Q2 fps
100, engine hang
150, engine hang
200, engine hang
250, 55.7
300, 66.4
350, 76.4
400, 86.1
450, 92.9 (overclocking 12%!)

Interesting here is the fact that increasing the RAM with a certain percentage, increases fps with the same percentage! When we combine both tables, we can conclude that the RAM access speed is the bottleneck, not the GPU speed. When you benchmark Q2 some more using different settings for texture filtering this conclusion remains intact: fps is not influenced one bit depending on filtering. At least, the GPU doesn't care.

About the engine hangs at low speeds: most RAM used on graphics cards is of the dynamic type: it must be refreshed within a certain amount of time to keep it's content. When it's done too slow the content gets damaged: hence trouble.

So, why is RAM access the bottleneck?

background: RAM bandwidth considerations
So how much data can be transferred with RAM anyway? Well, raw speeds look like about this.
the NV18 (most cards as a fact still), have a 128bit wide path between GPU and RAM. This means that per clock-cycle (SD-RAM) 128/8=16 bytes data are transferred. If we have a clock of 400Mhz, that means 400.000.000 * 16 bytes = 6,4Gbytes/second can be transferred.
We need to deduct some room for refreshcycles, so let's say for argument sake we keep about 6Gbytes/sec bandwidth for our card's functions.

So which functions are running? Well, we need to send RAM content to the screen (monitor). In 1024x768x32 mode at 75Hz refresh that means 1024*768*4*75 = 225Mb/sec are transferred.

This leaves some 4.8Gbytes/sec bandwidth for the GPU accesses and CPU accesses combined.
Note that when you run for instance Quake2 timedemo, that at first the textures are loaded into the cardRAM, and then the demo starts running. Running the demo nolonger transfers data between the host system (CPU) and cardRAM: everything needed is already there. Apart from the actual rendering commands that is, but these are a relatively small amount of data: which resides in main system RAM, and are fetched by the GPU directly (AGP DMA accesses). So these commands don't load the RAM bandwidth. Just the GPU.

Bottleneck identification?
One serious 'problem' with these calculations is the fact that the GPU not always needs chunks of 16 bytes (128bits, the width of the datapath, data transferred in one clock-cycle). If you render using a 16-bit Z-buffer, and some serious hardware access optimisation doesn't exist, those two bytes will cost 16 bytes worth of bandwidth. In other words: these accesses run at 2/16 = 12,5% of maximum speed. For a 32bit colorbuffer, this would be 4/16 = 25% speed.

This could be what we are looking at. Unfortunately, I don't have a clue how to engage optimisation in the GPU for this kind of stuff: the crossbar memory controller (if it exists in those cards, this I should check in the coarse specs from nVidia). This piece of hardware is capable of splitting up those 16 bytes in seperate smaller lanes so to speak.

On the other hand, this same problem should exist on TNT class cards: but we are running at relatively high speeds there already compared to GeForce class cards. If you look at the windows driver results. But then again, there might be completely other reasons for that. It remains sort of guessing.

So, how are those speeds again? I'll sum a bit up once more (for the P4 2.8Ghz system at 1024x768x32 mode):
card, windows (blit-swapbuffer function forced, 16-bit textures), beos ALpha 4
TNT2 (ASUS V3800) , 41.3, 15.6
GF2MX400, 86.0, ---
GF2Ti, 165, ---
GF4MX440, 119, 26.3
(--- means: not tested)

So, the TNT2 works at 15.6/41.3 = 38% of max. speed. The GF4MX440 at 26.3/119 = 22% of max speed. Both cards have 128 bit wide buses by the way.
Note to self: so geforce class cards seem to be running at relatively 50% speed of the TNT class cards. Do we need to enable DDR (double data rate) explicitly?? At least more cards should be compared for this. I seem to remember the GF2Ti running at some 23fps on BeOS, which would be relatively much slower than the GF4MX440.

Indications for actual RAM access bandwidth on BeOS
I had in mind to give you the result of an interesting delta-speed test I did on BeOS, but that will have to wait until another day. Time is up for now. But I'll post it as next item, I promise. It's very much related to the above story after all!

In the meantime: have fun with 3D! It seems we can run Quake1,2 and 3 all on BeOS now. With acceleration...

Signing off. Good night :-)

nVidia 3D status update

2006-02-25T00:16:00.000+01:00

High-time for a status update I'd say. A lot has happened.

Resizing outputwindows and another BeOS bug
This function is implemented and working reliably now. However, that took some time: there turns out to be another BeOS (R5 and dano) bug here: when you enable Window resizing events in the constructor of the BGLview, the corresponding routines are called: but the new size given to the resize routine is NOT the new one! Instead the one before the latest one is given.. Needles to say it took a lot of testing and trying to recognize this bug. By the time I knew what was going wrong, I saw a workaround in Be's teapot code: not using the given size, but asking for it itself.
After I added this workaround to the driver as well, resizing worked correctly. But not before I added LockLooper()/UnlockLooper() calls to the routines LockGL() and UnlockGL(): this was the trouble I saw about resizing being asynchronous to rendering. So not a Mesa problem, but 'my' problem: syncing threads. Fortunately this solution was already there in current Mesa, so I just copied it over to my driver.

Resizing sometimes still temporary distorts the rendered output, but that's not very important. Although it could look better of course. The driver is not calling Mesa GLviewport or resize_buffer functions, that's a task for the application programmer (as can be seen in various code examples outthere). The driver only takes care of programming the card right. It's nice to see a very large Teapot spin around, and to recognize the speed effects of resizing it. :-)

Trilineair filtering: 'random' engine crashes
As usual (so I can say these days :-) BeOS Mr.X is 'betatesting' the driver for me. As he has a lot of knowledge about the Quake series of games and the console commands you can give them, he finds bugs rather easy compared to myself. One of the problems he encountered was that using GL_LINEAR_MIPMAP_LINEAR texture rendering in Quake2 hung the driver. After two days of searching I discovered what was wrong: the original UtahGLX driver I based my work on contained an error: the rendering quality setting was increased 'by one step' when rendering switched from textured rendering to non-textured rendering. Of course the driver meant to set a basic 'level 1' as textures aren't actually used then.

The driver crashed the acceleration engine because it was fed with an illegal setup: a non-existing filtering mode.
So: alpha 4 will have this problem fixed. And the really funny part is that I didn't even know the driver supported filtering in this area... But it does: you can choose no filtering, bilinear filtering, and trilinear filtering: all just a setting fed into the engine. Checkout the gl_texturemode console command for Quake1 and Quake2 if you are interested.

Quake1 touching keyboard hangs game.
Another interesting thing to have a look at. Since the sources of GLquake are outthere, I made it compile on R5 and dano. That turned out to be a relatively easy thing todo. After having the game run, I could now go on a bughunt for this error. It turns out that the keyboard routine is protected by a semaphore, which is also grabbed when a new frame is rendered. This is a bad situation apparantly, as rendering stops completely when the keyboard was touched. I could fix it anyway by modifying the game executable a bit: acquiring/releaseing the semaphore as close to actual rendering as can be (inside the LockGL()/UnlockGL() part instead of outside of it.) Still you see the keyboard lagging on high-res modes however. Anyway: it has to do. Unless someone else is going to have a better look ofcourse. (Enable the networking support someone?).

With Be's software GL the game did not hang, but then, this renders rather slowly. I could prevent hanging in the accelerated driver by adding a snooze(100000)...
If someone knows of a driver-way to overcome this problem I am interested in knowing: after all R4.5's accelerated GL did not suffer from this symptom.

Quake1 rendering faults.
While I was playing around with Q1, I decided to try to find the reason for the wrongly rendered game scores at the mid-bottom of Quake1's screen. I found it after another day or two: yet another 'original' UtahGLX driver bug. It forgot to send the active texture's colorspace to the engine when a new one was activated...
Oh, doing a timerefresh in Q1 console was strange to see as well: it rendered in the foreground buffer. As the nVidia driver doesn't support that yet, I modified this command to use the backbuffer so it's accelerated: it's nasty to have to wait for 128 frames when rendering a single one cost about a second or so.

Anyway: it makes more sense as well to have it render in the backbuffer as otherwise we would always see the 'distortions' of the engine building up the frames in plain sight.

Next up..
So: all in all all rendering faults for both Quake1 and Quake2 have been solved. I guess I should release an updated version of Quake1 to bebits (including source) so this game can be played using openGL once more on BeOS. It would be nice if someone could take it from there to update it for networking and such I'd say.

OK, back to work. I want to have a look at switching resolutions inside Quake2 (wich only works partly for some reason), and then comes the 'real' swapbuffer thing. Apart from these items the driver seems ready for a new release.

Talk to you later!

nVidia 3D: back on Mesa 3.4.2

2006-02-18T10:53:00.000+01:00

While searching for a good solution for that delayed swap I mentioned to solve drawing errors, I once again compared Mesa 3.2.1 and 3.4.2. One of the differences between them turns out to be the added Mesa feature to complete pending drawing commands right before a driver issues the swapbuffer() command.
In other words, I switched back to Mesa 3.4.2, as that solves the drawing problem neatly if I add executing that Mesa internal command in the driver's swapbuffer function.

Mesa speed
The reason for me to fallback to the older Mesa before (alpha 3.5) was the apparant lower rendering speed the newer version had. Luckily it turns out I made a mistake myself: I forgot to enable hardware accelerated Z-buffer clearing! Once I enabled that, speed came a lot closer to Mesa 3.2.1's. Mesa 3.4.2 is indeed a bit slower, but just a tiny bit now.
Of course, I wanted to see if I could at least come up with the old speed, so I started looking once more at the hardware rendering commands hoping to find something I could optimize a bit more. Well, I found something indeed. Instead of issuing the vertexes and drawing commands seperately, I now issue them in one single burst of writes into the DMA cmd buffer. Also I use other vertex offsets in the engine, so the last vertex written automatically points me at the first drawing command entry. This saves overhead in explicitly setting engine register pointers in there, increasing rendering speed a bit (5-10% less words written into the DMA cmd buffer). If only Mesa could send 4 points, 4 lines and 5 triangles in one call... then I could increase the burst to it's max increasing speed another few percents, and save software routine calling overhead a lot.

Vertical retrace sync
In the meantime I added a new nv.settings option in the 2D driver called 'force_sync'. This option is now taken by the 3D accelerant to enforce retrace syncing for the swapbuffers command. With a small addition to the 2D's driver acc engine init code, we can now instruct the acceleration engine to wait for a retrace occuring before coninuing exec of commands. This is a bit nicer than explicitly waiting for a retrace (by CPU), as this enables us to keep sending rendering commands to the engine while that engine wait for the retrace. One of the important things for optimum fps rates, is that we try to keep the engine's DMA command buffer 'filled' at all times... The app should stay ahead with filling of the engine emptying and executing.

This engine wait exists in NV11 and newer cards, so the driver autoselects the retrace sync method depending on card architecture.

Swapbuffers: swapping instead of blitting (copying)
Adding real swapping turns out to be a challenge! The reason for wanting to add this function is to remove some of the acc engine load (used for blitting), so that space-in-time becomes available for 3D acceleration.
Unfortunately, swapping requires a sync to retrace: the CRTC (cathode ray tube controller) part of the GPU cannot do a swap at all times, as it's very busy with data fetching while the screen is drawn. You need to issue such a swap during retraces, otherwise the point in time the actual switch occurs cannot be guaranteed (over here it typically delays some 100 'lines': this register holding the pointer is doublebuffered in hardware apparantly).
Well, you guessed it: if we have to wait for a retrace, then we waste valuable GPU time we could otherwise use for 3D rendering! This contradicts our goal of course... In effect we loose speed instead of gaining it.

So: is there a solution to this problem? Yes, there is I think (I still need to check this out though). On BeOS, all 3D rendering uses double buffering. We have the 'frontbuffer' and the 'backbuffer': two buffers. You could switch between those once rendering to the backbuffer is done. The backbuffer then becomes the frontbuffer and vice versa. The next frame will be rendered to the old frontbuffer, now being the backbuffer. You see the problem: we need to wait until the CRTC actually displays the new frontbuffer, before we can delete and render in the old frontbuffer.
The solution presents itself: setup triple buffering. When we use that we don't really care when exactly the CRTC switches to the new buffer, we leave the old one alone anyway! Instead we use the third buffer to render into... Of course we need to wait anyway if the CRTC needs more time to switch than we need to render one frame: I don't know yet how to sync rendering to this limitation.

All in all I don't know yet if swapping will make it into alpha 4: I want to see the thing actually work OK before I promise that. Oh, this solution has a downside as well (of course): we need extra graphics memory to hold the third buffer. Though that is no real problem in practice.

Resizing buffers (viewports, the output window)
This is another subject I am once again putting time into. The last action I took (late last yesterday evening) was determining that we have a hardware (sync) problem here! This is good news for me, as I should be able to fix that. Once I do I can retest the Mesa internal function for resizing buffers (and resizing viewports). Looks like Mesa deservers (much) more credit than I initially gave it: it's well thought out, internal sync wise. I was under the impression that hangs and render errors could occur with out-of-sync events like resizing output windows, but it might well be that this is not the case at all. I'm a happy camper.

If I can find a solution the the hardware problem, and Mesa's function for resizing works well enough (under heavy acc engine load): I'll enable driver support for resizing. This means the teapot can be stretched etc via resizing the window it spins in (unlike having the repeating pots pattern you see now). Also this means that apps that initially create very small buffers and resize later will work (without modification) now.

Conclusion
Well, it looks like this will be an important update: Alpha4. Although in effect the speed won't differ that much (upto 10% speed gain depending on CPU and GPU power: P4-2800, NV18 +10%, dualP3-500 NV11 +3%), there are a lot of visible bugfixes concerning rendering.

I hope this will stimulate people to do some more 3D apps... ;-)

Mesa 3.2.1 and accelerated 3D on nVidia (again)

2006-02-12T01:50:00.000+01:00

While working on updating the nVidia 2D driver for a new BeBits release, I decided to clean-up for 3D support. I tested a lot of register configuration settings with help of two cards in a system: I could never test as speedy as these days (nolonger reboots required).

Some 'nonsense' 3D setup where removed, and I could also find one point where more speed could be gained for 3D: I modified the rendering output colorspace from some 'special' type with different input/output spaces, to 'standard' ARGB32. This apparantly means less drawing overhead, which lead to a 11% rendering speedup in B_RGB32 space on my P4-2.8Ghz using the NV18 card. On my dualP3-500 with NV11 a 7% speedup was still gained. 15 and 16 bit spaces are unmodified speed-wise.

While I was very nearby the 3D subject again, I wandered off more into the 3D accelerant and Mesa3.2.1. I ended up trying to setup a real swapbuffer command (instead of using blitting), which could give us another 5% speedgain for all spaces in fullscreen modes. It still doesn't work correctly (I am thinking another Mesa bug..), but it gave me an interesting view on the rendering behind-the-scenes (seeing a scene being constructed in the backbuffer).

It became apparant to me, that although we have several drawing errors with Quake2 (missing texts, missing parts of text, missing bitmaps, intermittant missing crosshair and scores), these items were drawn none the less! As it turns out, the normally visible rendered buffer (with the just mentioned errors) is rendered in the background, then swapped on-screen, and then the missing pieces are rendered in the now obsolete background! Of course they are never shown, as after this final rendering part, the erase buffers command comes up...

So, I tried a delayed swap, and YES!! Q2 renders without any drawing fault (32bit mode atm)!

This sudden success means I'll put some more time in the alpha3.5 3D add-on, and see what I can do to modify it for general improvement here: I am hoping I can get this incorporated so that it's still useable with other 3D apps as well. I will update the BeBits entry to be Alpha4 after I release the 'current' 2D driver, hopefully with both the 'perfect draw' and the fullscreen swap function in place: all in all for instance 1024x768x32 mode in Q2 would go up from 22 to 28fps then, and without drawing errors anymore.

Well, 'back to work'. Talk to you later!

official Be drivers and multiple cards

2006-01-24T10:40:00.000+01:00

I've been playing around a lot lately with multiple graphicscards in one system, seeing what happens if you try to use the second (or tertiary or whatever) card in there. It turns out to be quite interesting, a lof of things happen I didn't really expect.

What card will be used by the BeOS to display the Desktop?
If you start a terminal session, and type:
ls -l /dev/graphics
You'll get a list of kerneldrivers currently loaded for graphicscards. The first one listed is tried first by BeOS. If it determines that one doesn't work, it will try the second one listed etc. 'Stub' is not a real driver, but a fallback option to display your Desktop if no suitable real driver is found.

How does a driver signal that it won't work?
This is rather interesting, and rather unspecified. remember, a driver consists of two parts: the kerneldriver and the accelerant. The kerneldriver is the one creating the /dev/graphics/ entries.
So: the system (app_server) tries to open the kerneldriver first. Some closed source drivers will block more than one open instance.
- The matrox driver(s) do this to signal that the card in question is already in use: handy for me if I want to determine which cards are still free for a video consumer node for instance.
- However: the sis driver does this if it determines that the card can't be made to work: i.e. it sees that this card wasn't coldstarted by the system BIOS (displaying POST messages etc). The sis driver itself doesn't feature internal coldstart support, so if a sis card is non-primary according to your system BIOS, the driver will signal that it can't be used.

While I personally like the first 'feature', I don't really like the second one: it's likely that a accelerant will be the better place to check if a card can be really used: the kerneldriver's functionality should only be mapping the device: not *using* it.

On a sidenote I can tell you I tried converting the Haiku nVidia driver to use this signalling for 'being busy', but I miserably failed. I am no expert here, but it seems that the cookie managed by the system somehow is causing trouble. And besides: Be probably documented multiple-opens to be supported in their Graphics Driver kit for a good reason, although their own drivers (sometimes) work differently.

So, I modified the Accelerant's INIT_ACCELERANT and CLONE_ACCELERANT hooks to return B_NOT_ALLOWED in case the order of them being executed is not valid. Also I'll add aborting on unuseable cards later on in INIT_ACCELERANT.

Driver errors encountered during node development
For some reason most Be drivers can't seem to correctly identify their own hardware. Say you have two cards in a system, the desktop displayed on card 1, and card 2 not used. If you start using card 2, you might well discover that the driver for card 2 somehow gains access to card 1 and messes up it's programming. I have a feeling this has to do with non-system-wide-unique named areas mapped by the kerneldrivers.
Luckily the Haiku drivers don't have this issue: I guess the Be Alpha driver kit has a fix for this problem in it.

Other errors encounted were:
- Be SiS driver has overlay support, but it's broken. It supports single buffered overlay only, but vertical 'bars' of repeating video are shown instead of normal video. Also shutting of overlay doesn't work: once enabled it stays enabled.
- Be unified nVidia driver has broken GET_ACCELERANT_DEVICE_INFO hook: you need to issue it twice to get valid info (after that it's OK).
- DPMS state preservation over SetMode() calls is 'broken' on most Be drivers. Apparantly they didn't have time to update all of their drivers to what the alpha driver kit prescribes. (SiS driver is OK, nVidia and Matrox are 'broken'). BTW, I think preserving DPMS state is the way to go indeed. :-)

Well, that's about it I guess. This is the third time I am trying to write this 'article', so forgive me if I'm a bit sloppy. The fun in writing an article fades away fast if browsers and sites constantly mess-up...

Back again...

2006-01-22T18:45:00.000+01:00

Hi there,

Let's try blogging this way once more. It's a lot less work than editing HTML myself after all, and more is possible (considering my limited knowledge on this stuff).

Hopefully I'll find the time to keep messages coming here :-)

Rudolf.