Re: [Qemu-devel] win98 slow with kqemu
I have noticed the same thing. Could it be that todays processors are simply very bad at running 16-bit code (that the pipeline has to be reloaded for each instruction or something similar)? If this is the case there is probably nothing else to do than avoiding kqemu with 16-bit OS:s. On the other hand, if for instance VMware is able to run Windows 98 much faster (I do not have it so I can't test this) then my guess is that kqemu is the guilty part and does something wrong with 16-bit code. Regards Dan Sandberg Mikhail Ramendik wrote: Hello, Some time ago I reported win98 slowness with kqemu, see http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00295.html I have tried again, this time on a Pentium 4 (Prescott) 3 GHz system, with Debian sarge and backports.org 2.6.18 kernel; qemu 0.8.2 and kqemu 1.3.0pre9 are locally compiled, not packaged. Still I see visible slowness with win98 guest and kqemu; it is slower than win98 guest without kqemu. The amnhld.vxd idlesness driver is installed. The problem is mentioned in forums periodically, i.e. the last reply in http://qemu-forum.ipi.fi/viewtopic.php?t=2015 . I would really like to have this fixed; I am somewhat experienced and will do what is needed for testing etc. I would try some CPU mark tests for a more objective check - but which of them will work without DirectX? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] invisible wall patch
Julian Seward wrote: Could somebody please commit, or at least consider committing, Anthony Liguori's invisible wall patch, shown at http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00112.html ? Without it, QEMU is essentially unusable on my SuSE 10 host; with it, the mouse stuff works perfectly. A couple of other people on that thread had similar experiences with it. J ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel The patch works perfectly here (qemu 0.8.1 on Windows XP host). Without it I always get the invisible wall if I leave mousegrab and enter it again close to a window border. It seems to me that SDL only reports pointer-deltas based on the movement of its own pointer (which is set invisible) and when this invisible pointer hits the window border you therefor only get delta=0 even if the guest OS pointer is still somewhere in midscreen. (Setting the SDL pointer always visible gives a good illustration of what is going on.) The guest-OS rather expects raw mouse movement deltas, than the filtered SDL-pointer deltas. Somehow the patch seems to solve this, but I can't say that I understand how (not having looked into the SDL source code). Regards Dan Sandberg ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Fabrice Bellard wrote: Dan Sandberg wrote: Just curious... Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? If not, then consider the benefits: 1. It is much faster than any native graphics 2D/3D primitives like Windows GDI 2: It gives full control over things like window or fullscreen mode in any (almost) resolution and color depth. 3. It is operating system independent. 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha channel etc in hardware, all you have to do is select the pixelformat you like to use for the buffer and OpenGL does the rest - lightning fast, minimum CPU-load. [...] I am not sure the bottleneck is in the rendering itself and the single primitive that QEMU uses (display a rectangle of bitmap) is accelerated by every graphic card since many years. But you are free to modify the SDL library to include OpenGL rendering if it is not already done :-) Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel OK, I am no expert at Qemu's inner workings as you are, but I think I have seen mentioned that host and guest pixel formats should be kept identical for best performance eg. an undesired need to select 16-bit graphics on the host when one wants to use high resolution on the guest at which resolution the emulated graphics board only supports 16-bit. I also get the impression that the quest display area is updated less frequently than the native intervall probably to keep CPU-load down and also meaning that the guest OS waste CPU-time on rendering that is sometimes thrown away when it happens in between actual Qemu display updates. To me this suggests that the needed RectangleBlit operation is not CPU-transparent and it seems from the discussions that the lower than native update frequency may introduce totally new problems like graphic artefacts or possibly the guest OS going out of sync with the emulated display adapter and a pointer that cannot keep up with fast movements sometimes. Creating a rectangular direct output area in OpenGL is actually like vitualizing a graphics card. It is updated at native speed and you can select pixelformat for that area independent of the host pixel format and you do not have to be doing any RectangleBlit operation or causing any CPU-load - to my understanding at least. The next logical step would be to emulate a more competent graphics board in this rectangular area including hardware acceleration for guest RectangleBlit operations etc. This would give much better 2D-performance for any guest OS that knows have to take advantage of it and of course OpenGL would be used for this too. It is more or less a mapping of OpenGL functionality between guest and host OS'es. No fancy 3D OpenGL stuff is needed, only the very basic 2D functionality is required to boast performance in windowed enviroments so even old and cheap graphics cards would do the job. It is OS-independent as long you can find an OpenGL-driver. I realize that the latter may be a problem in some cases so I am not saying that any of todays possibilities in Qemu should be retired, rather that it could be sort of a new plug-in module for those who want a virtual display adapter with close to native graphic performance and happen to have what is needed in terms of graphic card and drivers. I am also not suggesting that you should do the hard work Fabrice. I am truly impressed of what you are doing and don't understand how you find the time. I am also not suggesting that I know exactly how to do it, I am a beginner when it comes to OpenGL-programming and only starting to realize the possibilities of it. So I only wanted to start the discussion and hopeing for an OpenGL-genious out there with lots of spare time. :) Regards Dan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Jamie Lokier wrote: Dan Sandberg wrote: Creating a rectangular direct output area in OpenGL is actually like vitualizing a graphics card. That is what X's XF86DGA (Direct Graphics Adapter) feature does. And I believe SDL already supports XF86DGA when in full screen mode. It is updated at native speed Not necessarily. When I tried using mplayer (a video player) with the video output set to use OpenGL, it was the slowest of all options - even slower than writing the images though X11 shared memory with a copy-to-screen bitblt for each frame. But then, OpenGL drivers vary considerably in their performance and quality. and you can select pixelformat for that area independent of the host pixel format and you do not have to be doing any RectangleBlit operation or causing any CPU-load - to my understanding at least. Well, OpenGL does a RectangleBlit each time it redraws the 3d rendering area, doesn't it? If you have hardware accelerated OpenGL support, that shouldn't use much CPU. But then, the same is true for old-fashioned hardware accelerated 2d bitblt, if the pixel format is supported. [...] I am not saying that any of todays possibilities in Qemu should be retired, rather that it could be sort of a new plug-in module for those who want a virtual display adapter with close to native graphic performance and happen to have what is needed in terms of graphic card and drivers. I agree it's worth a look, because it may be faster for some people, and because it provides access to image scaling (potentially hardware assisted), which classic X11 bitblt does not. It might be worth looking at mplayer's OpenGL driver, which does something similar to what Qemu would need. Other X features which can do similar things and may provide equal or better performance are: Xv (used to display video, but generally provides a resizable overlay; may or may not provide a usable pixel format), and Xrender. -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Yes, in the worst case the OpenGL-driver is all software emulation and then it is slow and CPU-consuming. It may also be that some old OpenGL-drivers have to emulate a direct output area by bitblt operations from an off-screen buffer to the on-screen buffer and then there will be no gain, I agree. But technically that's not the only way to do the trick and newer boards should be capable of doing it much smarter without any bitblt operations involved. I still remember my old favorite, the Amiga computer with its unique virtual screens that allowed multiple programs to coexist in the same physical screen, each with its own display buffer, pixel format and all rendering in full speed. That was never done by bitblt-operations, instead much smarter by synchronized on-the-fly switching between multiple display buffers as the electron beam painted the screen. Lets say that you want to set up a 800x600 direct output rectangle with BGR-pixel format inside a 1600x1200 RGB host screen on a modern card with an adequate OpenGL driver. When the screen is painted the DAC's read from the host video buffer (1600x1200) and interpret it as RGB. Somewhere they hit the left boundary of the separate viewport that you have set up and bang, on the fly they switch to reading 800x600-organized data from the other video buffer and interpreting it as BGR. Later on the same video line they hit the right boundary of the separate viewport and bang they switch back to reading from the main buffer and interpreting it as RGB. As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are equally active and equally often updated on the same physical screen - without need for any moving data around, and without any time consuming activity at all taking place as all switches are done on the fly in the background by special hardware (if the board supports this). It is like having two separate physical video boards, each with its own display buffer. Regards Dan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Paul Brook wrote: On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote: In order to stop the release of incomplete BGR patches, I am implementing a more complete patch. I am just adding depth = 32 with BGR instead of RGB. If other pixel formats are wanted, you should signal it now. I don't have any paticular favourite pixel formats, but qemu now has [at least] 3 different sets of low-level pixel conversion routines (vga, tcx and pl110). If you're feeling really enthusiastic it would be nice if they could be unified :-) It's one of the things I've been meaning to look at when I've nothing better to do, but haven't got round to yet.. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Just curious... Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? If not, then consider the benefits: 1. It is much faster than any native graphics 2D/3D primitives like Windows GDI 2: It gives full control over things like window or fullscreen mode in any (almost) resolution and color depth. 3. It is operating system independent. 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha channel etc in hardware, all you have to do is select the pixelformat you like to use for the buffer and OpenGL does the rest - lightning fast, minimum CPU-load. My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. Hope someone likes the idea, otherwise I will have to do it myself if I can find some spare time. Dan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU 0.8.1 - Invisible wall
Thomas Han wrote:
Hi Anthony,
Sorry for the late reply. I did try out the patch with my local build
and I
haven't see that invisible wall mouse problem for a few days now.
Thanks very much,
Thomas
On 5/4/06, Anthony Liguori [EMAIL PROTECTED] wrote:
Thomas Han wrote:
Hi,
For what it's worth. I have also seen this invisible wall problem
with my mouse for a few weeks off the CVS build too.
Can you try out the following patch. *grumbles about SDL's brokenness*
Regards,
Anthony Liguori
Since 0.8.1 came out yesterday, Instead of using CVS build, I'm now
running Qemu 0.8.1 + kqemu-1.3.0pre6. My host OS is FC5 and I'm
running XP inside it.
Thanks,
Thomas
On 5/4/06, *Christian MICHON* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
qemu 0.8.0 does not show this invisible barrier issue.
if this is worth anything, I use SDL 1.2.9.
If someone can reproduce the issue also on linux hosts,
there could be a lead.
On 5/4/06, Christian MICHON [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I removed manually vnc_display_init, and this is not the
culprit...
I'll check anyway versus qemu-0.8.0...
--
Christian
___
Qemu-devel mailing list
Qemu-devel@nongnu.org mailto:Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
diff -r 39a6dd1136c6 sdl.c
--- a/sdl.c Thu May 04 04:13:13 2006 +
+++ b/sdl.c Thu May 04 21:30:11 2006 -0500
@@ -280,13 +280,18 @@ static void sdl_update_caption(void)
static void sdl_hide_cursor(void)
{
-SDL_SetCursor(sdl_cursor_hidden);
+if (kbd_mouse_is_absolute()) {
+ SDL_ShowCursor(1);
+ SDL_SetCursor(sdl_cursor_hidden);
+} else {
+ SDL_ShowCursor(0);
+}
}
static void sdl_show_cursor(void)
{
if (!kbd_mouse_is_absolute()) {
- SDL_SetCursor(sdl_cursor_normal);
+ SDL_ShowCursor(1);
}
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
On my installation (v0.8.1 with WindowsXP host) the invisible wall can
be avoided or reproduced at will and I guess this indicates what´s wrong.
After leaving MouseGrab with Ctrl-Alt there will be an invisible wall if
I reenter by clicking with the host's mouse pointer far away from where
the quest-OS-pointer is. On the other hand if I reenter by carefully
clicking exactly at the guest-OS-pointer they will be in sync and
everything seems to be OK.
I haven´t been looking at the source-code, but my suggestion is that in
the Click-event-handler where Mousegrab is entered the guest-OS pointer
coordinates should be passed rather than the host's coordinates
(simulating a click at the exakt right position).
Regards
Dan Sandberg
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu - bug with -m 256
Brad Campbell wrote: Troy Benjegerdes wrote: On Thu, Feb 09, 2006 at 04:01:34PM -0600, Anthony Liguori wrote: Jim C. Brown wrote: -kernel-kqemu virtualizes ring 0 code. So it basically makes qemu do what VMware does. IIRC someone reported a 33% speedup with the new option. That was me. That was a 33% speedup on win2k startup time. kqemu (user only) has a negligible impact on win2k startup time which suggests this is mostly ring 0 code running which would make it a good benchmark for kernel-kqemu performance. This was a terribly unscientific benchmarking so don't read too much into it. Regards, Anthony Liguori My win2k guest (with SP4, but not any updates) seemed to hang on startup with -kernel-kqemu. Are you using -m 256 by any chance? I get this result with around that much ram allocated to the guest. -m 160 (or less) or -m 384 (or more) works perfectly here.. Great tip -thank you! I have been having the same headache as others: Linux and RectOS guests constantly crashing in the very same spot when -kernel-kqemu is enabled. I just made a quick test adding -m 384 and ReactOS suddenly boots all the way with -kernel-kqemu enabled! My test line was: qemu.exe -kernel-kqemu -m 384 -L ./bios -boot c -hda c.img Best regards, Dan Sandberg ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu - bug with -m 256 -please disregard
Dan Sandberg wrote: Brad Campbell wrote: Troy Benjegerdes wrote: On Thu, Feb 09, 2006 at 04:01:34PM -0600, Anthony Liguori wrote: Jim C. Brown wrote: -kernel-kqemu virtualizes ring 0 code. So it basically makes qemu do what VMware does. IIRC someone reported a 33% speedup with the new option. That was me. That was a 33% speedup on win2k startup time. kqemu (user only) has a negligible impact on win2k startup time which suggests this is mostly ring 0 code running which would make it a good benchmark for kernel-kqemu performance. This was a terribly unscientific benchmarking so don't read too much into it. Regards, Anthony Liguori My win2k guest (with SP4, but not any updates) seemed to hang on startup with -kernel-kqemu. Are you using -m 256 by any chance? I get this result with around that much ram allocated to the guest. -m 160 (or less) or -m 384 (or more) works perfectly here.. Great tip -thank you! I have been having the same headache as others: Linux and RectOS guests constantly crashing in the very same spot when -kernel-kqemu is enabled. I just made a quick test adding -m 384 and ReactOS suddenly boots all the way with -kernel-kqemu enabled! My test line was: qemu.exe -kernel-kqemu -m 384 -L ./bios -boot c -hda c.img Best regards, Dan Sandberg Sorry! Monday morning, coffee machine broken and my test far TOO quick since I forgot to start the kqemu service first and used a double-click script with the result that I missed the warning message that kqemu actually wasn´t running. With -kernel-kqemu enabled I now get the same nasty bug as before regardless of -m 160, 256, 384 or 512.. Best regards, Dan Sandberg ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
