Who's Online |
90 user(s) are online ( 59 user(s) are browsing Forums)
Members: 0
Guests: 90
more...
|
|
|
|
|
Re: A1222 Development Thread
|
Posted on: Yesterday 11:27
#1
|
Home away from home 
|
@rjd324
What's the newest version of GCC that still has a usable compiler for SPE? I've been using GCC 6 for compiling SPE-specific code, but theoretically GCC 8 should still have SPE, but as a separate compiler (e.g., ppc-amigaos-gcc-spe, or something like that). I've never seen GCC 8 PowerPC SPE for AmigaOS, though.
EDIT: I think that the ultimate solution, would be a full PowerPC to PowerPC SPE JIT recompiler...
Hans
|
|
|
|
|
|
Re: Sneak Peek Inside Kea Campus' Amiga Corner
|
Posted on: Yesterday 9:07
#2
|
Home away from home
|
@all Kea Campus' Amiga Corner has just received its first how-to content: How to get an AmigaOS cross-compiler up and running on your machine quickly (see below).** It'll be public over here in about a week. Or, you can watch it now by joining the campus ( link), and support creation of more Amiga content (and software) in the process. Just say you're an Amiga user when you post in the welcome thread, so I know you're one of us. Click here to join the campus. 
** This will be followed up with more videos in future...
Edited by Hans on 2024/7/26 14:38:43
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
|
Home away from home
|
@kas1e
Reads are slower because they involve sending a request to the card, and then receiving the response (i.e., the returned value) from the card. This is inherently slower than shoveling data to the card.
DMA transfers can reduce the overhead by sending data in large blocks, so you need much fewer requests.
Hans
|
|
|
|
|
|
Re: Trying to decide between buying an X5000 and an A1222+
|
|
Home away from home
|
@mdcatdad There is a driver for USB MIDI devices here. I've never used it myself, so I can't tell you if it does or doesn't work on the A1222 (or any other machine, for that matter). Hans
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Home away from home
|
@balaton Quote: It looks like this may also be an issue on real machine which would use more power and keep the system run hotter instead of letting the CPU sleep when idle so maybe it should be fixed for the real machine too independent of QEMU. (Unless it does use something that works on real machine but not emulated by QEMU.) This absolutely should be fixed in the kernel itself. While it doesn't affect functionality, burning unused CPU cycles in a loop is a waste of energy. Hans
|
|
|
|
|
|
Re: Nova Bridge - where?
|
|
Home away from home
|
@elfpipe Quote: It worked for me also yesterday. I did some heavy shopping :). Thanks! Great! @daveyw Quote: Amistore is telling me I have £3.27 balance, but there doesn't seem to be any way for me to spend this - if I try and make a purchase, I am prompted to add the full price of the item. Could you try contacting Amistore's customer support (there should be one)? I shouldn't have to be the go-between. I don't know how Amistore works. Maybe it doesn't have a system to split the bill between store credit and a different payment method. Hans
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Home away from home
|
@Capehill Quote: Did you test Tequila's PROFILE switch, by the way? I added simple profiling support because Hieronymus didn't work on my systems initially (but it was luckily updated later and started to work). I did a long time ago, and can't remember what issues I encountered. For what I'm measuring, I'd prefer something that doesn't open up a GUI window, and simply records the data for X number of seconds, and then reports what happened. Hans
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Home away from home
|
@joerg Quote: Which (emulated) CPU? IIRC the power saving code in it was only working/used on 603e, 750FX and 750GX CPUs, not on 604e and 74xy CPUs.
Not sure about 750CXe any more, the THRM registers aren't supported/working, power saving mode may.
I don't know if QEmu supports emulating the power saving modes at all, or in a way that it's stopping the emulated CPU like real CPUs do. Ranger says: PowerPC 74XX Apollo Quote: Even if it's working you can't check CPU usage with tools like Tequila as that's restarting the CPU 5000 times/sec. with timer.device interrupts and the CPU usage calculation method it's using doesn't work if the CPU is stopped. Don't use such AmigaOS tools but check the host CPU usage instead. I checked htop when Tequila wasn't running. QEmu was still using 200% CPU on the host. Then I started Tequila, and it showed idle.task at the top. Quote: PerformanceMonitor.resource, which is used by tools like Hieronymus, isn't supported on all systems.
According to a comment on http://os4depot.net/?function=comment ... ment/debug/hieronymus.lha from 10 Nov 2012 by kas1e Pegasos2 is one of the unsupported ones. That's a pity, because hieronymus can tally up CPU usage on a per-function basis when debug symbols are available. @Georg Quote: If the guest OS does something (like "stop" on 68k, or "hlt" on x86) which lets a real cpu know that it is supposed to sleep (until interrupt happens), then an emulation of that cpu can know, too. Exactly. I'd forgotten about idle.task, which is a bad idea because it prevents CPU power management from working. @smarkusg Quote: I wouldn't even worry about it. Modern operating systems are able to distribute this across their cores. Of course, there is a limit.
For example the Apple M1 MacOs. I have no idea how they do it on "x86" (Window...). Linux is a matter of cpu sheduler and kernel (sheduler = not only those included in the stable/official release of the kernel in the distros) .... It's certainly not affecting the usability of my system, but it wasn't the behaviour that I was expecting. I was wondering if there was something wrong with the emulation that, if solved, might boost performance. Hans
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Home away from home
|
@joerg
I just tried the CPUTemp docky on os4depot, and the idle.task is still eating up all free CPU time. Looks like there's no easy way to disable it.
Hans
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Home away from home
|
@joerg
Yes, the idle.task is indeed the culprit. The Tequila profiler shows the idle.task at the top. Sadly, hieronymus doesn't work for me (either it doesn't work on the Pegasos 2, or doesn't work on QEmu).
I'll try the CPUTemp docky.
Another oddity that I've noticed, is that moving the mouse pointer lowers the CPU usage of the second qemu process (at least with the SM501), as does drawing a lot of graphics (at least with VirtioGPU).
Hans
|
|
|
|
|
|
qemu 200% host CPU usage at idle?
|
|
Home away from home
|
According to htop, QEmu has two processes that collectively use ~200% CPU time on the host, even when AmigaOS is idle. That's basically 2 cores being hogged all the time, even when doing nothing.
Does anyone else have this? What is QEmu doing that takes up all that CPU time? I would have expected host CPU usage to be low when the guest OS is idle.
Hans
|
|
|
|
|
|
Sneak Peek Inside Kea Campus' Amiga Corner
|
Posted on: 7/11 14:13
#12
|
Home away from home
|
It's been a few weeks since the Kea Campus launch. There's still a lot of work to do, but some additional content has been added. This includes the first actual content to the Amiga corner (beyond forum discussions). Here's a peek at what the campus home looks like right now:
Learn more by clicking here.
Edited by Hans on 2024/7/26 14:39:10
Edited by Hans on 2024/7/26 14:41:32
|
|
|
|
|
|
Re: Hi to all Amiga fans
|
|
Home away from home
|
@kikems Welcome! Quote: Ooohhh famouse Kikems from AmigaWave youtube channel!!! Nice! First time I hear about your channel. Looks like a great channel for Spanish speakers (not me, sadly). You should have included a link to your YouTube channel. Hans
|
|
|
|
|
|
Re: Nova Bridge - where?
|
|
Home away from home
|
@all
AmiStore emails should be working again. Could someone try?
Hans
|
|
|
|
|
|
Re: Nova Bridge - where?
|
|
Home away from home
|
@LiveForIt Quote: The only thing you need is a QR codes in AmiStore.no so you pay using mobile. That should work quite well, although the email deliverability problems do need to be fixed. Hans
|
|
|
|
|
|
Re: Nova Bridge - where?
|
|
Home away from home
|
@kas1e Quote: Your work is one of not many valuable things in whole Enhancer, and its indeed sucky how Mattew handle sales and in whole amistory problems users have all the time. Matthew is over-stretched, and really could use an extra pair of hands. That would be easier done if the Amiga market were healthier. Quote: Is it possible to ask them to give you ability to sell things you do, with giving them their part ? Or maybe rebuy it back so you will have the rights to sell it ? That's unlikely to happen. For starters, there's no way I could afford to buy it back, and I appreciate A-EON funding the graphics card projects for all these years. I doubt they'd want to sell on other platforms when they've built their own infrastructure for selling and updates (i.e., the AmiStore). Yes, it's malfunctioning at the moment, but it's likely to be a relatively small problem. I actually like the idea of the AmiStore, and I'd rather see it fully up and running again. If the AmiStore ever were handed over to me, then I'd probably rebuild the server side using WooCommerce, so you could also buy online, and then download using the AmiStore app. Very unlikely to happen, though. Hans
|
|
|
|
|
|
Re: Nova Bridge - where?
|
|
Home away from home
|
@billt Was this with a gmail address by any chance? Or another email provider that's finicky with SPF/DKIM configuration? @all I've submitted a bug ticket for this, and hope it'll be resolved soon. It's very sucky that people literally want to hand over money (in return for software), and are unable to do so. This partially happened to my store a few months ago, when the payment plugin put me in "legacy mode" without notification (you had to manually upgrade to "the new experience"), and then they broke legacy mode. I fixed that ASAP. Alas, I'm not authorised to sell NovaBridge & other items, so I can't help you with those. Hans
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
|
Home away from home
|
@all EDIT: FORGET THIS. IIRC, the drivers only use vblank interrupts. So if vblank interrupts are disabled (which nikitas has done), then there should be no interrupts. Geennaam suggested that use of legacy interrupts might cause trouble. Modern drivers use Message-Signalled-Interrupts (MSI), and it's safe to assume that almost everyone using VFIO to pass-through their graphics card has MSI enabled drivers. We don't, because AmigaOS doesn't support MSI. So, our drivers use legacy INTx interrupts. Legacy INTx interrupts need special handling and, given that few people will be using them, it's possible that QEmu's code for handling them hasn't been thoroughly tested. From here: For a legacy INTx interrupt, you should know that the vfio_irq_info will report VFIO_IRQ_INFO_AUTOMASKED, meaning that the physical interrupt is automatically masked once it is triggered since these are level triggered interrupts will would otherwise continue to fire on the host until serviced by the guest or userspace driver. To enable the interrupt, you'll want to call VFIO_DEVICE_SET_IRQS to provide an VFIO_IRQ_SET_DATA_EVENTFD for the VFIO_IRQ_SET_ACTION_TRIGGER. This will enable the interrupt and you'll be notified when an interrupt occurs via poll(2), select(2) or similar on the eventfd. As above, when an interrupt occurs and you've finished servicing the device, you'll need to unmask the interrupt before a new interrupt can be triggered. There are multiple ways to do this. As described in the header file, you might use VFIO_IRQ_SET_DATA_NONE and VFIO_IRQ_SET_ACTION_UNMASK to effect the unmask. You could also use VFIO_IRQ_SET_DATA_BOOL, but that's a bit overkill since your bool array would contain a single index for the INTx interrupt. You can also create another eventfd, such that you have one for signaling the interrupt and one for unmasking the interrupt, in that case you'd use VFIO_IRQ_SET_DATA_EVENTFD, VFIO_IRQ_SET_ACTION_UNMASK when configuring the interrupt, and then you could simply write to the eventfd to effect the unmask.
Edited by Hans on 2024/7/4 9:31:36
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
|
Home away from home
|
@nikitas Quote: I'm the poor canary flying into the mineral mine tunnel to see if toxic gas exists further inside. Let's see if I die...
I even cleaned the connectors and PCIe slot with Isopropyl 90. I found the (hidden) mvme SSD, removed it, and placed it in another slot away from the CPU. (in case it was using PCIe lanes as read). What else can somebody do, I wonder. I think that we can safely rule out hardware issues. I've seen some threads about VFIO performance issues with Windows, and there it's always a matter of messing with the sofware configurations. Quote: Could be a problem that I don't do Single-GPU passthrough? I use the integrated GPU for my host and I pass the RX550 through QEMU/VFIO, plugged in a second monitor for the guest OS. AFAIK, that's a pretty normal set up. Geennaam also gets poor performance with the RX 550, and his Radeon HD card also slowed down with ethernet or an emulated USB flash drive. @balaton Quote: Maybe the HD card could work if MicroDelay didn't have a problem with that card. This might mean these cards are slow for different reasons. It's also possible that problem with HD card is not actually in MicroDelay but could it be that something is disabling multitasking so the test runs slower even though the delay would return in time? What could do that with only the HD card but not RX card and how could that be confirmed? Maybe snoopy can log calls to Disable/Forbid and see if there are more of these with the HD card than RX card? I'm shocked that the graphics card had any impact on MicroDelay(), because the graphics card is NOT involved in that function. The RadeonHD driver does have an added Disable()/Enable() when enabling/disabling the vblank interrupt, but that shouldn't be happening more than twice the monitor's refresh rate. If nothing is waiting for the vblank, then that code doesn't get run at all. If Snoopy can log Disable()/Enable() calls, then yes, it'll be possible to see if there's more of them with the RadeonHD card. Hans
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
|
Home away from home
|
@nikitas Quote: Is this a problem, or is it expected? Not a problem, but also not expected. Quote: Running this script with:
- R7 240 attached, took about: 24 seconds.
- RadeonRX 550 attached, took about: 1.50 or 2 seconds
- RadeonRX 550 attached with Screenmode --> Enable Interrupts = Checked, took about: 1.0 or 1.5 seconds
- RadeonRX 550 attached with Screenmode --> Enable Interrupts = Checked and Ethernet attached and using bochs-display, took about: 1.0 or 1.5 seconds (same as the test above)
When I enable interrupts on Screemode, the systems seem to run slower overall, though this test appears to execute faster.
You're RX 550 results aren't too far off, but the R7 240 result is 24x slower than it should be. I didn't expect there to be a dramatic difference depending on which graphics card is plugged in. That doesn't make sense. It does confirm that MicroDelay() can indeed be a problem, although it's not necessarily the cause of the massive graphics slow-down. Hans
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
