nv_acc_dma.c: fix gcc6 build

Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>

NVidia: 64bit fixes.

added engine function OFFSCREEN_TO_SCREEN_SCALED_FILTERED_BLIT. Not used yet, testing and wip. Function is confirmed up and running on geforce 7200, 6200, 6600, 5200.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37158 a95241bf-73f2-0310-859d-f6bbb57e9c96

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30867 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed acceleration engine crashes on at least G72 cards by powering up a new part of the engine. This fixes acc on Geforce 7300/7400/7500 cards, and closes tickets #927, #1535 and #3482. In order to test this you need to go back to Haiku R30277 at least since app_server nolonger uses acceleration. Acceleration code was synced to Xfree86 4.8.0. and no chances were found. Bumped version to 0.90, updated docs.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30783 a95241bf-73f2-0310-859d-f6bbb57e9c96

added engine command fifo setup for TCL_PRIMITIVE_3D for NV15 only for now (testing). Over here the NV15 keeps running and the command seems responsive. I hope this doesn't crash other NV15's outthere.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22290 a95241bf-73f2-0310-859d-f6bbb57e9c96

checked G73 setup against today's XFree86 CVS. G73 should be supported now, that is, after the kerneldriver is updated as well (for cardIDs)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17047 a95241bf-73f2-0310-859d-f6bbb57e9c96

removed NV47 references, replaced with G70. Also added G71, G72 and G73 engines.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17037 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated pre-NV10 card init code for a small 3D rendering speed increase on TNT2 and TNT2-M64 cardtypes: gain is some 1-4% depending on colorspace and exact card-type. This completes the 2D driver's 3D related init programming sweep. Next up should be adding cardID's and adding a new nv.setting to force screen aspect. Bumped version to 0.77.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17000 a95241bf-73f2-0310-859d-f6bbb57e9c96

what? didn't upgrade to 0.75 while you are using hardware 3D? Well, maybe now I can convince you!. New speeds: another 43% gain for NV11, in 1024x768x32 Q1 now at 27.1fps, NV15 gets another 60% boost for the winning score of 45.4fps, and NV18 tries to keep up (but fails :) with now 41% speedup for 37.0fps. 3D users, it's time to upgrade to 0.76. :)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16941 a95241bf-73f2-0310-859d-f6bbb57e9c96

improved 3D init programming. NV11 gained 44% speed, NV15 gained 21% speed, NV18 and other cards remain at the same speed. These gains (or about) are in all resolutions, all colordepths. If your CPU is fast enough of course. Bumped version to 0.75. There's no doubt about it, if you use 3D, upgrade!

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16931 a95241bf-73f2-0310-859d-f6bbb57e9c96

added retrace sync programming for NV12_IMAGE_BLIT command. Works OK it seems (testing in 3D add-on).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16400 a95241bf-73f2-0310-859d-f6bbb57e9c96

switched to a newer blit function in the driver for NV11 and higher (below does not support it). Benchmarking shows this blit has about the same speed as the old one. The reason for switching is the fact that this new function supports auto_sync_to_retrace. That should counteract the drop in fps for synced swaps (3D) a bit.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16398 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated 3D related colorspace settings to be optimal speed wise. Also removed redundant stuff not having any effect with the current engine setup. 3D rendering speed stays same on RGB15 and 16, but RGB32 space just gained about 11% gain :)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16321 a95241bf-73f2-0310-859d-f6bbb57e9c96

completely removed concurrent 3D/overlay workaround number 2 (executing a 3D command in engine init). Overlay and fifo-assignment-switching on-the-fly / 3D are working OK indeed. The dangerous-RAM-area patch completely solves that problem.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16221 a95241bf-73f2-0310-859d-f6bbb57e9c96

disabled 3D/overlay patch number two: looks like I nailed this one good. Looks to be confirmed on TNT1, will test more before final delete of this patch.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16203 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed overlay playback and accelerantion engine crashes if all is right: it turns out the last piece of cardRAM may not be accessed by software. This looks to be a hardware bug, size of dangerous RAM depends on pre/post NV40 architecture, bug exists for both FIFO channel assignment on the fly, and DMA command buffer existing in cardRAM. If there are still users outthere using PIO acceleration and 3D they have a good chance of having working concurrent overlay as well, as the fifo-assignment bug turns up with PIO acc as well. Note: the bugfix is still in test: confirmed on TNT1 only for now.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16200 a95241bf-73f2-0310-859d-f6bbb57e9c96

comment update: pitch granularity now confirmed for 15, 16 and 32bit RGB depths (SCALED_BLIT).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16169 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated SCALED_BLIT to do 15-bit space correctly.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16168 a95241bf-73f2-0310-859d-f6bbb57e9c96

removed 'typo' introduced while testing.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15645 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed with-issues with scaled_filtered blit. Tested for 16bit space. Over here this new function is now stable. Other spaces will be tested asap.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15615 a95241bf-73f2-0310-859d-f6bbb57e9c96

corrected scaled_filtered_blit setup according to test results with a node. Now it correctly works for a 'number of source-widths': tested 320 and 640 pixels source bitmaps. This source-width thing is still under test..

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15613 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated scaled_filtered_blit code and fixed NV1_RENDER_SOLID_LIN setup. Scaled blit might still be down, but we are getting there.. (in progress)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15602 a95241bf-73f2-0310-859d-f6bbb57e9c96

finished and enabled support for 2D acceleration function SCREEN_TO_SCREEN_SCALED_FILTERED_BLIT (DMA mode only). While still untested, the engine keeps running at least. Should work on all cards the driver supports. Note: overlay support is now broken: 2D engine freezes at some point. Will fix that asap (I hope)...

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15542 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed not asking cmd buffer for room for all items (scaled_fiterled_blit)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15541 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed preliminary (untested) scaled_filtered_blit function, although it wont' work yet: the engine cmd define and fifo assignment has yet to be setup.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15538 a95241bf-73f2-0310-859d-f6bbb57e9c96

more stuff for SCREEN_TO_SCREEN_SCALED_FILTERED_BLIT function. Not yet complete though.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15536 a95241bf-73f2-0310-859d-f6bbb57e9c96

adding DMA acc function SCREEN_TO_SCREEN_SCALED_FILTERED_BLIT (in progress). The videonode turns out to be a nice playground to test it with, so I can set it up. Also it looks like I'm going to need it because I can't get a B_YCbCr422 connection going on R5 or dano (negotiation seems to fail).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15424 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed DMA acceleration init code sync to XF86. All cards should be operational again (still untested). Bumped version to 0.65.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15003 a95241bf-73f2-0310-859d-f6bbb57e9c96

updating DMA acc engine init code: part 4. Still in progress, but maybe NV47 acc runs now: It's enabled now. This turns out to be an interesting update: init code has been extended for NV20 and higher cards, giving me reason enough to probably do some more 3D testing on newer cards. (probably for nothing though :)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14999 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated engine DMA acc init code, part 3 (in progress).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14989 a95241bf-73f2-0310-859d-f6bbb57e9c96

updating DMA acc init code, part 2: in progress.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14987 a95241bf-73f2-0310-859d-f6bbb57e9c96

updating DMA acceleration code for NV41, 43, 44. Adding code for NV47: sync to XF86, in progress (acc might be broken now..)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14984 a95241bf-73f2-0310-859d-f6bbb57e9c96

added some comments about the NV18 speedfix and resetting registers on NV28.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13424 a95241bf-73f2-0310-859d-f6bbb57e9c96

added/modified shared_info to (better) support upto 32 3D accelants. Needs to be improved/expanded later though. Bumped version to 0.53.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13210 a95241bf-73f2-0310-859d-f6bbb57e9c96

modified 3d reload flag to support 32 clones, added clone counter as well.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13175 a95241bf-73f2-0310-859d-f6bbb57e9c96

added shared_info flag to inform 3D add-on to reload it's rendering state, further improving 3D rendering speed: Quake2 is at 105fps (GF4MX440, 640x480x16), Teapot renders at close to 500fps now. Bumped version to 0.52.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13169 a95241bf-73f2-0310-859d-f6bbb57e9c96

added a concurrent overlay/3D workaround making that combination work reliably now. No more engine crashes should occur. Bumped version to 0.51.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13092 a95241bf-73f2-0310-859d-f6bbb57e9c96

corrected all dummyreads to use volatile pointers. Thanks Marcus Overhagen for reading along.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13082 a95241bf-73f2-0310-859d-f6bbb57e9c96

modified a few comments only . All my cards BTW are running OK (including NV43/PCIe), so it looks like a release can be about done.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13029 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated explicit engine register clearing to be only carried out on pre-NV20: newer cards don't like this and hang. Also cleaned up a bit. Let's stick with the 1Mb cmd buffer as it seems to have proven itself now. (only pre-NV40 for now).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12927 a95241bf-73f2-0310-859d-f6bbb57e9c96

added some more comments for specs

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12926 a95241bf-73f2-0310-859d-f6bbb57e9c96

FIX FOR NV18cd obos_svn/trunk/src/add-ons/accelerants/nvidia/ We now have a new winner for 3D. Quake2 runs at 91.5fps in 640x480x16. I can hardly believe this..

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12925 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed NV1x 3D DMA acceleration. NV15 now renders the teapot at 400+fps in both 16 and 32bit, quake2 in 640x480x16 runs at 77fps. The DMA 3D driver is now fully operational to the same extent as the PIO version: but much faster :-). Note, this 2D driver is still in testing..

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12905 a95241bf-73f2-0310-859d-f6bbb57e9c96

added shared_info flag to assess PCI or AGP mode. Engine (if in DMA mode) selects PCI or AGP transfers accordingly (pre-NV40 only for now). It seems the combination of the 1Mb cmd buffer size and it being in main mem makes it all fast. (1Mb in gfx card remains at same speed at 32kb.). Maybe we can even use AGP engine transfers for placing textures on the gfx card in the future: who knows.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12848 a95241bf-73f2-0310-859d-f6bbb57e9c96

forgot to tell the DMA cmd fetch engine it may write-back as well as read. Seems to not have influence on speed, as expected I'd say. Anyway: just tried enabling AGP transfers for cmd fetches: that actually works over here!. I just saw GLteapot spinning at over 400fps because of it. Note however that this doesn't mean we can reach that speed with a local DMA command buffer: the real reason for the higher speed might be the large size (1Mb compared to 32kB). testing some more..

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12844 a95241bf-73f2-0310-859d-f6bbb57e9c96

on pre-NV40 I have activated the main mem DMA command buffer at size = 1Mb. It's working OK and is way faster on TNT1 (using the local-DMA-via-mainmem workaround) - of course. For all other cards however (so which have working local DMA command buffers) the mainmem implementation is actually a bit slower, and places a higher burder on the bus slowing down 2D a lot when 3D maxes out. All in all, I am not sure this is the way to go. It might be best to make this all a switch for nv.settings, disabled by default. Still testing... (Curious how AGP transfers will do - if possible, currently using PCI transfers)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12843 a95241bf-73f2-0310-859d-f6bbb57e9c96

small update to keep accelerant working with already modified kerneldriver and shared_info for mainmem DMA buffer.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12836 a95241bf-73f2-0310-859d-f6bbb57e9c96

more cleanup for DMA: re-organised cmd define locations.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12764 a95241bf-73f2-0310-859d-f6bbb57e9c96

major hash and engine command defines cleanup (PIO and DMA). It looks like the hash-rules are quite simple after all. Hoping I'm right about that: looking good. PIO mode: 3D add-on alpha1 should nolonger work with the current 2D driver (hang). DMA mode: on TNT2 orig, DMA 3D acc is fully working now. All surface commands work, old ones are removed. I'll (try to) bring PIO mode upto par so 3D will work again there too. GLteapot stays at 360fps @ 16bit, 280 fps @ 32bit for now (TNT2 orig). Bumped version to 0.47.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12762 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed concurrent overlay and 3D use. This never worked before: it turns out that overlay requires a certain engine command setup order/chain without gaps to prevent hard crashes. 3D surface cmd still down though..

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12756 a95241bf-73f2-0310-859d-f6bbb57e9c96

removed more old surface commands related programming.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12755 a95241bf-73f2-0310-859d-f6bbb57e9c96

removed old 2D/3D surface commands. While the 'new' 3D surface command is still down, the 2D surface command has been replaced with NV4_SURFACE/NV10_CONTEXT_SURFACES_2D. These indeed work. Teapot: now @ 360fps on TNT2 orig (16bit).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12754 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed introduced error for TNT1. DMA mode is a bit flaky ATM though here.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12650 a95241bf-73f2-0310-859d-f6bbb57e9c96

more colorspace dependand engine cmd programming for 3D. Now 15,16 and 32bit mode are up again: 15/16bit: teapot 320fps, 32: 280fps (tnt2). All demos run.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12642 a95241bf-73f2-0310-859d-f6bbb57e9c96

added DMA surface cmd's colorspace dependant programming. These commands were still down at last 3D test, but already the Teapot is spinning at 300fps in DMA mode ona TNT2 over here!!

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12641 a95241bf-73f2-0310-859d-f6bbb57e9c96

added all 3D related commands found in PIO acceleration code to DMA pre-NV40 code as well. Bumped version to 0.46: experimental, should be fully OK though (for 2D).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12626 a95241bf-73f2-0310-859d-f6bbb57e9c96

the DMA acc sub-cmd-lists are now issued to a single engine command (except for blit because it's hardware can't do that), instead of to multiple issued engine commands. (one could say 'parallel processing' but that's not the case: it remains serial: it's just faster).

DMA acceleration speed is up another 10% for rect and span commands.
commencing more testing now: code is complete (I hope).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11433 a95241bf-73f2-0310-859d-f6bbb57e9c96

optimized DMA acc code more by splitting up command lists into sublists before issuing them to the engine. this further improves speed with upto about 70 percent, for a total of about doubling the speed by pure software optimation.

Note: code is now working the same as Thomas's ATI driver: he minimized calls in the same ways. (Curious how a benchmark contest would hold up now.. ;-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11431 a95241bf-73f2-0310-859d-f6bbb57e9c96

applied DMA mode speed optimations 'step 1.5': incorporated all top-level acceleration functions inside the engine's code so minimal nested calls are made. Confirmed further speedup of about 15% on fast CPU's...


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11427 a95241bf-73f2-0310-859d-f6bbb57e9c96

optimizing DMA acc for speed ('step 1'). Also simplifies code.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11422 a95241bf-73f2-0310-859d-f6bbb57e9c96

added fix (not yet completely tested) for NV40/NV45 artifacts on heavy acc engine use. Bumped driverversion to 0.37.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11419 a95241bf-73f2-0310-859d-f6bbb57e9c96

added one (still disabled) register for framebuffer config(?) on NV40/NV45 (in test)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11417 a95241bf-73f2-0310-859d-f6bbb57e9c96

added some comments about NV40 architecture. We have several new unknown factors:
- DAC2 always detects a analog screen connected;
- it seems like there are at least two new registers we don't know about. One extra switch to place output on connectors, and one (extra) switch for pixelclock PLL to CRTC connections (one PLL drives both CRTC's in some cases, pre-programmed by the card BIOS determined on the screen configuration found at power-up.
- in a known register (TSTCTRL) b20 blocks/moves output on connectors (?).
All confirmed on NV43, GeForce PCIe 6600GT.

Driver status:
- one DVI monitor connected is OK;
- one analog screen connected on the DB15 connector is OK,
- two analog screens connected is OK and can be used for dualhead.
other combinations don't work well or at all. This is the status confirmed on
the NV43. Assuming same for other cards of NV40 architecture.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11399 a95241bf-73f2-0310-859d-f6bbb57e9c96

added some more PIO mode acceleration programming for NV40 and higher. This remains non-functional: aborting dev on this for now. Notes about the problem are in the code. For now I guess no-one cares about PIO mode nomore anyway... ;-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11354 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated a few comments, added some acc stuff for NV40+ for PIO mode: trying to get that up as well briefle now.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11328 a95241bf-73f2-0310-859d-f6bbb57e9c96

added NV04(TNT1) DMA workaround code. TNT1 now also works with DMA acceleration. TNT2-M64 has been confirmed up also. This means all cards should work now! (Except for a NV40 artifact on blits..).
Still some finetuning to do.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11293 a95241bf-73f2-0310-859d-f6bbb57e9c96

added pre-NV10 screen location and size for completeness. NV05 (TNT2) is confirmed up and running speedy now :-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11292 a95241bf-73f2-0310-859d-f6bbb57e9c96

added preliminary pre-NV10 specific DMA acceleration code. Not finished, not tested.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11290 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated a few register defines for NV44 type.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11271 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed NV44 and NV45 programming for acceleration


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11269 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed NV20 architecture DMA acceleration: confirmed both NV20 and NV30 architectur up and running OK BTW.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11171 a95241bf-73f2-0310-859d-f6bbb57e9c96

small simplification for reading and writing DMAGET and DMAPUT, gives a minor speedup (a few percent max).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11167 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed DMA acc for NV30 architecture, still untested. Fixed two doubled registerdefines which adress the same registers.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11108 a95241bf-73f2-0310-859d-f6bbb57e9c96

needed to bump the DMA command buffer forced freespace up to 256 words: NV4_GDI_RECT needs a higher setting than the old version. Hopefully engine crashes are now past tense...


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11095 a95241bf-73f2-0310-859d-f6bbb57e9c96

Arrrgghh! I was still using NV3_GDI_RECTANGLE_TEXT instead of NV4_GDI_RECTANGLE_TEXT on pre-NV40 (NV11 tested). Fixed now.
Anyway: Now we know the reason the switch must be made: the old command, while being approx. of the same speed as the new one, has a hardware fault and has also therefore been removed in NV40 and later hardware.
The fault is the input->output colorspace conversion which doesn't work while being used with DMA acc. Glad I could loose that nasty workaround now!!


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11093 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed overlay bitmap DMA adress, fixed overlay in 15 bit mode (NV11). nVidia hardware is broken here :-/. Anyway, it works now.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11092 a95241bf-73f2-0310-859d-f6bbb57e9c96

modified overlay to stay outside DMA buffer if it exists.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11091 a95241bf-73f2-0310-859d-f6bbb57e9c96

added invert_rect DMA acc function. Tested in all colorspaces on NV11 (OK).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11090 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated DMA acc to use the full DMA buffersize instead of just one quarter.
Also improved forced freespace limit setting in this buffer, now finally completely preventing engine crashes it seems.
Engine speed went up again due to larger DMA buffer.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11089 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed fill_rect and fill_span 8, 15 and 16 bit colorspaces for NV10Arch. Tested and OK on NV11.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11080 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated DMA engine error handling: the driver should nolonger hang (again) if the engine crashes.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11018 a95241bf-73f2-0310-859d-f6bbb57e9c96

finalized DMA buffer overfill checking for optimum speed. On NV11 accelerated functions are running at 130% to 200% speed in DMA mode compared to the 'old' PIO mode. Without trouble now.
Still only 32bit mode, and still missing invert_rect function though. Also still not explicitly adhering the engine constraints which needs to be rechecked/retuned compared to PIO mode (hence the non working 800x600x8 mode I expect..)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11009 a95241bf-73f2-0310-859d-f6bbb57e9c96

added checking to prevent DMA buffer overfills: it turns out for instance NV11 can't keep up with BeRoMeter and the engine crashes otherwise. It turns out NV11 is currently only working correctly in 32bit color mode BTW.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11005 a95241bf-73f2-0310-859d-f6bbb57e9c96

shut-down that dumb ISA access for DMA. Acc speed just went through the roof! (testing with BeRoMeter). I'll now compare DMA and non-DMA speed on NV11 8-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11003 a95241bf-73f2-0310-859d-f6bbb57e9c96

DMA versions of fill_rect and fill_span (same core func still) are up! Removed some testlogging, their load became too high with these new functions added :)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11001 a95241bf-73f2-0310-859d-f6bbb57e9c96

small cleanup. This fixes DMA buffer freespace tracking as well.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11000 a95241bf-73f2-0310-859d-f6bbb57e9c96

added fill_rect and fill_span functions (same). Not yet exported, not yet working either..


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10986 a95241bf-73f2-0310-859d-f6bbb57e9c96

added timeout and abort for DMA idle waits. This keeps the system responsive if the DMA engine fails, which is way better than a complete hang. Adding this because it's not impossible to create a situation that stalls DMA: for instance if a video app writes (way) outside it's allocated overlay buffers.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10976 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed DMA buffer wraparounds. DMA acceleration is now stable on NV11 and NV43. Enjoy.. (still missing acc hooks will be setup asap.)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10959 a95241bf-73f2-0310-859d-f6bbb57e9c96

small cleanup (mostly comments updates)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10944 a95241bf-73f2-0310-859d-f6bbb57e9c96

another nice milestone: NV43 (GeForce PCIe 6600 GT tested) has acceleration up and running as well now!. Please note that the same restrictions apply here as I just mentioned for NV11: to be fixed asap of course ;-)
Jippieeee!


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10941 a95241bf-73f2-0310-859d-f6bbb57e9c96

added explicit clearing of the hashtable engine RAM. This sneaky thing won't get to me again: it keeps it's contents even over power-outages of upto say 15 seconds!!


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10932 a95241bf-73f2-0310-859d-f6bbb57e9c96

small logging correction for DMA_PUT.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10847 a95241bf-73f2-0310-859d-f6bbb57e9c96

The DMA_PUT register is write-only on some cards (confirmed NV11).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10846 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed a stupid error I introduced with cleaning up some stuff: FIFO channel assignments should now work. Confirmed NV11 BTW being at the same level as NV43: DMA works, engine not yet.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10839 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed NV10 architecture DMA programming to the same level as NV43. Hopefully this engine will show more signs of life than NV43 still does..


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10800 a95241bf-73f2-0310-859d-f6bbb57e9c96

added cmd defines (CTX registers) for pre-NV40 cards, corrected a CTX programming error for NV40 and higher (2d_surface).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10798 a95241bf-73f2-0310-859d-f6bbb57e9c96

added setting pattern colorspace (DMA)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10795 a95241bf-73f2-0310-859d-f6bbb57e9c96

added 2D_surface setup (DMA), added fifo channel assignent check for aquire_engine, cleaned some stuff up.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10793 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed FIFO channel pointer error that caused assert_fifo to always fail (DMA, >NV40). Should fix driver hanging after changing workspaces with different modesettings on NV40 and later.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10792 a95241bf-73f2-0310-859d-f6bbb57e9c96

added 2D_surface command engine defines and FIFO channel assignment: used for setting buffer colorspace, location and pitch later on.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10771 a95241bf-73f2-0310-859d-f6bbb57e9c96

more DMA related programming. Still acceleration this way is disabled. DMA command fetching now actually works on GeForce 6600/NV43 (verified). The acceleration engine still refuses to process the fed commands (correctly) though. OTOH: programming not yet coplete ;-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10734 a95241bf-73f2-0310-859d-f6bbb57e9c96

modified cmd handles, added DMA blit partly. Still untested.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10713 a95241bf-73f2-0310-859d-f6bbb57e9c96

added DMA cmd related info


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10711 a95241bf-73f2-0310-859d-f6bbb57e9c96

more DMA stuff


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10709 a95241bf-73f2-0310-859d-f6bbb57e9c96

added more DMA programming: cmd buffer and FIFO setup.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10701 a95241bf-73f2-0310-859d-f6bbb57e9c96

added checking for engine idle: which is actually the case over here :-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10666 a95241bf-73f2-0310-859d-f6bbb57e9c96

added DMA engine initialisation code for NV40 and higher. Still disabled, and needs support from driver (reserve DMA buffer RAM etc)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10660 a95241bf-73f2-0310-859d-f6bbb57e9c96

added cursor HW bug workaround for NV40 and higher on CRTC1; added seperate acc file for DMA test setup for NV40 and higher (for now).
The driver now works by default on NV40 and higher, but without acceleration.
If someone tests using overlay, let me know if it actually works: NV43 seems to have a new engine, NV40 _might_ still have the old, and so, useable engine.
NV40-plus overlay is something we will NOT have any time soon!


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10651 a95241bf-73f2-0310-859d-f6bbb57e9c96

NVidia: 64bit fixes.

added engine function OFFSCREEN_TO_SCREEN_SCALED_FILTERED_BLIT. Not used yet, testing and wip. Function is confirmed up and running on geforce 7200, 6200, 6600, 5200.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37158 a95241bf-73f2-0310-859d-f6bbb57e9c96

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30867 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed acceleration engine crashes on at least G72 cards by powering up a new part of the engine. This fixes acc on Geforce 7300/7400/7500 cards, and closes tickets #927, #1535 and #3482. In order to test this you need to go back to Haiku R30277 at least since app_server nolonger uses acceleration. Acceleration code was synced to Xfree86 4.8.0. and no chances were found. Bumped version to 0.90, updated docs.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30783 a95241bf-73f2-0310-859d-f6bbb57e9c96

added engine command fifo setup for TCL_PRIMITIVE_3D for NV15 only for now (testing). Over here the NV15 keeps running and the command seems responsive. I hope this doesn't crash other NV15's outthere.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22290 a95241bf-73f2-0310-859d-f6bbb57e9c96

checked G73 setup against today's XFree86 CVS. G73 should be supported now, that is, after the kerneldriver is updated as well (for cardIDs)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17047 a95241bf-73f2-0310-859d-f6bbb57e9c96

removed NV47 references, replaced with G70. Also added G71, G72 and G73 engines.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17037 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated pre-NV10 card init code for a small 3D rendering speed increase on TNT2 and TNT2-M64 cardtypes: gain is some 1-4% depending on colorspace and exact card-type. This completes the 2D driver's 3D related init programming sweep. Next up should be adding cardID's and adding a new nv.setting to force screen aspect. Bumped version to 0.77.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17000 a95241bf-73f2-0310-859d-f6bbb57e9c96

what? didn't upgrade to 0.75 while you are using hardware 3D? Well, maybe now I can convince you!. New speeds: another 43% gain for NV11, in 1024x768x32 Q1 now at 27.1fps, NV15 gets another 60% boost for the winning score of 45.4fps, and NV18 tries to keep up (but fails :) with now 41% speedup for 37.0fps. 3D users, it's time to upgrade to 0.76. :)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16941 a95241bf-73f2-0310-859d-f6bbb57e9c96

improved 3D init programming. NV11 gained 44% speed, NV15 gained 21% speed, NV18 and other cards remain at the same speed. These gains (or about) are in all resolutions, all colordepths. If your CPU is fast enough of course. Bumped version to 0.75. There's no doubt about it, if you use 3D, upgrade!

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16931 a95241bf-73f2-0310-859d-f6bbb57e9c96

added retrace sync programming for NV12_IMAGE_BLIT command. Works OK it seems (testing in 3D add-on).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16400 a95241bf-73f2-0310-859d-f6bbb57e9c96

switched to a newer blit function in the driver for NV11 and higher (below does not support it). Benchmarking shows this blit has about the same speed as the old one. The reason for switching is the fact that this new function supports auto_sync_to_retrace. That should counteract the drop in fps for synced swaps (3D) a bit.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16398 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated 3D related colorspace settings to be optimal speed wise. Also removed redundant stuff not having any effect with the current engine setup. 3D rendering speed stays same on RGB15 and 16, but RGB32 space just gained about 11% gain :)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16321 a95241bf-73f2-0310-859d-f6bbb57e9c96

completely removed concurrent 3D/overlay workaround number 2 (executing a 3D command in engine init). Overlay and fifo-assignment-switching on-the-fly / 3D are working OK indeed. The dangerous-RAM-area patch completely solves that problem.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16221 a95241bf-73f2-0310-859d-f6bbb57e9c96

disabled 3D/overlay patch number two: looks like I nailed this one good. Looks to be confirmed on TNT1, will test more before final delete of this patch.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16203 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed overlay playback and accelerantion engine crashes if all is right: it turns out the last piece of cardRAM may not be accessed by software. This looks to be a hardware bug, size of dangerous RAM depends on pre/post NV40 architecture, bug exists for both FIFO channel assignment on the fly, and DMA command buffer existing in cardRAM. If there are still users outthere using PIO acceleration and 3D they have a good chance of having working concurrent overlay as well, as the fifo-assignment bug turns up with PIO acc as well. Note: the bugfix is still in test: confirmed on TNT1 only for now.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16200 a95241bf-73f2-0310-859d-f6bbb57e9c96

comment update: pitch granularity now confirmed for 15, 16 and 32bit RGB depths (SCALED_BLIT).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16169 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated SCALED_BLIT to do 15-bit space correctly.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16168 a95241bf-73f2-0310-859d-f6bbb57e9c96

removed 'typo' introduced while testing.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15645 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed with-issues with scaled_filtered blit. Tested for 16bit space. Over here this new function is now stable. Other spaces will be tested asap.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15615 a95241bf-73f2-0310-859d-f6bbb57e9c96

corrected scaled_filtered_blit setup according to test results with a node. Now it correctly works for a 'number of source-widths': tested 320 and 640 pixels source bitmaps. This source-width thing is still under test..

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15613 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated scaled_filtered_blit code and fixed NV1_RENDER_SOLID_LIN setup. Scaled blit might still be down, but we are getting there.. (in progress)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15602 a95241bf-73f2-0310-859d-f6bbb57e9c96

finished and enabled support for 2D acceleration function SCREEN_TO_SCREEN_SCALED_FILTERED_BLIT (DMA mode only). While still untested, the engine keeps running at least. Should work on all cards the driver supports. Note: overlay support is now broken: 2D engine freezes at some point. Will fix that asap (I hope)...

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15542 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed not asking cmd buffer for room for all items (scaled_fiterled_blit)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15541 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed preliminary (untested) scaled_filtered_blit function, although it wont' work yet: the engine cmd define and fifo assignment has yet to be setup.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15538 a95241bf-73f2-0310-859d-f6bbb57e9c96

more stuff for SCREEN_TO_SCREEN_SCALED_FILTERED_BLIT function. Not yet complete though.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15536 a95241bf-73f2-0310-859d-f6bbb57e9c96

adding DMA acc function SCREEN_TO_SCREEN_SCALED_FILTERED_BLIT (in progress). The videonode turns out to be a nice playground to test it with, so I can set it up. Also it looks like I'm going to need it because I can't get a B_YCbCr422 connection going on R5 or dano (negotiation seems to fail).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15424 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed DMA acceleration init code sync to XF86. All cards should be operational again (still untested). Bumped version to 0.65.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15003 a95241bf-73f2-0310-859d-f6bbb57e9c96

updating DMA acc engine init code: part 4. Still in progress, but maybe NV47 acc runs now: It's enabled now. This turns out to be an interesting update: init code has been extended for NV20 and higher cards, giving me reason enough to probably do some more 3D testing on newer cards. (probably for nothing though :)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14999 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated engine DMA acc init code, part 3 (in progress).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14989 a95241bf-73f2-0310-859d-f6bbb57e9c96

updating DMA acc init code, part 2: in progress.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14987 a95241bf-73f2-0310-859d-f6bbb57e9c96

updating DMA acceleration code for NV41, 43, 44. Adding code for NV47: sync to XF86, in progress (acc might be broken now..)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14984 a95241bf-73f2-0310-859d-f6bbb57e9c96

added some comments about the NV18 speedfix and resetting registers on NV28.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13424 a95241bf-73f2-0310-859d-f6bbb57e9c96

added/modified shared_info to (better) support upto 32 3D accelants. Needs to be improved/expanded later though. Bumped version to 0.53.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13210 a95241bf-73f2-0310-859d-f6bbb57e9c96

modified 3d reload flag to support 32 clones, added clone counter as well.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13175 a95241bf-73f2-0310-859d-f6bbb57e9c96

added shared_info flag to inform 3D add-on to reload it's rendering state, further improving 3D rendering speed: Quake2 is at 105fps (GF4MX440, 640x480x16), Teapot renders at close to 500fps now. Bumped version to 0.52.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13169 a95241bf-73f2-0310-859d-f6bbb57e9c96

added a concurrent overlay/3D workaround making that combination work reliably now. No more engine crashes should occur. Bumped version to 0.51.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13092 a95241bf-73f2-0310-859d-f6bbb57e9c96

corrected all dummyreads to use volatile pointers. Thanks Marcus Overhagen for reading along.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13082 a95241bf-73f2-0310-859d-f6bbb57e9c96

modified a few comments only . All my cards BTW are running OK (including NV43/PCIe), so it looks like a release can be about done.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13029 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated explicit engine register clearing to be only carried out on pre-NV20: newer cards don't like this and hang. Also cleaned up a bit. Let's stick with the 1Mb cmd buffer as it seems to have proven itself now. (only pre-NV40 for now).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12927 a95241bf-73f2-0310-859d-f6bbb57e9c96

added some more comments for specs

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12926 a95241bf-73f2-0310-859d-f6bbb57e9c96

FIX FOR NV18cd obos_svn/trunk/src/add-ons/accelerants/nvidia/ We now have a new winner for 3D. Quake2 runs at 91.5fps in 640x480x16. I can hardly believe this..

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12925 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed NV1x 3D DMA acceleration. NV15 now renders the teapot at 400+fps in both 16 and 32bit, quake2 in 640x480x16 runs at 77fps. The DMA 3D driver is now fully operational to the same extent as the PIO version: but much faster :-). Note, this 2D driver is still in testing..

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12905 a95241bf-73f2-0310-859d-f6bbb57e9c96

added shared_info flag to assess PCI or AGP mode. Engine (if in DMA mode) selects PCI or AGP transfers accordingly (pre-NV40 only for now). It seems the combination of the 1Mb cmd buffer size and it being in main mem makes it all fast. (1Mb in gfx card remains at same speed at 32kb.). Maybe we can even use AGP engine transfers for placing textures on the gfx card in the future: who knows.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12848 a95241bf-73f2-0310-859d-f6bbb57e9c96

forgot to tell the DMA cmd fetch engine it may write-back as well as read. Seems to not have influence on speed, as expected I'd say. Anyway: just tried enabling AGP transfers for cmd fetches: that actually works over here!. I just saw GLteapot spinning at over 400fps because of it. Note however that this doesn't mean we can reach that speed with a local DMA command buffer: the real reason for the higher speed might be the large size (1Mb compared to 32kB). testing some more..

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12844 a95241bf-73f2-0310-859d-f6bbb57e9c96

on pre-NV40 I have activated the main mem DMA command buffer at size = 1Mb. It's working OK and is way faster on TNT1 (using the local-DMA-via-mainmem workaround) - of course. For all other cards however (so which have working local DMA command buffers) the mainmem implementation is actually a bit slower, and places a higher burder on the bus slowing down 2D a lot when 3D maxes out. All in all, I am not sure this is the way to go. It might be best to make this all a switch for nv.settings, disabled by default. Still testing... (Curious how AGP transfers will do - if possible, currently using PCI transfers)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12843 a95241bf-73f2-0310-859d-f6bbb57e9c96

small update to keep accelerant working with already modified kerneldriver and shared_info for mainmem DMA buffer.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12836 a95241bf-73f2-0310-859d-f6bbb57e9c96

more cleanup for DMA: re-organised cmd define locations.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12764 a95241bf-73f2-0310-859d-f6bbb57e9c96

major hash and engine command defines cleanup (PIO and DMA). It looks like the hash-rules are quite simple after all. Hoping I'm right about that: looking good. PIO mode: 3D add-on alpha1 should nolonger work with the current 2D driver (hang). DMA mode: on TNT2 orig, DMA 3D acc is fully working now. All surface commands work, old ones are removed. I'll (try to) bring PIO mode upto par so 3D will work again there too. GLteapot stays at 360fps @ 16bit, 280 fps @ 32bit for now (TNT2 orig). Bumped version to 0.47.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12762 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed concurrent overlay and 3D use. This never worked before: it turns out that overlay requires a certain engine command setup order/chain without gaps to prevent hard crashes. 3D surface cmd still down though..

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12756 a95241bf-73f2-0310-859d-f6bbb57e9c96

removed more old surface commands related programming.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12755 a95241bf-73f2-0310-859d-f6bbb57e9c96

removed old 2D/3D surface commands. While the 'new' 3D surface command is still down, the 2D surface command has been replaced with NV4_SURFACE/NV10_CONTEXT_SURFACES_2D. These indeed work. Teapot: now @ 360fps on TNT2 orig (16bit).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12754 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed introduced error for TNT1. DMA mode is a bit flaky ATM though here.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12650 a95241bf-73f2-0310-859d-f6bbb57e9c96

more colorspace dependand engine cmd programming for 3D. Now 15,16 and 32bit mode are up again: 15/16bit: teapot 320fps, 32: 280fps (tnt2). All demos run.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12642 a95241bf-73f2-0310-859d-f6bbb57e9c96

added DMA surface cmd's colorspace dependant programming. These commands were still down at last 3D test, but already the Teapot is spinning at 300fps in DMA mode ona TNT2 over here!!

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12641 a95241bf-73f2-0310-859d-f6bbb57e9c96

added all 3D related commands found in PIO acceleration code to DMA pre-NV40 code as well. Bumped version to 0.46: experimental, should be fully OK though (for 2D).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12626 a95241bf-73f2-0310-859d-f6bbb57e9c96

the DMA acc sub-cmd-lists are now issued to a single engine command (except for blit because it's hardware can't do that), instead of to multiple issued engine commands. (one could say 'parallel processing' but that's not the case: it remains serial: it's just faster).

DMA acceleration speed is up another 10% for rect and span commands.
commencing more testing now: code is complete (I hope).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11433 a95241bf-73f2-0310-859d-f6bbb57e9c96

optimized DMA acc code more by splitting up command lists into sublists before issuing them to the engine. this further improves speed with upto about 70 percent, for a total of about doubling the speed by pure software optimation.

Note: code is now working the same as Thomas's ATI driver: he minimized calls in the same ways. (Curious how a benchmark contest would hold up now.. ;-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11431 a95241bf-73f2-0310-859d-f6bbb57e9c96

applied DMA mode speed optimations 'step 1.5': incorporated all top-level acceleration functions inside the engine's code so minimal nested calls are made. Confirmed further speedup of about 15% on fast CPU's...


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11427 a95241bf-73f2-0310-859d-f6bbb57e9c96

optimizing DMA acc for speed ('step 1'). Also simplifies code.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11422 a95241bf-73f2-0310-859d-f6bbb57e9c96

added fix (not yet completely tested) for NV40/NV45 artifacts on heavy acc engine use. Bumped driverversion to 0.37.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11419 a95241bf-73f2-0310-859d-f6bbb57e9c96

added one (still disabled) register for framebuffer config(?) on NV40/NV45 (in test)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11417 a95241bf-73f2-0310-859d-f6bbb57e9c96

added some comments about NV40 architecture. We have several new unknown factors:
- DAC2 always detects a analog screen connected;
- it seems like there are at least two new registers we don't know about. One extra switch to place output on connectors, and one (extra) switch for pixelclock PLL to CRTC connections (one PLL drives both CRTC's in some cases, pre-programmed by the card BIOS determined on the screen configuration found at power-up.
- in a known register (TSTCTRL) b20 blocks/moves output on connectors (?).
All confirmed on NV43, GeForce PCIe 6600GT.

Driver status:
- one DVI monitor connected is OK;
- one analog screen connected on the DB15 connector is OK,
- two analog screens connected is OK and can be used for dualhead.
other combinations don't work well or at all. This is the status confirmed on
the NV43. Assuming same for other cards of NV40 architecture.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11399 a95241bf-73f2-0310-859d-f6bbb57e9c96

added some more PIO mode acceleration programming for NV40 and higher. This remains non-functional: aborting dev on this for now. Notes about the problem are in the code. For now I guess no-one cares about PIO mode nomore anyway... ;-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11354 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated a few comments, added some acc stuff for NV40+ for PIO mode: trying to get that up as well briefle now.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11328 a95241bf-73f2-0310-859d-f6bbb57e9c96

added NV04(TNT1) DMA workaround code. TNT1 now also works with DMA acceleration. TNT2-M64 has been confirmed up also. This means all cards should work now! (Except for a NV40 artifact on blits..).
Still some finetuning to do.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11293 a95241bf-73f2-0310-859d-f6bbb57e9c96

added pre-NV10 screen location and size for completeness. NV05 (TNT2) is confirmed up and running speedy now :-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11292 a95241bf-73f2-0310-859d-f6bbb57e9c96

added preliminary pre-NV10 specific DMA acceleration code. Not finished, not tested.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11290 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated a few register defines for NV44 type.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11271 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed NV44 and NV45 programming for acceleration


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11269 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed NV20 architecture DMA acceleration: confirmed both NV20 and NV30 architectur up and running OK BTW.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11171 a95241bf-73f2-0310-859d-f6bbb57e9c96

small simplification for reading and writing DMAGET and DMAPUT, gives a minor speedup (a few percent max).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11167 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed DMA acc for NV30 architecture, still untested. Fixed two doubled registerdefines which adress the same registers.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11108 a95241bf-73f2-0310-859d-f6bbb57e9c96

needed to bump the DMA command buffer forced freespace up to 256 words: NV4_GDI_RECT needs a higher setting than the old version. Hopefully engine crashes are now past tense...


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11095 a95241bf-73f2-0310-859d-f6bbb57e9c96

Arrrgghh! I was still using NV3_GDI_RECTANGLE_TEXT instead of NV4_GDI_RECTANGLE_TEXT on pre-NV40 (NV11 tested). Fixed now.
Anyway: Now we know the reason the switch must be made: the old command, while being approx. of the same speed as the new one, has a hardware fault and has also therefore been removed in NV40 and later hardware.
The fault is the input->output colorspace conversion which doesn't work while being used with DMA acc. Glad I could loose that nasty workaround now!!


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11093 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed overlay bitmap DMA adress, fixed overlay in 15 bit mode (NV11). nVidia hardware is broken here :-/. Anyway, it works now.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11092 a95241bf-73f2-0310-859d-f6bbb57e9c96

modified overlay to stay outside DMA buffer if it exists.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11091 a95241bf-73f2-0310-859d-f6bbb57e9c96

added invert_rect DMA acc function. Tested in all colorspaces on NV11 (OK).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11090 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated DMA acc to use the full DMA buffersize instead of just one quarter.
Also improved forced freespace limit setting in this buffer, now finally completely preventing engine crashes it seems.
Engine speed went up again due to larger DMA buffer.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11089 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed fill_rect and fill_span 8, 15 and 16 bit colorspaces for NV10Arch. Tested and OK on NV11.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11080 a95241bf-73f2-0310-859d-f6bbb57e9c96

updated DMA engine error handling: the driver should nolonger hang (again) if the engine crashes.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11018 a95241bf-73f2-0310-859d-f6bbb57e9c96

finalized DMA buffer overfill checking for optimum speed. On NV11 accelerated functions are running at 130% to 200% speed in DMA mode compared to the 'old' PIO mode. Without trouble now.
Still only 32bit mode, and still missing invert_rect function though. Also still not explicitly adhering the engine constraints which needs to be rechecked/retuned compared to PIO mode (hence the non working 800x600x8 mode I expect..)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11009 a95241bf-73f2-0310-859d-f6bbb57e9c96

added checking to prevent DMA buffer overfills: it turns out for instance NV11 can't keep up with BeRoMeter and the engine crashes otherwise. It turns out NV11 is currently only working correctly in 32bit color mode BTW.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11005 a95241bf-73f2-0310-859d-f6bbb57e9c96

shut-down that dumb ISA access for DMA. Acc speed just went through the roof! (testing with BeRoMeter). I'll now compare DMA and non-DMA speed on NV11 8-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11003 a95241bf-73f2-0310-859d-f6bbb57e9c96

DMA versions of fill_rect and fill_span (same core func still) are up! Removed some testlogging, their load became too high with these new functions added :)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11001 a95241bf-73f2-0310-859d-f6bbb57e9c96

small cleanup. This fixes DMA buffer freespace tracking as well.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11000 a95241bf-73f2-0310-859d-f6bbb57e9c96

added fill_rect and fill_span functions (same). Not yet exported, not yet working either..


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10986 a95241bf-73f2-0310-859d-f6bbb57e9c96

added timeout and abort for DMA idle waits. This keeps the system responsive if the DMA engine fails, which is way better than a complete hang. Adding this because it's not impossible to create a situation that stalls DMA: for instance if a video app writes (way) outside it's allocated overlay buffers.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10976 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed DMA buffer wraparounds. DMA acceleration is now stable on NV11 and NV43. Enjoy.. (still missing acc hooks will be setup asap.)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10959 a95241bf-73f2-0310-859d-f6bbb57e9c96

small cleanup (mostly comments updates)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10944 a95241bf-73f2-0310-859d-f6bbb57e9c96

another nice milestone: NV43 (GeForce PCIe 6600 GT tested) has acceleration up and running as well now!. Please note that the same restrictions apply here as I just mentioned for NV11: to be fixed asap of course ;-)
Jippieeee!


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10941 a95241bf-73f2-0310-859d-f6bbb57e9c96

added explicit clearing of the hashtable engine RAM. This sneaky thing won't get to me again: it keeps it's contents even over power-outages of upto say 15 seconds!!


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10932 a95241bf-73f2-0310-859d-f6bbb57e9c96

small logging correction for DMA_PUT.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10847 a95241bf-73f2-0310-859d-f6bbb57e9c96

The DMA_PUT register is write-only on some cards (confirmed NV11).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10846 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed a stupid error I introduced with cleaning up some stuff: FIFO channel assignments should now work. Confirmed NV11 BTW being at the same level as NV43: DMA works, engine not yet.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10839 a95241bf-73f2-0310-859d-f6bbb57e9c96

completed NV10 architecture DMA programming to the same level as NV43. Hopefully this engine will show more signs of life than NV43 still does..


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10800 a95241bf-73f2-0310-859d-f6bbb57e9c96

added cmd defines (CTX registers) for pre-NV40 cards, corrected a CTX programming error for NV40 and higher (2d_surface).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10798 a95241bf-73f2-0310-859d-f6bbb57e9c96

added setting pattern colorspace (DMA)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10795 a95241bf-73f2-0310-859d-f6bbb57e9c96

added 2D_surface setup (DMA), added fifo channel assignent check for aquire_engine, cleaned some stuff up.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10793 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed FIFO channel pointer error that caused assert_fifo to always fail (DMA, >NV40). Should fix driver hanging after changing workspaces with different modesettings on NV40 and later.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10792 a95241bf-73f2-0310-859d-f6bbb57e9c96

added 2D_surface command engine defines and FIFO channel assignment: used for setting buffer colorspace, location and pitch later on.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10771 a95241bf-73f2-0310-859d-f6bbb57e9c96

more DMA related programming. Still acceleration this way is disabled. DMA command fetching now actually works on GeForce 6600/NV43 (verified). The acceleration engine still refuses to process the fed commands (correctly) though. OTOH: programming not yet coplete ;-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10734 a95241bf-73f2-0310-859d-f6bbb57e9c96

modified cmd handles, added DMA blit partly. Still untested.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10713 a95241bf-73f2-0310-859d-f6bbb57e9c96

added DMA cmd related info


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10711 a95241bf-73f2-0310-859d-f6bbb57e9c96

more DMA stuff


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10709 a95241bf-73f2-0310-859d-f6bbb57e9c96

added more DMA programming: cmd buffer and FIFO setup.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10701 a95241bf-73f2-0310-859d-f6bbb57e9c96

added checking for engine idle: which is actually the case over here :-)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10666 a95241bf-73f2-0310-859d-f6bbb57e9c96

added DMA engine initialisation code for NV40 and higher. Still disabled, and needs support from driver (reserve DMA buffer RAM etc)


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10660 a95241bf-73f2-0310-859d-f6bbb57e9c96

added cursor HW bug workaround for NV40 and higher on CRTC1; added seperate acc file for DMA test setup for NV40 and higher (for now).
The driver now works by default on NV40 and higher, but without acceleration.
If someone tests using overlay, let me know if it actually works: NV43 seems to have a new engine, NV40 _might_ still have the old, and so, useable engine.
NV40-plus overlay is something we will NOT have any time soon!


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10651 a95241bf-73f2-0310-859d-f6bbb57e9c96