@nikitas

It's a pity that disabling the ethernet & other things made no difference.

Could you try compile and run the code I gave in this post above? Remember to link with -lauto.

Edit: It should compile with gcc -o MicroDelayTest MicroDelayTest.c -lauto

It'll let us know if there's a problem with MicroDelay() or not.

Hans

@Hans

Quote:

No, I tried all the possible combinations, and it didn't go any faster. The only thing that maybe helped a little was removing bochs-diplay and using Evdev for USB devices.

Also, the command:

Made a visible difference. But just a bit.

I also tried a funny thing using a read vga-to-vga on a small old monitor I found. I got the error "Couldn't create screen mode." I think this monitor supports 640x480.

@elfpipe

try to contact them if they can reset your password http://www.a-eon.com/?page=contact

@Maijestro

sigh...fixed

No, I don't believe something as modern as the 7800XT will work. That's more modern than the 6700XT in my gaming PC (and considerably cheaper - hmm!).

I believe the RX500 series is as recent and powerful as it gets. By that, the RX580 8GB is the best supported card. For the vast majority of the time you won't get any benefit from anything higher than RX550, but there are certainly a few games like Dhewm3 where every FPS counts and in that respect, RX580 > RX550. But not by much, just a few FPS. I know since I own both cards and have tried them.

Someone please correct me if any of the above is wrong.

@balatonQuote:

Could be wrong, but I don't think the x11 "vesa" driver needs any special Linux kernel options. There's another X11 driver "fbdev" which does use that Linux kernel framebuffer stuff.

In theory to use "vesa" driver it's just a matter of editing xorg.conf (in /etc/X11) (or save a modified version whereever you want) and look in the "Device" section in there and edit it to say:

Driver "vesa"
Option "ShadowFB" "0"

Many years ago that was enough. But nowadays if you try to start X11 (startx -- -xf86config myxorg.conf) it may fail and the log (var/log/Xorg.0.log) says "vesa: Ignoring device with a bound kernel driver". That seems to be because of the still existing normal gfx card (in my case "nvidia") kernel modules in memory.

So here what I do is to first log out of desktop, use CTRL ALT F1 to switch to virtual console, run "init 3" to get rid of X11 (KDE) display manager, then "lsmod | grep nvidia", then "rmmod" the modules (you need to find the right order, ie. which ones to remove first, otherwise it says "module is in use by ...") and then "startx -- -xf8config myxorg.conf". For some reason here the screen first appears somewhat broken (don't know if it's just the monitor), ~zoomed, ~like_wrong_modulo, so I also have to do some CTRL ALT F1 -> CTRL ALT F7 forth and back switching and then it displays fine.

If the thing is slow and you see flickering mouse sprite (because of disabled shadow framebuffer) in front of gfx updates (like "glxgears" window) it worked.

Google how to disable "compositing" on your desktop. There may be some shortcut key for it. To verify that it's disabled run "xcalc" or "xclock" from a terminal. Press CTRL+Z to freeze the program. Then drag it's window out of screen and back in. If this creates gfx trash or gfx disappering (like text/numbers) then it worked. (Happens because program is frozen and cannot update/refresh areas of window which became hidden and then visible again. With enabled compositor this does not happen, because the windows contents are backed up in their own pixmaps=bitmaps and the contents don't get lost when dragged out of view or behind things).

x11perf -shmput500
x11perf -shmget500

It's unlikely that it is not running in 4 byte per pixel screenmode (so that you can interpret x11perf results/sec as million_bytes/sec) but if you want to check then look if "xdpyinfo" says "32" for "bitmap unit". Tough I'm not 100 % sure that really reflects the "bytes per pixel". (don't know or remember why but AROS hosted X11 driver even creates a dummy test XImage and then picks the bytes per pixel from it).

@AmigaOldskooler

Well - first of all, I can't log in.

It's been years since I used the account, and obviously I haven't the faintest what my password is. The password reset function doesn't work - it never sends me anything.

I have tried creating a new account for a different email. I have been able to log on, but I cannot buy anything. Every function related to sales fails to work.

@kas1e

Thanks, I will give it a try.

@Raziel

Quote:

There seem to be problems with your server again, I can't retrieve or download "infrequent builds".

Hello,
I found for good price brand new ASUS Radeon RX 7800 XT 16GB Dual graphic card.

Shall I buy it for my AmigaOne X5000 or my AmigaOne X1000?

Will it provide me with any benefit over the AFox Radeon RX550 4GB that I have in my X5000 currently, or over the XFX Radeon Black Double D R9 280X 3GB DDR5 that I bought for X1000?

I've removed the XFX from X1000 because it was too noisy for my taste, but I can place it back if needed for tests or serous work (although recently I am more working with the X5000) and sometimes the Apollo Core V4+SA.

@elfpipe
Max wrote java clone of amistore which you can use to buy things from OS where java works (i mean PC with windows at least): https://github.com/migthymax/JAmiStore

I never understood why there wasnt pc version of amistore compiled (as it hollywood in end) or simple webshop to use from any os, but that how is it

What kind of problem did you encounter with AmiStore? Maybe we can help with a workaround.

Hi all, and thanks for the feedback!

I will look into what you wrote @pjs. That is a good idea for the next report!

@smarkusg: Will update the roundup with the information from you. Many thanks!

@elfpipe

Just launch AmiStore program on your miggy and there is NOVABRIDGE to buy.
Read requirementes and if they fill what you use/have, then login and proceed/checkout.

Hi all,

I want to play games. I am guessing Nova Bridge will enable someting along those lines. I am not successfull with AmiStore. How/where do I get it?

Best, elfpipe

@kas1e
I've corrected the code.

@nikitas
Quote:
Remove it from the QEmu command line, and use your Radeon R7 240 for testing (geennaam said that it had no effect on his RX 5x0 cards).

I have no idea bout using the secondary real SSD drive, or the bochs-display. If you can boot to AmigaOS without them, then try removing both from the QEmu args.

@balaton
VFIO is obviously working with TCG. I was hoping to get some idea of what the overhead was when used with TCG instead of KVM, and maybe some tips on what to try.

Hans

@Hans
Quote:
Most of the people who do this want to play games in a VM that run on Windows while they want to run Linux. So they want to have the most performance and use KVM and vfio. This may mean that using it with TCG is not tested that much and with PPC at all but that does not mean it should not work. Of course we're on uncharted territory, not many people run AmigaOS on QEMU and even less tried vfio GPU pass through so it's not something that was tested and known to work. Some people tried it before for MacOS but gave up because there the firmware is needed to run the FCode ROM of the Mac graphics card (or a suitable ROM for a PC card) for MacOS to even recognise the card but QEMU's OpenBIOS can't run FCode ROMs and real Mac ROMs don't run with QEMU. (I had patches to fix both of these but they aren't upstream so one can only experiment with it with applying patches from different places so only a few people even tried. Somebody once managed to get a Rage128Pro working but don't know if it was usable.)

@nikitas
Only remove from the QEMU command. It was said that if the guest has a USB disk as with the ufat shared folder then it ran slower with vfio for some reason. I don't know if @geennaam ever talked about a network card. It does (or should) not matter what you have on the host, the theory is that maybe having other PCI devices in the guest like USB or network card may interfere with interrupts from the graphics card. Now they are on different bus and we had several patches to fix this but who knows. This was with an RadeonHD card and used pci.1 so it's different than what you've tried but we have not better idea at the moment. So remove all -device usb-* and -device rtl8139 from QEMU command line and see if that changes anything.

@joerg
Right, but i mean to put pci2pcie bridge in this adapter, so to use agp to double speed (as agp in peg2 its pci but not on 33, but on 66)

@Hans

Quote:

Okay, so do I have to remove the ethernet from the QEMU command only, or should I also shut down the ethernet on the host? Regarding the USB drive, I have a secondary real SSD drive on "/dev/sdb" that I use in the QEMU command. Is this OK? For the mouse/keyboard, I use bochs-display. Is this OK, too?

@balaton
Indeed, virsh makes it more complex. So, I will create a new QEMU setup for this when I have time.

@kas1e

But it may be better to use for example usDelay = 10 and count = 100000, or usDelay = 100 and count = 10000.