What the fastest possible x64 emulation way of OS4 today ?

@balaton
Even if it may not required because of DCC/EDID support it can still help to have a DEVS:Monitors icon disabling some gfx library/P96 parts QEmu doesn't emulate (yet):
- In @smarkusg's screenshot the "Dragable" bit is enabled, which doesn't work in your driver according to your docs (drag down a screen and display parts of another one, maybe using another resolution, or even different depths like 8/15/16/24/32 bit modes, behind it).
- DISABLEFAKENATIVE (not enabled in @Maijestro's screenshot) should be disabled with DISABLEFAKENATIVE=YES, as long as 8 bit CLUT modes aren't supported completely.
- INTERRUPT=YES, or the probably still supported alternative NOINTERRUPT=NO, shouldn't be used for gfx drivers without VBLANK interrupt support.

@balaton
Even if it may not required because of DCC/EDID support it can still help to have a DEVS:Monitors icon disabling some gfx library/P96 parts QEmu doesn't emulate (yet):
- In @smarkusg's screenshot the "Dragable" bit is enabled, which doesn't work in your driver according to your docs (drag down a screen and display parts of another one, maybe using another resolution, or even different depths like 8/15/16/24/32 bit modes, behind it).
- DISABLEFAKENATIVE (not enabled in @Maijestro's screenshot) should be disabled with DISABLEFAKENATIVE=YES, as long as 8 bit CLUT modes aren't supported completely.
- INTERRUPT=YES, or the probably still supported alternative NOINTERRUPT=NO, shouldn't be used for gfx drivers without VBLANK interrupt support.

@joerg
You can have a monitor icon and experiment with settings but likely it won't make much difference as what is not emulated is already disabled in the driver. For the cases you listed:
- You can drag screens down but it likely won't reveal other screens behind and just show black emptyness instead of other screens but screens are draggable. (May need latest QEMU 11 though as this needed a fix.)
- 8bit CLUT modes should work, the boot splash screen is using that too.
- It does not matter if you enable or disable interrupts, the driver has an empty handler that just returns FALSE so it will never do anything. QEMU has a dummy 60Hz vblank interrupt for ati-vga because MacOS needed that so this could be supported but since it's not synced to host screen it would not matter much so I did not bother to try to implement it. Interrupts will only be needed when we run 2D acceleration async like real card does so it would need to signal finishing operations with an interrupt but it's not working that way in QEMU yet so no need for interrupts.
So I think the only reason you may want a monitor icon is if you want to define some non-standard resolution that's not in the list from DDC already.

@smarkusg
What do you need 128MB VRAM for? Is there anything that you can fill up the default 16MB with or if there is isn't less than 128MB enough? This seems just wasting RAM to sit unused. With todays systems that's not a problem just curious how did you end up with that number?

@smarkusg @balaton

Quote:

Compiled Qemu 11 and encountered exactly the same issues as with 10.x. A square with rounded corners in the top-left corner of the boot logo.

@balaton

Quote:

Here are a few numbers for you: the ATI VGA driver is faster than the SM502 in most areas. That’s certainly a result of the 32-bit mode. Thanks again.

@Maijestro
Quote:
Thanks but the interesting part is probably the end not shown on your screen shot. It looks like the BlitBitMap results are much lower for some reason which should not be like that. But these results seem to be with different Gfx2DBench versions and different QEMU versions so they are not directly comparable. Maybe you should rerun the sm501 test and compare that to the current ati-vga results. If that also shows slow down in BlitBitMap with sm501 too then maybe there's some problem with your installation (could be with pixman) or something in QEMU has changed.

@balaton
Quote:
Here are the results from QEMU-11 on Linux

But setting aside the ATI (QEMU) test—this is interesting https://hdrlab.org.nz/benchmark/gfxbench2d/os/amigaos/Result/3025
VirtIOGPU?

@smarkusg
32-bit screen is twice as much data than 16-bit so if it were half the speed that could be explained but it looks slower than that. What if you compare 16-bit screen (same screen mode) with sm501 and ati-vga? Maybe there's something in ati-vga that slows it down that we need to profile to find out but just comparing same screen mode first could show if that's really the case or something else. I guess you also used same settings on same machine just the driver and -display is different for these tests. E.g. not comparing theme without transparency in one case and transparency enabled in the other.

@balaton
I ran it again just now for ATI (QEMU) 16-bit
Same Linux system, same guest OS (Peg2 AOS4FE U3), same command-line limit—only the `-display` option was changed.

udostępnij zdjęcie znajomym

The option I added, “vgamem_mb=128”, does not affect the test result. Without it, the result is the same.

@smarkusg
OK so even with same screen mode there seems to be difference. What is the same sysmon info you show on your last screen shot for the sm501 case? I tried to check that but sysmon seems to be gone from os4depot where every link points. What happend to it?

@balaton
Quote:
It used to be available for free on os4dpot. Without going into detail as to why... it is currently available as part of the ‘zTools’ bundle in the AMIStore App Store (A-EON shop)
Several other programmes that were previously freely available, such as TuneNet, have suffered the same fate. At present, the situation is such that there are no new updates... just like everything else under A-EON’s control.

EDIT:
As far as I recall, only @joerg managed to update his program recently via AMIStore. The update had been available for several years, but it stopped working after the Up3 update. It is now working properly again

@smarkusg
It's not helpful that test programs are not available. So can you post the same sysinfo screen you posted for ati-vga with sm501 too for comparison?

I tested the driver on my linux system and it works great. I tested it with QEMU 10.2.1 and SDL renderer.

The only thing was that when I was increasing its memory over 128mb then the cursor changed to a big red box, that moved when I moved the mouse. I believe that other mentioned that issue here as well.

@balaton
Quote:
Here's a screenshot

@walkero
Thanks. No, others reported an issue that mouse pointer is shown when it should not be but that's a known limitation with the current state of ati-vga. I think ATI R100 can't handle more than 128MB (and typical cards only had 64MB) with larger VRAM was only available from R200, so I think you just run out of the memory window if you try to go above 128MB. But I can't imagine what can you fill 128MB with on a 2D only card so why would you want even more?

@smarkusg
There's something with BlitBitMap that I don't understand and could not find out what could cause this. It seems that smaller blits are faster with ati-vga but larger ones are slower which does not make much sense as sm501 is also using pixman similar to how ati-vga uses it and while ati-vga is a bit more complex it does not depend on size of the blit that is just passed to pixman. Without pixman ati-vga is a bit faster for me but the same slow down for larger areas still happen so it's not pixman related but don't know yet what it may be.
I wanted to check with the sysinfo screen shot that both ati-vga and sm501 has compositing enabled but it looks like no differences in that either. I'd need to dig into it more to find out what 2D ops are used on sm501 and ati-vga that could explain the difference.

@balaton
I noticed one more small thing.
The memory usage for the ATI card (QEMU) always shows very low values. I think the maximum value was 7MB even when I had 64MB or 128MB allocated.
Even that early Voodoo driver always shows a maximum of 16MB.
The screenshot for the Sm502 also shows the usage.
Maybe this is a silly observation, but is there a lack of RAM for ATI (QEMU)? Maybe that’s why it chokes during “larger” tests.

P.S.
It’s also strange that the values shown by sysmon are in Mb instead of MB. The values themselves are correct, but “Mb” is misleading.

EDIT:
Edit: Here's a screenshot, @Maijestro—it's also max 7MB
https://ibb.co/rRnNMNrh

@smarkusg
I have noticed that too that for sm501 more used VRAM is reported. There's plenty of RAM on ati-vga, you even raised it to 128MB but AmigaOS just does not use more for some reason. Could be because the grantdirectaccess option is not enabled but when I tried to enable that, the screen did not update correctly so it cannot be used before some more fixes in ati-vga. But that should not affect these GfxBench2D tests as I think that it tests VRAM to VRAM blits which should be the same regardless as it just moves around rectangles on the screen. But it's still faster for smaller blits which probably matters more in normal usage than large blits.

@balaton
Quote:Did you implement all of the BoardInfo->Blit*() functions in your driver?
AFAIK nearly all BoardInfo functions in a P96 driver can be set to NULL on AmigaOS 4.x and a fallback function in graphics.library is used instead. For example for a very simple framebuffer driver. On real hardware with HW acceleration it's usually slower, but for emulation the graphics.library functions might be faster.
IGNOREMASK should be enabled (=YES), no matter if real hardware or emulation, which requires using a matching DEVS:Monitors, or using Kickstart/p96Config (not sure if that's enabled on all systems, or only used on Classic Amigas).
Might also depend on the AllocCardMem() and/or AllocBitMap() functions, which should return at least 32 bit aligned (or more if the (emulated) gfx hardware requires it) memory.

Simple example of the required VRAM for a FullHD Workbench screen:
1920*1080*4(32 bit)*4(4 images, see below)/1024/1024 = nearly 32 MB VRAM.
1st "image": The screen bitmap itself, i.e. the final result displayed on the monitor.
2nd: The Workbench screen backdrop image.
3rd: The Workbench root window image.
4th: The Workbench drawer window images.
Add some more screens of other applications and even without using anything requiring even much more VRAM like 3D or compositing, just using plain old 2D, you can easily exceed the 64 MB VRAM of a R7000 like the onboard one in the Teron Mini/AmigaOne µA1.