16 May 2021, 14:41 | #141 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
Quote:
|
|
19 May 2021, 14:38 | #142 | |
Ancient Amiga User
Join Date: Mar 2018
Location: Elkhart, IN USA
Posts: 207
|
Quote:
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 Last edited by gdonner; 29 May 2021 at 20:22. |
|
19 May 2021, 15:57 | #143 |
Semi-Retired
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 2,002
|
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.
|
24 May 2021, 19:01 | #144 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,515
|
Quote:
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. Code:
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 Last edited by Toni Wilen; 24 May 2021 at 19:11. |
|
30 June 2021, 17:33 | #145 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
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. |
30 June 2021, 18:54 | #146 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
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. |
30 June 2021, 21:52 | #147 | |
Amigan
Join Date: Feb 2012
Location: London
Posts: 1,311
|
Quote:
Would have been nice to hear about this from Jens (iComp). I appreciate this is not your problem. |
|
30 June 2021, 23:40 | #148 |
Ancient Amiga User
Join Date: Mar 2018
Location: Elkhart, IN USA
Posts: 207
|
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! Last edited by gdonner; 01 July 2021 at 16:06. |
01 July 2021, 09:10 | #149 | |
MTN/SPT
Join Date: Sep 2019
Location: Germany
Age: 53
Posts: 61
|
Quote:
My setup: chipset -> internal VGA-out ZZ9000 -> ZZ9000 HDMI-out Thanks for the huge update! |
|
01 July 2021, 11:02 | #150 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
Quote:
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. |
|
01 July 2021, 12:04 | #151 |
Guru Meditating
Join Date: Jun 2014
Location: England
Posts: 2,339
|
Superb update. Looking forward to trying this with my machine that has a Voodoo3 and ZZ9000
|
01 July 2021, 14:18 | #152 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
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. |
01 July 2021, 14:38 | #153 | |
MTN/SPT
Join Date: Sep 2019
Location: Germany
Age: 53
Posts: 61
|
Quote:
|
|
02 July 2021, 12:25 | #154 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
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. |
03 July 2021, 12:39 | #155 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
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. |
06 July 2021, 13:57 | #156 |
Guru Meditating
Join Date: Jun 2014
Location: England
Posts: 2,339
|
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) Last edited by trixster; 06 July 2021 at 14:13. |
06 July 2021, 14:10 | #157 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
Quote:
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. |
|
06 July 2021, 14:14 | #158 |
Guru Meditating
Join Date: Jun 2014
Location: England
Posts: 2,339
|
Thanks for the reply, Thomas, I'll do some more testing
|
06 July 2021, 15:30 | #159 |
Semi-Retired
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 2,002
|
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.
|
06 July 2021, 16:35 | #160 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
P96: What's the right way to do X? | Warty | Coders. General | 2 | 21 December 2020 00:00 |
Providing 2 fire button support / cd32 joypad support | amigapd | request.Other | 0 | 13 July 2015 17:20 |
Portaudio support (was: WinUAE support for ASIO drivers) | Amiga1992 | support.WinUAE | 57 | 28 March 2009 21:15 |
Classic WB P96 | Anubis | project.ClassicWB | 5 | 08 May 2006 14:30 |
amiga-news.de: Collected software-news | Paul | News | 0 | 14 November 2004 15:50 |
|
|