Re: [Qemu-devel] [PATCH] OSX x86_64 host support
Am 09.12.2007 um 17:52 schrieb Mike Kronenberg: On the other hand, the QT implementation is and remains the fastest solution, as no of the other allows directly accessing the video- buffer, which results in way more copying. Likely, QT doesn't come with it's own set of video drivers, but uses some core technology of OS X. It's obviously possible to get CoreGraphics to avoid single buffering, but it's hard to find documentation about this, since Apple obviously wants to avoid such hacks. Additionally, flushing the graphics buffer is limited to screen refresh rate, which makes performance comparisons difficult: http:// developer.apple.com/documentation/Performance/Conceptual/Drawing/ Articles/FlushingContent.html#//apple_ref/doc/uid/TP40001835 At last, there is sample code which shows how to get pixels onto the screen without using the CPU at all: http://developer.apple.com/ samplecode/TextureRange/index.html HTH, Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH] OSX x86_64 host support
Hi from Q, Yes we have a OpenGL, CG and in dev a Core Animation version for vga output. Quickdraw is depreciated since Tiger. But as QEMU has never added gcc4 to the tool-chain, there was never a official running version on any Intel machine :) Our OpenGL and CG implementation offer fullscreen and tablet support as-well. Fullscreen is very slow on the CG implementation, but was speeded up by Core-Animation. I'd going with the OpenGL implementation, if the true opengl implementation for QEMU was coming ;). Else the partial screen-redrawing of CG is faster than OpenGL. On the other hand, the QT implementation is and remains the fastest solution, as no of the other allows directly accessing the video- buffer, which results in way more copying. If there is need for back-porting any of this stuff, that would be no problem. For the new Q front-end, we are going with a CG approach only, but we bypass cocoa.m altogether and mmap (shmem allows only 4mb on OS X) everything to the viewer app. Mike On 07.12.2007, at 21:19, Andreas Färber wrote: Am 07.12.2007 um 21:12 schrieb Alexander Graf: On Dec 7, 2007, at 6:43 PM, Pierre d'Herbemont wrote: On Dec 7, 2007, at 1:42 PM, Alexander Graf wrote: Right now there is no graphical output available except for VNC, as the cocoa output depends on deprecated APIs that are no longer available in 64-bit mode and SDL does not compile on x86_64 Darwin yet. This is the QuickDraw API? If so, it should be quite straight forward to use OpenGL or CoreGraphics instead... What about not disabling Cocoa, and simply print a nice #error or #warning that explains that the quickdraw part needs fixing? Pierre. Yes, it's the QuickDraw API. I'm currently looking into this, so if you know anything about the transition to CoreGraphics, please let me know or point me to some documentation on that. I'd rather have a proper patch for the cocoa output than anything else. Disabling it is only a temporary workaround to have it build at all. Doesn't Q offer all three? I'm pretty sure I've been using its OpenGL option with success. Andreas Cheers, Alex smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] [PATCH] OSX x86_64 host support
Hi, On Dec 9, 2007, at 5:52 PM, Mike Kronenberg wrote: Hi from Q, Yes we have a OpenGL, CG and in dev a Core Animation version for vga output. Quickdraw is depreciated since Tiger. But as QEMU has never added gcc4 to the tool-chain, there was never a official running version on any Intel machine :) There still isn't. Sadly there have been no comments on my x86_64 darwin patch, but that one seems to be the least intrusive and fastest intel mac qemu patch I've seen so far. Our OpenGL and CG implementation offer fullscreen and tablet support as-well. Fullscreen is very slow on the CG implementation, but was speeded up by Core-Animation. I'd going with the OpenGL implementation, if the true opengl implementation for QEMU was coming ;). Else the partial screen-redrawing of CG is faster than OpenGL. My CG implementation is a mere hack. There is no partion screen- redraw, as I push the full CGImage contents to the context on every repaint. So any of these sound way better. On the other hand, the QT implementation is and remains the fastest solution, as no of the other allows directly accessing the video- buffer, which results in way more copying. I thought CG allows for storing images on the video card's buffer as well? At least that's what I've read somewhere in the Apple documentation. If there is need for back-porting any of this stuff, that would be no problem. Everything is better than what there is right now. Currently qemu is ppc 32-bit only with (maybe) 10.5 being the last supported version, as I personally believe that Apple will remove QuickDraw in 10.6. So I'm fine with whatever you feel like worth backporting. I'm not in a position to decide on what to do, don't know who is either though. So if anyone with commit rights feels interested in Mac OS X Host support, I'd love to hear some words on this. For the new Q front-end, we are going with a CG approach only, but we bypass cocoa.m altogether and mmap (shmem allows only 4mb on OS X) everything to the viewer app. Mike Cheers, Alex
Re: [Qemu-devel] [PATCH] OSX x86_64 host support
On Dec 7, 2007, at 6:43 PM, Pierre d'Herbemont wrote: On Dec 7, 2007, at 1:42 PM, Alexander Graf wrote: Right now there is no graphical output available except for VNC, as the cocoa output depends on deprecated APIs that are no longer available in 64-bit mode and SDL does not compile on x86_64 Darwin yet. This is the QuickDraw API? If so, it should be quite straight forward to use OpenGL or CoreGraphics instead... What about not disabling Cocoa, and simply print a nice #error or #warning that explains that the quickdraw part needs fixing? Pierre. Yes, it's the QuickDraw API. I'm currently looking into this, so if you know anything about the transition to CoreGraphics, please let me know or point me to some documentation on that. I'd rather have a proper patch for the cocoa output than anything else. Disabling it is only a temporary workaround to have it build at all. Cheers, Alex
Re: [Qemu-devel] [PATCH] OSX x86_64 host support
On Dec 7, 2007, at 1:42 PM, Alexander Graf wrote: Right now there is no graphical output available except for VNC, as the cocoa output depends on deprecated APIs that are no longer available in 64-bit mode and SDL does not compile on x86_64 Darwin yet. This is the QuickDraw API? If so, it should be quite straight forward to use OpenGL or CoreGraphics instead... What about not disabling Cocoa, and simply print a nice #error or #warning that explains that the quickdraw part needs fixing? Pierre.
Re: [Qemu-devel] [PATCH] OSX x86_64 host support
Am 07.12.2007 um 21:12 schrieb Alexander Graf: On Dec 7, 2007, at 6:43 PM, Pierre d'Herbemont wrote: On Dec 7, 2007, at 1:42 PM, Alexander Graf wrote: Right now there is no graphical output available except for VNC, as the cocoa output depends on deprecated APIs that are no longer available in 64-bit mode and SDL does not compile on x86_64 Darwin yet. This is the QuickDraw API? If so, it should be quite straight forward to use OpenGL or CoreGraphics instead... What about not disabling Cocoa, and simply print a nice #error or #warning that explains that the quickdraw part needs fixing? Pierre. Yes, it's the QuickDraw API. I'm currently looking into this, so if you know anything about the transition to CoreGraphics, please let me know or point me to some documentation on that. I'd rather have a proper patch for the cocoa output than anything else. Disabling it is only a temporary workaround to have it build at all. Doesn't Q offer all three? I'm pretty sure I've been using its OpenGL option with success. Andreas Cheers, Alex
Re: [Qemu-devel] [PATCH] OSX x86_64 host support
Am 07.12.2007 um 18:43 schrieb Pierre d'Herbemont: This is the QuickDraw API? If so, it should be quite straight forward to use OpenGL or CoreGraphics instead... There is prior art (to get isnpired) in BasiliskII. From it's file src/MacOSX/video_macosx.h: // Using Core Graphics is fastest when rendering 32bit data. // Using CGImageRefs allows us to use all the bitmaps that BasiliskII supports. // When both Basilisk II and OS X are set to 'Thousands', updating a 312x342 // window happens at over 500fps under 10.2, and over 600fps on 10.3! Basilisk's sources are here: http://gwenole.beauchesne.info/projects/basilisk2/files/ BasiliskII_src_01052006.tar.bz2 Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
