Who's Online |
190 user(s) are online ( 120 user(s) are browsing Forums)
Members: 0
Guests: 190
more...
|
|
Headlines |
-
mce.lha - game/utility
Apr 23, 2024
-
theme_list.lha - utility/misc
Apr 23, 2024
-
faac.lha - audio/convert
Apr 22, 2024
-
faad2.lha - audio/convert
Apr 22, 2024
-
seq.lha - audio/misc
Apr 22, 2024
-
libfaac.lha - development/library/audio
Apr 22, 2024
-
libfaad.lha - development/library/audio
Apr 22, 2024
-
image2pdf.lha - utility/text/convert
Apr 22, 2024
-
libharfbuzz.lha - development/library/graphics
Apr 20, 2024
-
libpng.lha - development/library/graphics
Apr 20, 2024
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
|
Home away from home 
|
@balaton A bit of professional courtesy would be appreciated. You do NOT need to lecture a fellow developer about how posting problems on an obscure forum is unlikely to get them fixed. I haven't submitted any bug reports yet because, so far, I haven't had enough information to do so. Quote: But @Maijestro could also reproduce it on completely different hardware and OS so this may be something related to HIDPI display or QEMU. I just tried disabling scaling, and performance went up (still slower than expected, but a lot better). The mouse pointer also suddenly works just fine. Looks like HIDPI may indeed be a problem... Setting scaling to 200% also triggered a slow-down, and made the mouse pointer unusable again. So, any scaling is a problem. This looks like a system/driver issue (not sure which module is to blame, yet). I've seen plenty of complaints about fractional scaling causing performance issues (and other problems). AFAIK, Ubuntu is also on the conservative side when updating packages, so these problems may well have been fixed upstream already. The mouse pointer not handling scaling definitely is a QEMU issue, and there's already a bug report for it.** I'll add my observations to that ticket, and update the broken scaling bug report too... Hans ** NOTE: This is with the mouse pointer input being in normal mode. IIRC, the recommendation is to use tablet mode (with a suitable driver on the guest OS). I haven't tried that out yet.
Edited by Hans on 2024/2/23 5:27:52
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
Posted on: 2/22 14:13
#42
|
Home away from home
|
@all I'm pleased to say that updating to QEMU 8.2.1 fixed the GTK display. Unfortunately, the GTK display backend is now almost as slow as SDL2 when using the Virtio GPU device. Also, the Virtio mouse pointer is indeed completely unusable, as per this bug report. Looks like I have to put up with the slowness for now... Hans
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
Posted on: 2/22 12:24
#43
|
Home away from home
|
@smarkusg
As I said earlier, the GTK backend is completely broken on my system when OpenGL is enabled, regardless of which emulated graphics card you use. It's the same when I use the emulated SM501. No idea why it works for you but not me (and some other people who reported the same issue).
Linux has a large number of distros with different setups. QEMU's GTK code itself has two OpenGL backends (one being EGL based).
The mouse pointer issue (in one of the bug reports I linked to) is specific to the Virtio GPU device. Emulated cards like the SM501 use a mouse pointer that's drawn directly to the window. Virtio uses the host system's actual mouse pointer.
The SDL2 slowdown with a Virtio GPU display may also be specific to my system. I've seen varying reports about Virtio GPU performance (with Linux guest OSes) from "near native" to "horribly slow." It seems to vary a lot depending on which distro, hardware, libs and drivers people have.
I can try upgrade to the latest release (8.2.1) and see if GTK works any better. I didn't see anything relevant in QEMU's commit history, though.
Hans
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
Posted on: 2/22 10:32
#44
|
Home away from home
|
Adding SDL_GL_SetSwapInterval(0) did nothing, nor did my attempts to disable vsyncing in the drivers. My laptop has both an Intel and nVidia GPU, and I've got no idea which one it's using, or what the settings are (the nVidia control panel doesn't even have OpenGL settings).
Switching the desktop to 1920x1080 @60Hz did help, but flushing the image to screen is still hurting performance (reducing screen bitmap flushing to once every 6 frames gives approx. 3x speed up). It's still slower than the GTK backend.
I don't see anything wrong with QEMU's SLD2 GL code. Time for me to move on. I'll just have to live with it for now.
Hans
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
|
Home away from home
|
@all The problem I encountered with the GTK display backend has been around for a few years already. There are other issues too, such as broken mouse positioning and refresh rate limiting. I suspect that my problem may be SDL2_GL_SwapWindow() waiting for a vsync, or the nVidia driver forcing a vsync. To make matters worse, my monitor runs at 30Hz in 4K.** If QEMU's Virtio GPU code is running in the same thread as the CPU emulation (and I suspect that it is), then emulation gets blocked by up to 33ms at a time. Hans ** Despite this, the VirtioGPU driver is told that it's got a 60Hz screen. So, it's trying to update the screen at that rate. I wish that the EDID that QEMU sends to Virtio GPU was based on the actual monitor's capabilities.
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
|
Home away from home
|
@smarkusg Quote: Linux - SLD works without any problem, there is no slowdown. Just don't know why you have "show-cursor=on" because then there are two indicators. I have it enabled, because Virtio uses the host OS' actual mouse pointer, and otherwise you can't see it. @vagappc Quote: SPICE (the Simple Protocol for Independent Computing Environments) is the best remote display for VM. Ah, okay. The SPICE software that I know, is the circuit emulator ( link). @all I think the SDL slowness is Virtio GPU specific. With SDL, flushing the screen bitmap to the monitor is incredibly slow. That's crazy, given that the screen bitmap is in an OpenGL texture, so blitting to the display window on the host OS should be incredibly fast. Either way, drawing graphics ends up being painfully slow unless reduce how often the display is flushed (which lowers the frame-rate). With GTK, the flush operation is way faster. @Maijestro Nice to see the problem confirmed, albeit with Cocoa instead of GTK. I was hoping someone would tell me that the GTK issue had been fixed, and I just needed to upgrade. I'm currently using v8.1.0 (self-compiled). @smarkusg Quote: I guess the problem on macOS and Cocoa was fixed already in the git version because I saw on the mailing list that you helped the developer to fix it. Thanks!!! Has it also been fixed for GTK? Or for Cocoa alone? Hans
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
Posted on: 2/21 13:36
#47
|
Home away from home
|
@vagappc Quote: Is your version of qemu from the Linux distro or did you compile it?
During the build for enable the openGL it need of other package. I had to compile it, which included guessing what dependencies I had to install for the features I needed. Quote: Are you using Wayland or a regular X server?
With Wayland there is many problems with GTK I think it's X11. At least, that's what the about window says. I'm using Ubuntu 22.04.4 LTS. Quote: I am not sure, bat the acceleration opengl I think it want a client spice What's a "client spice?" I've seen spice mentioned, but have no idea what it is, or how it fits into the larger ecosystem. Either way, I can confirm that OpenGL is working. Otherwise I wouldn't be able to work on the VirtioGPU's hardware acceleration. My problem is that the GTK display is messed up, and SDL is annoyingly slow. Hans
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
Posted on: 2/21 13:19
#48
|
Home away from home
|
@balaton Quote: Since nobody else has your virtio-gpu driver nobody can experiment with it. You don't need my driver to enable OpenGL. Just add the gl=on option. I get the same behaviour with the SM501. Hans
|
|
|
|
|
|
Qemu GTK/SDL display problems
|
Posted on: 2/21 12:55
#49
|
Home away from home
|
Has anyone tried enabling OpenGL in Qemu? Everything works great without it. Once OpenGL is enabled, the GTK display mode becomes unusable. On my machine, the screen is squished into the window's lower left quadrant, and the rest of the window flickers like crazy.
The SDL display type works, but screen updates are very slow, which in turn slows down the emulated machine (at least, with the Virtio GPU device).
My display option is currently: -display sdl,gl=on,show-cursor=on, and I'm using a self-compiled Qemu 8.1.0 on Linux.
Has anyone else experimented with this? I'd prefer to use the GTK mode because performance is much better, but it's unusable in its current state (when OpenGL is enabled).
Hans
|
|
|
|
|
|
Re: About off topic news on Amigans
|
|
Home away from home
|
@geennaam Quote: I think that this site original started as "not morphos". When aros wasn't even taken seriously yet. Not quite. While it's hard to imagine now, IIRC, at one point amigaworld.net was the official AmigaOS 4 support forum. Amigaworld.net provided an OS4 centric space away from amiga.org (which had become a hotbed of inter-OS flame wars). Despite having their own forums (e.g., morphzone), AROS and MorphOS fans seem to really want to discuss their OSes on any and every Amiga computer forum. So, AROS & MorphOS "fans" also joined amigaworld.net, and arguments over the pros and cons of each OS followed. So, what started as an OS4 centric forum was OS4 centric no more. AFAIK, this is why amigans.net was started. It's stated intention was to be an AmigaOS 4 site. Basically, what MorphZone is to MorphOS. The only way to maintain this site's OS4-centric character, is to keep discussion of other OSes (including Amiga clones) off the front page. Otherwise, this place will end up like amigaworld.net, and before you know it a new OS4 centric forum will be created... What will that next forum be? Os4zone.net? AmigaNGWorld.net? LeaveUsAlone.com?  Hans
|
|
|
|
|
|
Re: can
|
|
Home away from home
|
@328gts Quote: I'm using http only with Odyssey but for some reason I'm getting the OWB error prompt (Error 60) noted above? If you're getting SSL errors, then it's trying to use SSL for some reason (i.e. https instead of http). Did you disable HTTP in ZitaFTP Server by any chance? I'll respond to your email after I've had a chance to look at it. Hans
|
|
|
|
|
|
Re: can
|
Posted on: 1/21 12:31
#52
|
Home away from home
|
@joerg Quote: Yes, and I literally told @328gts to stop using https for localhost because Odyssey clearly can't handle the SSL certificate. Quote: OWB development was stopped by Pleyo in 2009 already, anything newer wont work in OWB, incl. my AmigaOS 3.x/m68k and 4.x/PPC ports and and the AROS/x86 one, and probably not in forks of it like Odyssey either. I see no reason why Odyssey couldn't use an updated libCURL & OpenSSL. Whether anyone is going to make it happen is another matter... Hans
|
|
|
|
|
|
Re: can't login to ZitaFTP server webpage?
|
Posted on: 1/20 12:39
#53
|
Home away from home
|
@328gts Are you attempting to log in on the machine running the server? If so, just double-click on the ZitaFTP Server dock icon. I tried it, and it works just fine. Or, use http: instead of https:. There's no point in SSL encrypting a localhost connection... I have no idea why Odyssey would have trouble with the certificate. Error 35 is from libCURL. Perhaps OpenSSL is now too old, or maybe it's libCURL that needs an update. A bit embarrassing if Odyssey can't handle what was recommended SSL protocol settings years ago (e.g., min TLS 1.2, with ciphers restricted to ones that don't have known flaws). Quote: I also tried using IBrowse and I got into the login page but after putting in my username and password I get "500 Internal Server Error..Try again in a few minutes or contcat the system administrator"? Could you capture a log of this, and send it to me via email? Increase ZitaFTP's logging level to the max if needed. Hans
|
|
|
|
|
|
Re: AmigaOne X5K Video Tests - from HD7750 to RX580
|
|
Home away from home
|
@imagodespira Quote: Maybe you have to try some games for your RX580 next year (we have to solve some problems we currently cannot reproduce, some crashes on the one X5000 and not on the other... we will see how to fix it) ;)" Any idea which driver and kernel versions are used on the X5000 with these crashes? The X5000 has a larger cache-line size to most other PPC CPUs, and the kernel originally configured the cache hint instructions (e.g., dcbz) to act on the whole cache line instead of the old cache line size of 32-bytes. Needless to say, clearing too many bytes can cause trouble... IIRC, the X1000 also has a larger cache line, but it's set up to treat the old dcbz (and related) as if they operate on a 32-byte cache line. This ensures compatibility with older software that assumes a 32-byte cache line (which includes older driver versions). Hans
|
|
|
|
|
|
Re: after Enhancer 2.2 upgrade, Emotion Locks up Playing MP4 Video
|
Posted on: 2023/11/27 12:13
#55
|
Home away from home
|
@LiveForIt Quote: Checking if something has or has not composition for example is useless, because a driver can support hw ARGB composition, but not support hw YUV422 composition. So you can get false positives on that. Do a test YUV composite with the "hardware only" flag set. It'll fail with hardware/drivers that don't support it. EDIT: Make sure the test composite operation is to a bitmap that's on the target graphics card (e.g., the screen bitmap, or a bitmap that you've locked to the right graphics card). @AmigaSociety Could you log this problem to the A-EON bug tracker? We do want it to fail gracefully if the hardware doesn't support it. That'll tell you whether YUV compositing is supported independently of ARGB. Hans
Edited by Hans on 2023/11/27 12:54:33
|
|
|
|
|
|
Re: PCI virtio driver development
|
Posted on: 2023/11/21 6:00
#56
|
Home away from home
|
@kas1e Quote: Mean no open source, another sites to register to download it, another ownership who want to dictate when and how to use it. Maybe can be ok with closed source stuff, but with QEMU having developers to rely on closed source library, IMHO no way to go. This has zero effect on Qemu developers. It only matters to those writing drivers for AmigaOS. Incidentally, Virtio isn't only for Qemu. It's also supported by other Virtual Machines (VMs). Quote: If ppls will be in needs to contact to the Mattew (yeah, that Mattew who answer years for simple questions), to get access to the closed source library, to sign some document or register on some site, that IMHO just crazy. You're assuming that people will have to sign an NDA to get access. I don't remember them doing that with their classes. The reason that I'm encouraging people to contact A-EON, is so that A-EON is aware that people want access to the library. Hopefully that'll nudge them to take action sooner rather than later. I've already encouraged them to open up access to the library. Hans
|
|
|
|
|
|
Re: IBrowse 3.0 released
|
Posted on: 2023/11/21 4:05
#57
|
Home away from home
|
@Maijestro Quote: I do have one small criticism, your browser is really an independent development under AmigaOs, but I currently think the price of 54.99 euros is a bit too expensive without CSS support. True, from a customer perspective. From a development perspective it's a drop in the ocean of what it costs to make a browser, and AmigaOS developers don't have the luxury of spreading the costs over millions of users. "Free" browsers like Firefox get their funding from things like Google paying them commissions in return for being the default search engine. That's made possible due to millions using the browser (and therefore using it to do Google searches). Hans
|
|
|
|
|
|
Re: Touchscreen use cases on the Amiga
|
Posted on: 2023/11/21 3:56
#58
|
Home away from home
|
@AlfredOne
Could this driver be used on Qemu in "touchscreen" mode? Perhaps someone could try it out. I was going to, but am pretty swamped with other stuff.
Hans
|
|
|
|
|
|
Re: PCI virtio driver development
|
Posted on: 2023/11/21 3:53
#59
|
Home away from home
|
@Maijestro Quote: It's one and the same person see... A few people have contacted me privately, so there may actually be more than three people working on virtio drivers. @MightyMax and anyone working on virtio drivers (or considering working on) Please try contacting A-EON about using the virtio.library. It'll take care of all the low-level stuff, so you can focus on the "blk" part. Matthew might be a bit overloaded at the moment between work & family. So, be patient. Hans
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 2023/11/15 0:57
#60
|
Home away from home
|
@balaton Sorry, this is with a real machine. After the success with getting a RadeonRX working with QEMU + passthrough, kas1e wanted to see if we could get it working on a real Pegasos II. We've kind of hit a brick wall. The OS & driver need to be able to access the PCI configuration registers, but they're not responding... Quote: If this is through a bridge you may need to do something differently to access the other bus behind the bridge otherwise you may try to read device on the host bus not the bridge's bus so you'd get non-existing device that would return 0xff when you read it (which may be interpreted as 0 for BARs, I'm not sure). Maybe check some docs on how to handle PCI buses behind a bridge and check if the AmigaOS kernel does that correctly. The OS is using OpenFirmware's own callback function to access configuration registers. You tell it which domain, bus, & device you want to access, and it does it for you. That function is working with all other devices, but not with the graphics card behind the PCI to PCIe bridge. It reads zeros from the GPU's configuration registers, and 0xFFFFFFFF from the card's audio sub-device. 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
