P96 3.0.0 (and later) news and support

[Thomas Richter]

Originally Posted by Romanujan

I didn't mean PC-world chipsets - I meant software emulated virtual cards, FPGA implementations, etc. BTW, PiStorm also seems to implement RTG, I'm not sure how the Vampire handles it (do they have P96 driver, or their own solution). Of course, having a workaround for each and every such RTG provider wouldn't be feasible - but what about extended driver API that would allow them to support better screen dragging? Maybe even combined chipset+RTG screens displayed at once, if the OCS/ECS/AGA is emulated or provided by FPGA?

As stated, I don't think that this is the right way to go.

[gdonner]

Originally Posted by Thomas Richter

VA2000 does not have a line-compare register, so it does not support screen dragging. The ZZ9000 has something comparable, though cannot (at this time?) mix modes or switch palettes. Warp 1260 is to my knowledge not a graphics card at all, and MiSTer does to my knowledge not implement RTG graphics but rather only native planar graphics.

Just to clarify, all Warp cards (1260, 560, 3060/4060, CDTV-60 and 1240) use XILINX ARTIX-7 FPGA-based RTG graphics; so obviously not an older conventional "chip" per se (like the PicassoIV's Cirrus Logic GD5446).

But according to CS-Lab, all Warp cards certainly require P96 (like the FPGA-based ZZ9000) for their graphics functionality (up to 32-bit FullHD 1920 x 1080) built into each card:

"The card supports Picasso96 drivers, each user is obliged to buy the driver himself." (source: https://amitopia.com/questions-and-a...que-warp-team/)

(FWIW, all evidence so far points to CS-Lab Warp cards being among the fastest implementations of P96 graphics on classic 68k Amigas--even before being optimized by Sellen.)

More info: http://gregdonner.org/warp4060/Speci...tml#xilinxfpga, http://www.amigaone.pl/?p=2954

[Hedeon]

Does the new rtg.library support OS4 sized boardinfo struct or the old size? Asking for a friend who backported an OS4 driver to OS3 and noticed the driver writing outside the OS3 boardinfo struct with V2.1.

[Toni Wilen]

Originally Posted by fehmi

I have checked above on 2 setups - Workbench 3.X on Amiga Forever 9 and AmiKit XE.

Posting again in this thread because I am not sure if this has something to do with Picasso96 too..

It crashes (or works strangely) because uaegfx gets Picasso96 FillRect() call with RenderInfo structure that has out of bounds VRAM address (0x3ffffce0, start of VRAM is 0x40000000) and UAE validates it immediately, unfortunately using wrong function that also assumes out of bounds address equals unrecoverable situation. RenderInfo BytesPerRow is 800 (correct)

Other parameters look fine, X=0, Y=0, Width=800 (width of screen), Height=1, Pen=0,Mask=FF, RGBFormat=1

Is this supposed to happen? Or is driver expected to ignore these? (uaegfx would have ignored it if it had used correct safe address validation routine..)

Hardware mouse cursor is in use.

EDIT: after fixing validation, it seems to work (with something strange going on with mouse but I haven't debugged it yet) but there is also CPU long word writes to same 0x3ffffcxx region.

0807BD70 5346                     SUBQ.W #$01,D6
0807BD72 6b20                     BMI.B #$20 == $0807bd94
0807BD74 12c0                     MOVE.B D0,(A1)+
0807BD76 6004                     BT .B #$04 == $0807bd7c
0807BD78 22c0                     MOVE.L D0,(A1)+
0807BD7A 22c0                     MOVE.L D0,(A1)+
0807BD7C 5146                     SUBQ.W #$08,D6
0807BD7E 6af8                     BPL.B #$f8 == $0807bd78
0807BD80 5846                     ADDQ.W #$04,D6
0807BD82 6b04                     BMI.B #$04 == $0807bd88

Code is located in rtg.library. So either something confuses rtg.library or something is simpy wrong. Or something.

[Thomas Richter]

An update on this: Just minutes ago, the 3.1.0 of P96 was published by iComp. This is again a somewhat larger update, therefore the increase in version number.



The list of changes is a bit large for a single post, so I'd probably split it up and just give you the "grand overview" first:


- A new feature: Multi-monitor support. Thus, if you want to use native video and graphics card output displayed on two monitors, or have more than two graphics cards, this update has something new to offer. Tested at home with two graphics cards, two monitors and one TV.



- An all-remade CVision3D driver that addresses many of the problems the older driver has, including some performance improvements in 32bit modes, and new modes as well. If you have read the "Rumgevirge" thread at a1k.org, you already have an idea what changed (a lot). The S3 chip on this card has really some "issues" and it was unusually hard to get the diva tamed.



- A minor bugfix of the CVisionPPC driver.


- A larger bugfix of the Pixel64 driver.


- A lot of minor bugs in the core library. (Including the one reported by Toni above).


As said, I'll go through the list in the next days, it's a bit longer than usual.

[Thomas Richter]

Concerning the first new feature: Multi-monitor support.

A graphics card that has a separate monitor connected to should be indicated by "DISPLAYCHAIN=NO" in the monitor driver tool types. P96 will then keep this monitor on, even if the active screen is switched away to another screen.

This now also works for the native output (which did not work before). Thus, if you switch the output from native video away to an RTG output that is not in the "display chain", the native output remains on.

Thus, the "display chain" is the list of RGB outputs that go from the native video output, to the VGA switches of one or more graphic cards, to the final monitor:

chipset->graphics card a->graphics card b->monitor

In this setup, both graphics cards are "in the display chain" and should have "DISPLAYCHAIN=YES" set.

If graphics card a has a separate monitor as such:

chipset->graphics card b->monitor 1

graphics card a->monitor 2

then graphics card a "is not in the display chain", and the monitor icon for the card should have the tooltype "DISPLAYCHAIN=NO" included to inform P96 about this.

Now, if the frontmost screen switches from "native" or "grahics card b" to "graphics card a", the screen on monitor 1 remains on, but the mouse pointer vanishes there, and appears on monitor 2 and its "graphics card b" screen.

The only thing that did not work in this setup is that the native output always vanished when the active screen was switched away from it. This monitor then remained blank.

[nogginthenog]

Originally Posted by Thomas Richter

- An all-remade CVision3D driver that addresses many of the problems the older driver has, including some performance improvements in 32bit modes, and new modes as well. If you have read the "Rumgevirge" thread at a1k.org, you already have an idea what changed (a lot). The S3 chip on this card has really some "issues" and it was unusually hard to get the diva tamed.

Thanks for the update Thomas. Wow, so many changes!

Would have been nice to hear about this from Jens (iComp).
I appreciate this is not your problem.

[gdonner]

http://wiki.icomp.de/wiki/P96#Update...28June_2021.29

A big update indeed! This fixed some issues I was having on both my A3000 and A4000.

Thomas, many, many thanks for your hard work with this!

[mnemo]

Originally Posted by Thomas Richter

If graphics card a has a separate monitor as such:
chipset->graphics card b->monitor 1
graphics card a->monitor 2
then graphics card a "is not in the display chain", and the monitor icon for the card should have the tooltype "DISPLAYCHAIN=NO" included to inform P96 about this.

Maybe a dumb question, but does this also work for the internal chipset output of an Amiga 3000 or is that out of scope anyway, since it is not managed by RTG?

My setup:
chipset -> internal VGA-out
ZZ9000 -> ZZ9000 HDMI-out

Thanks for the huge update!

[Thomas Richter]

Originally Posted by mnemo

Maybe a dumb question, but does this also work for the internal chipset output of an Amiga 3000 or is that out of scope anyway, since it is not managed by RTG?

Multi-monitor support also means monitor 1 at native chipset and monitor 2 at the RTG graphics card. This also works. I had my TV connected to native video out, and the two other monitors to the RTG graphics. Just make sure that you take out those graphics cards from the display chain that are connected to a separate monitor.

[trixster]

Superb update. Looking forward to trying this with my machine that has a Voodoo3 and ZZ9000

[Thomas Richter]

The CVision3D received a major update as well, and it's hard where to start.

So maybe start with the supported modes: On ZII-Systems, the "byte-reversed" modes Hicolor (instead of HiColorPC) and ARGB (instead of BGRA) where not available, due to some strange bug. The card clearly supports them also on Z-II systems.

The 16-color "planar mode" is completely new. It may have some applications for legacy programs that require planar bitmaps. Due to some major trickery, we even have a hardware cursor in this mode (even though S3 seemed to believe that this is not possible. Hah!). Planar screens can also be dragged, though only 128K per plane (so 512K in total) are reachable in this mode. This is a restriction of the VGA chip. The Cirrus chip allow twice the size, 1MB in total (i.e. 256K per plane), just to put this into perspective.

A mode that was retired in the last update, but is now available again is the 24 bit BGR mode. There is unfortunately no RGB 24 bit mode, and you cannot drag 24-bit screens because they are generated entirely different. (Did I say "diva"?). If you see some artifacts while dragging windows in this mode in 1024x768, reduce the pixel clock slightly because it is really "at the edge" of what the chip can do.

For 32-bit RGBA/BGRA modes, we have again blitter support. This was disabled before, which means that the 32-bit modes are much faster. Unfortunately, BlitTemplate() and friends, in particular text writing is unaccelerated in 32-bit modes because the chip does not support it - only in 8,16 and 24-bit modes.

By an oversight, moving windows on high-resolution (e.g. 1280x1024) screens may have caused visual artifacts. This is also gone (increase the pipeline length of the video data).

The cybervision3D could only use interrupts in Zorro-III mode, and the "wait for vertical sync" was also just "bogus" in Z-II mode. This is because interrupt processing on this chip is particularly tricky. By default, interrupts are OFF now (INTERRUPT=NO in the tool type of the CVision3D monitor icon) because I'm quite conservative about this new feature, I've seen on some internal versions problems with the A3000 internal SCSI, but you can try INTERRUPT=YES as well. It should not make much of a practical difference, except that in the latter case, a WaitTOF() really synchronizes to the RTG output (and not to the native output).

The hardware accelerated line drawrer of the CVIsion3D was utterly broken and could have drawn lines that go over window edges (Try the "Lines" demo from WB 1.2!). That's gone, clipping now works. Unfortunately, line drawing in 32-bit RGBA/BGRA modes is not accelerated because the chip doesn't have it, and it is also disabled in 24-bit BGR mode because the chip has a bug here which causes the first pixel of a line to render wrong. Despite that, you always have accelerated line drawing for horizontal and vertical lines (i.e. for most GUI elements) which go through a completely different path.

There was a very minor bug in enabling border blanking. Because the chip only supports a non-black border color in legacy VGA modes, border blanking is forcefully on. This is again a strange side-effect of the S3 chip being actually"two chips in one", a legacy VGA part, and a "stream processor part", that work entirely different.

The S3 chip, or rather the P5 PCI bridge can unfortunately create "bus errors" in case the VGA memory bus is saturated. This problem of the card might have caused strange surprises in the past, such as hangs or deadlocks during rendering due to unprocessed access errors. This is hopefully addressed now by extending the CPU pipeline, and enlarging the Buster access error time out.

Finally, the S3 chip also supports a "memory window", similar to the Cirrus chip on the Picasso IV. I will say more about this feature in a later episode. Memory window support was fixed, and I'll upload a demo on this to aminet in the next days. This may also fix the memory window on Picasso IV, though I cannot check due to lack of hardware.

[mnemo]

Originally Posted by Thomas Richter

Multi-monitor support also means monitor 1 at native chipset and monitor 2 at the RTG graphics card. This also works. I had my TV connected to native video out, and the two other monitors to the RTG graphics. Just make sure that you take out those graphics cards from the display chain that are connected to a separate monitor.

Awesome, thanks!

[Thomas Richter]

Another short update on the update:

The update also includes updates of two additional drivers, one for the CVisionPPC, and another for the Pixel64 card.

As the Permedia3D chip on the CVisionPPC also provides a hardware-accelerated line drawer, I checked there the clipping algorithm, and I found that it might have been off by one pixel or so. Thus, I ported the CVision3D line clipping algorithm to the CVisionPPC, hopefully fixing some pixels. The tricky part is here to compute from the line segment passed in by the rtg.library the image rectangle that is covered by the line.

The Pixel64 card is a bit special as it is based on a proprietary extension board you need to connect to your system, and this extension board is configured and run by a vendor-specific library, the ateo.library. Apparently, the previous edition of the driver did not use this library, but tried to identify the graphics board itself, but failed in doing so correctly. Hence, the driver was updated to use the ateo.library if it is present, and in case it is not, the procedure to detect the graphics card was fixed to use the right ID to find it. Apparently, this was broken "on the way". Pixel64 cards should now be working again, both with and without the vendor library.

[Thomas Richter]

A couple of minor bugfixes at last:

- If you dragged down native screens, the background color of a RTG screen leaked through as top color of the view port. It no longer does that.

- When depth-arranging screens, P96 has to potentially copy around memory because the front-most screen has to be at address 0 of the video RAM. Unfortunately, this re-arrangement did not work for planar RTG screens. The code run into a blitter function, but this does nothing for planar screens as in such cases P96 only "mirrors" the contents of a native chipset bitmap in chip memory. Hence, things could break when depth arranging native screens.

- If two different width viewmodes were located on one view, and the topmost viewmode was wider, P96 may have attempted to trash some memory upfront the video RAM. This is the problem Toni detected upfront.

- Ellipse drawing on a rastport without a layer on 24-bit RGB/BGR screens used the wrong pen for rendering.

- Ellipse drawing in complement mode on a rastport without a layer on RTG screens was broken. This is because some of the points of the ellipse are drawn twice, and hence inverted twice - back to the original color.

- The high level functions for line drawing were cleaned up a bit and streamlined. I doubt this causes a measurable advantage, but at least the functions are now easier to read and follow.

- If creating a planar screen with a dimension or width too large to fit on the card, the initial bitmap allocation may have seem to succeeded, but as soon as the screen would be put onto the board, the result would be (obviously) an empty screen. Now bitmap creation checks early whether the bitmap type could fit onto the board, even though the bitmap is not needed immediately. This is because planar RTG screens allocate native bitmaps, and these native bitmaps are then used to update the RTG bitmaps when required.

-LoadView could cause a "hit" if the viewport would not have a color map or a rasinfo.

That should now be really it. It's really a somewhat larger update this time.

[trixster]

I’m seeing a strange situation with picasso96 3.0+ releases and PPC Warp3D, specifically with rtg.library. Simply put, fullscreen warp3d stuff is significantly slower on picasso96 3.xx than picasso96 2.xx

Using cowcat’s blitzquake gcc7 ppc release as the test, with rtg.library taken from all legacy picasso96 packages I can get hold of as well as the later icomp ones (I’ve tested 2.2, 2.4.3, 2.4.6) I’m getting around 47fps for a timedemo demo1 run-through. The versions of rtg.library I’ve tested are:

2.1e - 40.4029
2.1e with hedeon’s patch - 40.4030
2.2 - 41.12
2.4.3 - 41.14
2.4.6 - 41.15

With 3.xx I’m only getting 32fps. The versions of rtg.library here are:

3.00 - 42.540
3.01 - 42.557
3.10 - 42.713

I note from the release notes that picasso96 3.0 made changes to rtg.library to do with the Warp3D API

My test systems are using an AA3000+ Prometheus Firestorm G4 450Mhz PPC and Voodoo3, and an A4000 Mediator G3 800mhz PPC. Both systems see this ppc ward3d slowdown in fullscreen when using p96 3.xx. my workbench screen is 1280x1024x16bit and blitzquake is opening a 640x480x16bit screen.

I do not see a similar slow down in 68k warp3d (blitzquake returns the same fps scores for all versions of p96 rtg.library) but the 060 bottleneck might actually be masking any difference created by rtg.library.

Oddly, on Mediator windowed ppc warp3d is faster under p96 3.xx than 2.xx!!

Has anyone else encountered similar slowdowns? I guess I need to test different screenmodes / colour depths, and try and see if there's a difference to 68k warp3d (as it's hard to test with 68k blitzquake)

[Thomas Richter]

Originally Posted by trixster

I note from the release notes that picasso96 3.0 made changes to rtg.library to do with the Warp3D API

I haven't made any changes to that "API". Actually, there is not much of an API there in first place. The only thing P96 does is to provide the base pointer to the chip register set, and that is *it*. Everything else is up to Warp3D and the chip - 3D does not go through P96.


All I can say is "pick your screen modes wisely". Not all of them are accelerated and if the 3D part picks a non-accelerated screen mode, well, then that is it.


I believe you can try setting "GRANDDIRECTACCESS=YES" in the monitor tool type. You then get less screen modes, though maybe the ones Warp3D expects.

Another thing is that if the card does not provide an interrupt, then there is no screen synchronization. WaitTOF() runs into the native graphics.library WaitTOF() and synchronizes then to the native chipset, not the RTG chipset. So it may depend on whether there is a native screen in the back, and which type of native screen.

Sorry, not my fault. VGA chips rarely supply interrupts, and not all of the graphics cards have the interrupt signal routed to an Amiga interrupt.

[trixster]

Thanks for the reply, Thomas, I'll do some more testing

[Hedeon]

Thomas, regarding that P96 only gives a pointer to the chip registers... If you have sources to W3D_Picasso96(_PPC). library, could you change that if Prometheus is detected it assumes automatically that it should be a Voodoo3 which is in there? Or add some ENV in which you can add an address? I am looking especially at this Permedia2 PCI card that gets detected as voodoo and then the wrong address is set. 0 in stead of the same address as cvisionppc.

[Thomas Richter]

I afraid I don't, no. I believe the Frieden brothers worked on this, right? Maybe check with them?

P96 and Warp3D are really separate projects.