Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (balaton)

Bottom

« 1 (2) 3 4 5 ... 57 »

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/28 18:19 #21

Just can't stay away

@smarkusg
Quote:

You mentioned somewhere that the QEMU sam460ex emulation is to be removed. I won’t bother you with this matter.
It’s just worth noting that this issue occurs in QEMU-11 and ati-vga.

Not the sam460ex machine is to be removed (as long as I maintain it) but maybe the U-Boot for it which needs old compiler so it's a problem for distro maintainers. I updated sam460ex U-Boot hoping it might help with GPU passthrough but it still has issues so it did not help much. Either I can update to latest U-Boot and see if that fixes problems or just revert to the old version if that works better. The old U-Boot version is still available in older QEMU versions (10.1.0 and older) so one could also get it from there and replace it until I can fix it upstream if that version works better. The new sam460ex U-Boot also seems to have an issue with USB on AROS so it seems it needs some fixes anyway.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/28 18:09 #22

Just can't stay away

@joerg
This might depend on more things like host CPU and OS as well but at least the option is there to test different ways and use what's best for a given situation. Maybe somebody interested finding out more could test these. Here are the options:
- NOBLITTER in monitor icon should use guest side JIT compiled functions and only use the driver as plain frame buffer
- -device ati-vga,x-pixman=0 disables pixman and always uses fallback on host side
- no special options uses pixman on host side if available or fallback if QEMU is compiled without pixman or call to pixman fails
Testing on one system does not mean all systems would get the same result so I guess everybody needs to try and find what works best for them but reporting test results might still be interesting.
The ati-vga currently does not run async (that's for future enhancement) but the sm501 also doesn't and it has similar usage of pixman and fallbacks so I don't understand why they behave differently. Either there's something the sm502 driver does differently or it's because of some difference between the sm501 and ati-vga that might be fixed if we found out what it is.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/27 23:07 #23

Just can't stay away

@smarkusg
I've tested with amigaone and pegasos2 as that's probably what most people use, did not bother with sam460ex. As the sam460ex U-Boot has an ATI radeon driver it probably tries to init the card which fails without an appropriate ROM and we don't have a ROM that works with the x86emu in sam460ex U-Boot. So maybe you need to add -device ati-vga,romfile="",... and live with only serial output. The driver should still work once AmigaOS starts. I'll watch the video later.

EDIT: So QEMU vgabios does not work and romfile="" also crashes. There are some real card ROMs here with which I get no picture in U-Boot (ROM does not seem to run fully and interrupted by U-Boot) but at least it starts to boot but after the splash screen I got errors that I'm not sure is something wrong with my test image or some other problem.

Edited by balaton on 2026/4/27 23:42:27
Edited by balaton on 2026/4/27 23:42:55

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/27 21:07 #24

Just can't stay away

@joerg
Quote:

Did you implement all of the BoardInfo->Blit*() functions in your driver?

No but neither does the sm502 driver and this benchmark specifically seems to excercise BlitRectNoMaskComplete only so only that should matter.

Quote:

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.

I guess you can test that with setting NOBLITTER in the monitor icon which should disable the driver functions and use the AmigaOS defaults but I did not try that. But especially for larger blits doing it host side with native routines should be faster.
Quote:

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).

I haven't seen anything using other than 0xFF mask and BlitRectNoMaskComplete cannot even use a mask, plus the docs say that's only used for planar mode which is not implemented in my driver so this should not matter.
Quote:

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.

The defaults seem to allocate with enough alignment for ati-vga which I think is 16 bytes aligned.

Quote:

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.

The results from smarkusg does not seem to prove this theory where only one screen is allocated for ati-vga but more than 4 for sm501. There may also be wrong rounding in the displayed value because it says 3 MB for what should be 3.9 MB.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/27 20:52 #25

Just can't stay away

@kas1e
No it should have a lot of resolutions from qemu-edid even higher than 1920x1080. Maybe you have a Devs/Monitors/Radeon icon with tool types that disable DDC and do not define modes? You could either enable DDC in the monitor icon or delete or move it to Stroage so the defaults will be used.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/26 21:33 #26

Just can't stay away

@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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/26 20:44 #27

Just can't stay away

@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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/26 20:39 #28

Just can't stay away

@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?

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: pegasos2: rom reconstruction

Posted on: 4/26 20:33 #29

Just can't stay away

@kas1e
Yes you'd need a ROM matching the emulated card as there were some changes in registers between these Radeon chips so other ROMs might not find the registers they need. If your updated x86emu can handle the default QEMU vgabios (which comes from SeaBIOS) then that should also work for usual VESA stuff.
For real cards the driver that comes with AmigaOS should work and would be better but the QEMU ati-vga is not complete enough to work with that driver and it was easier to write a minimal driver than to implement the missing features in ati-vga. When ati-vga is improved, we may eventually be able to go back to the AmigaOS driver so my driver is just a stop-gap until then. For a real card a lot more init and clock setup stuff would be needed that is not needed for QEMU so I did not care to implement those so my driver would not work with a real card.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: pegasos2: rom reconstruction

Posted on: 4/26 16:01 #30

Just can't stay away

@kas1e
Since no other firmware has driver for SM502 than sam460ex U-Boot and SM502 does not have BIOS ROM this won't work with -device sm501 on pegasos2. Maybe such SM501/SM502 card does not even exist or if it does exist QEMU does not emulate that card, but if you can find a ROM for such card you may try with that. So yes, most likely to work with both BIOS and AmigaOS is ati-vga,model=rv100 with QEMU specific AOS4 driver but we need to find a ROM that works with it and I think those you tried did not work but maybe now with update x86emu they work now?

Alternatively you can try with MorphOS and -device ati-vga (without model=rv100) that works with both BIOS and MorphOS driver.

Apparently an SM502 based graphics card exists but where do you find a BIOS image for that?

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: pegasos2: rom reconstruction

Posted on: 4/26 15:11 #31

Just can't stay away

@kas1e
I have no idea. Why would you want to use sm501 and vga together? -device sm501 probably also needs -vga none so the firmware does not try to find a VGA device as that might have priority over sm501 which is not expected on anything else than on Sam460ex and even there it's disabled if there's a VGA device. On the other hand specifying -device cirrus-vga or -device ati-vga automatically disables the default -device VGA so you don't strictly need -vga none with those but it also does not matter if you add it just not needed, because there can only be one VGA device with legacy ISA IO ports and maybe additional secondary-vga devices so if you add another vga compatible device the default std-vga is replaced by that.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/26 15:06 #32

Just can't stay away

@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?

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/26 12:53 #33

Just can't stay away

@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?

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: pegasos2: rom reconstruction

Posted on: 4/26 11:11 #34

Just can't stay away

@kas1e
Quote:

PS. IF you have time, the things which surely will help, is adding X1000 support to the QEMU with basis of what Balaton already upload in other thread for initial X1000 qemu support, so we can test CFE patches on it before i can risk to flash one of the chips.

Might work for testing but would be wasted as it cannot be upstreamed: https://www.qemu.org/docs/master/devel ... e-of-ai-generated-content

For the bootstrap code you can probably take the startup for the original Marvell Discovery development board from U-Boot that I linked to at the beginning of this thread and fix that up. You can't legally take disassembled code from bPlan and just recompile it to be able to distribute it but the U-Boot code is legal to use.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: pegasos2: rom reconstruction

Posted on: 4/26 11:06 #35

Just can't stay away

@derfs
Where does m48t59 RTC come from? I don't see it mentioned anywhere and could not find it on the shematics either. So I don't know what real machine has for NVRAM, maybe it's stored in the flash? It does not really seem to have m48t59 and RTC is just part of VT8231.
The confusion in PCI0 vs PCI1 may come from that SmartFirmware (or QEMU so the default is the PCI bus) numbers them the opposite as MV64361. I think one of the MV64361 PCI buses is 66MHz which is used for AGP and the other is 33 MHz which is used for PCI in Pegasos2 but I forgot the details.
If you (or the AI) took any code from QEMU your license will be GPLv2-or-later, you can only have BSD license if no code is taken from GPL sources such as U-Boot or QEMU. You probably can't tell where the code from AI comes from so it's safer to go with GPL also to avoid some rougue company later taking your work change it and lock you out from your own sources.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/26 10:59 #36

Just can't stay away

@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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/25 19:12 #37

Just can't stay away

@Maijestro
Quote:

Here are a few numbers for you:

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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/25 17:57 #38

Just can't stay away

@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?

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/25 17:54 #39

Just can't stay away

@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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/25 15:18 #40

Just can't stay away

@joerg
No its board name is "Radeon (QEMU ati-vga)" overriding the Radeon 7000 name PCIGraphics.card sets and before I had DDC working I tested it with a monitor icon named Radeon with BOARDNAME=Radeon and CMPLENGTH=6 and that worked and picked up modes from it so I think that should work. But now with DDC you probably don't need a monitor icon at all and would get monitor info and modes via DDC. I've also found before that AmigaOS 4 does not really use BOARDNAME but the name of the monitor icon file has to match the driver name (which may not be the same as the kernel module name but what it sets as the board name). So no, CMPLENGTH does not compare to ATIRadeon.chip file name but to the "Radeon (QEMU ati-vga)" name the driver sets as the board name (or to the names set by PCIGraphics.card which seems to begin with Radeon for all ATI cards). Therefore a monitor icon named Radeon with CMPLENGTH=6 should work.

https://qmiga.codeberg.page/

Topic | Forum

Top

« 1 (2) 3 4 5 ... 57 »