Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Dan Sandberg]

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

[Dan Sandberg]

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

[Jamie Lokier]

Dan Sandberg wrote:
 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.

Thanks; I didn't know OpenGL had that function as well as 3d rendering.

That's what the Xv extension does (X video) - it's to provide an
overlay to be used by video players.  Xv scales the source image and
mixes it with the primary framebuffer in the way you describe.
However, Xv is intended for non-RGB colourspace source formats, so may
not be suitable for Qemu.  I don't know if Xv sometimes can support RGB.

Since Xv is supported by many video cards, even old ones without 3d,
or without working 3d drivers, I'm surprised that particular OpenGL
function isn't commonly implemented with equal performance.

-- Jamie


___
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]

 Anyway, many people think of OpenGL as just 3D, but it is extremely
 competent for 2D (given a good driver).

That's where your argument falls down.
I wouldn't be surprised if even a crappy OpenGL implementation could beat 
plain GDI. However I'd guess most OpenGL drivers are optimised for common 3D 
operations. OpenGL provides a very wide range of functionality, however if 
you go outside the commonly used (and hence optimized) feature set 
performance is likely to be fairly poor when compared if optimized routines.

 standard Windows GDI and 145 ms for the OpenGL 2D-canvas (and its just a
 standard business computer with no fancy graphic card at all).

If GDI was writing directly to video memory and OpenGL was writing to a buffer 
in system memory that would explain the large difference.


I'm not saying OpenGL is necessarily a bad thing, but it's certainly not (yet) 
what I'd consider good solution. Especially considering that 90% of modern 
graphics cards don't have any open source OpenGL capable drivers.

Paul


___
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

[Dan Sandberg]

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] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Jan Marten Simons]

Am Donnerstag, 11. Mai 2006 15:04 schrieb Dan Sandberg:
 Are you using an OpenGL directdraw surface for the graphics emulation in
 Qemu?

Qemu is using SDL, as this is a very portable library/framework. I'm not sure, 
if SDL uses DirectX on Win32, but I'd rather think it does not. Of course one 
might want to check this and maybe have a look at the SDL mail lists, if 
DirectX was discussed there.

 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.

There already are a few projects for external qemu GUIs, but for an internal 
GUI it would have to be done in SDL, too, as to not introduce further 
dependencies. Please keep in mind that qemu is ported to many platforms and 
therefor the code would have to be very portable anyways.
If you're keen on doing a GUI in Lazarus, feel free to do so, but have a look 
at the ml archive and some existing GUIs first.

With regards,
Jan Simons


___
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

[Oliver Gerlich]

Dan Sandberg wrote:

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

 



Hi,
some comments on your suggestions:


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


Not sure how much faster it is on Windows; currently Qemu uses plain SDL 
for drawing which probably uses DirectDraw under Windows. However, AFAIK 
under Linux SDL is not hardware accelerated in most cases, while OpenGL 
could give hardware acceleration.


2: It gives full control over things like window or fullscreen mode in 
any (almost) resolution and color depth.


AFAIK the windowing/fullscreen stuff is not done by OpenGL itself, but 
by some external library; SDL offers this functionality, GLUT is another 
possibility, and apparently the GlScene lib you mentioned does this as well.



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.


Basically, that sounds like a good idea to me.



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


Before you start working on this, I have some suggestions as well:

Is the drawing part really a performance bottleneck? And will this 
really be improved by changing the drawing functions, or wouldn't a 
better graphics card emulation give much more improvements? What does a 
profiler say about this?
I seem to recall that in most cases, SDL doesn't slow down performance 
in Qemu. It might be interesting to see how much the new RGB-BGR 
conversions costs, though.


Another thing that I think is important is that not all computers have 
OpenGL acceleration. And at least on Linux, software OpenGL rendering is 
quite slow, so a port to OpenGL would probably be a huge drawback for 
some people. If OpenGL is really worth the trouble, one could add OpenGL 
rendering so that people can still use the old way of drawing if no 
hardware acceleration is available.


A GUI frontend would be quite nice, I think. So far several people have 
submitted (quite useful) patches for this, but nothing more has happened 
in that direction. Not sure what is required for a GUI that will be 
integrated into Qemu finally...



Thanks,
Oliver


___
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

[Jim C. Brown]

On Thu, May 11, 2006 at 04:57:23PM +0200, Jan Marten Simons wrote:
 Am Donnerstag, 11. Mai 2006 15:04 schrieb Dan Sandberg:
  Are you using an OpenGL directdraw surface for the graphics emulation in
  Qemu?
 
 Qemu is using SDL, as this is a very portable library/framework. I'm not 
 sure, 
 if SDL uses DirectX on Win32, but I'd rather think it does not. Of course one 
 might want to check this and maybe have a look at the SDL mail lists, if 
 DirectX was discussed there.

He is askinng about OpenGL, not DirectX.

Dunno if it is the default, but iirc SDL supports OpenGL on Windows.

 
  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.

SDL has support for OpenGL builtin, so qemu should be able to use that
with only a few modifications.

 
 There already are a few projects for external qemu GUIs, but for an internal 
 GUI it would have to be done in SDL, too, as to not introduce further 
 dependencies.

No one has tried to make an SDL Gui for qemu. SDL guis tend to be ugly in
general.

There is a well supported GUI for OS X called Q, and there are 2 versions of
qemu that use a GTK GUI internally.

 Please keep in mind that qemu is ported to many platforms and 
 therefor the code would have to be very portable anyways.

Supporting something that runs (or can run) on top of X would catch most of
the platforms that qemu runs on, the only ones I can think of that would need
their own stuff would be Windows and OS X (well OS X has an X server but users
prefer a native GUI there).

 If you're keen on doing a GUI in Lazarus, feel free to do so, but have a look 
 at the ml archive and some existing GUIs first.
 
 With regards,
 Jan Simons
 
 
 ___
 Qemu-devel mailing list
 Qemu-devel@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/qemu-devel
 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


___
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

[Anthony Liguori]

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.


My own feeling is that a smarter thing to do is to pass the VGA ops to 
another program to actually do the rendering.  I think a GUI that used 
VNC to interact with QEmu would be a very good start.  localhost VNC 
performance seems good enough to me that this should be a reasonable 
approach.


Hardware scaling would, perhaps, be a useful feature of using OpenGL.  
Unfortunately, OpenGL is not available enough widely to make this 
practical in my mind.  I'd rather devote the same effort to fast 
software scaling (via SIMD instructions).


Regards,

Anthony Liguori

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




___
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]

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

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Paul Brook]

On Wednesday 10 May 2006 19:16, Ben Taylor wrote:
 Enclosed is a patch that fixes the color mapping when running qemu on a
 Solaris/Sparc system.  To enable the color mapping bgr, call qemu with the
 flag -bgr.

We've been over this several times before. qemu should be able to autodetect 
what color format to use. Also putting if inside the inner loop of the 
low-level conversion routines is a bad idea.

Paul


___
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

[Anthony Liguori]

Ben Taylor wrote:

Enclosed is a patch that fixes the color mapping when running qemu on a 
Solaris/Sparc
system.  To enable the color mapping bgr, call qemu with the flag -bgr.

This patch *requires* the qemu-0.8.1cvs-sparc-solaris.patch diff that was posted
earlier today.

I separated out this patch as there has been much discussion about fixing the 
bgr
problem, but I haven't seen any other code posted.  This has been tested with
Win98SE and DamnSmallLinux on an Ultra 80 running Solaris 10.

Note:  VNC and Sparc are still not playing nicely, so you will see inverted 
colors if
you run qemu on a Solaris Sparc host and display with vnc.
  


This is going to almost certainly going to have a negative performance 
consequence.  A better solution would be introduce a second set of 
functions that were byte swapped and set the rgb_to_pixel function 
pointer appropriately if bgr is enabled.


I would expect that you can automate the selecting of bgr too based on 
the host architecture and the target architecture.  There shouldn't be a 
need for a new command line option.


If you added a byte_order member to the DisplayState, this would fix the 
vnc case too.


Regards,

Anthony Liguori


Ben


diff -ruN qemu-solaris-sparc/hw/vga.c qemu/hw/vga.c
--- qemu-solaris-sparc/hw/vga.c 2006-04-08 21:06:34.0 -0400
+++ qemu/hw/vga.c   2006-05-10 12:31:31.059297000 -0400
@@ -790,23 +790,43 @@
 
 static inline unsigned int rgb_to_pixel8(unsigned int r, unsigned int g, unsigned b)

 {
+if (bgr_display_enabled) {
+return ((b  5)  5) | ((g  5)  2) | (r  6);
+}
+else {
 return ((r  5)  5) | ((g  5)  2) | (b  6);
 }
+}
 
 static inline unsigned int rgb_to_pixel15(unsigned int r, unsigned int g, unsigned b)

 {
+if (bgr_display_enabled) {
+return ((b  3)  10) | ((g  3)  5) | (r  3);
+}
+else {
 return ((r  3)  10) | ((g  3)  5) | (b  3);
 }
+}
 
 static inline unsigned int rgb_to_pixel16(unsigned int r, unsigned int g, unsigned b)

 {
+if (bgr_display_enabled) {
+return ((b  3)  11) | ((g  2)  5) | (r  3);
+}
+else {
 return ((r  3)  11) | ((g  2)  5) | (b  3);
 }
+}
 
 static inline unsigned int rgb_to_pixel32(unsigned int r, unsigned int g, unsigned b)

 {
+if (bgr_display_enabled) {
+return (b  16) | (g  8) | r;
+}
+else {
 return (r  16) | (g  8) | b;
 }
+}
 
 #define DEPTH 8

 #include vga_template.h
@@ -1366,6 +1386,8 @@
 
 if (disp_width != s-last_width ||

 height != s-last_height) {
+if (cirrus_vga_enabled  s-get_bpp(s) = 8)
+memset(s-vram_ptr, 0xff, s-vram_size);
 dpy_resize(s-ds, disp_width, height);
 s-last_scr_width = disp_width;
 s-last_scr_height = height;
diff -ruN qemu-solaris-sparc/vl.c qemu/vl.c
--- qemu-solaris-sparc/vl.c 2006-05-10 12:37:40.467126000 -0400
+++ qemu/vl.c   2006-05-10 12:31:46.354278000 -0400
@@ -130,6 +130,7 @@
 int vm_running;
 int rtc_utc = 1;
 int cirrus_vga_enabled = 1;
+int bgr_display_enabled = 0;
 #ifdef TARGET_SPARC
 int graphic_width = 1024;
 int graphic_height = 768;
@@ -4626,6 +4627,7 @@
-m megs set virtual RAM size to megs MB [default=%d]\n
-smp n  set the number of CPUs to 'n' [default=1]\n
-nographic  disable graphical output and redirect serial I/Os to 
console\n
+   -bgrinvert colors for HOSTS using certain SPARC frame 
buffers\n
 #ifndef _WIN32
   -k language use keyboard layout (for example \fr\ for 
French)\n
 #endif
@@ -4782,6 +4784,7 @@
 QEMU_OPTION_cirrusvga,
 QEMU_OPTION_g,
 QEMU_OPTION_std_vga,
+QEMU_OPTION_bgr,
 QEMU_OPTION_monitor,
 QEMU_OPTION_serial,
 QEMU_OPTION_parallel,
@@ -4861,6 +4864,7 @@
 { full-screen, 0, QEMU_OPTION_full_screen },
 { pidfile, HAS_ARG, QEMU_OPTION_pidfile },
 { win2k-hack, 0, QEMU_OPTION_win2k_hack },
+{ bgr, 0, QEMU_OPTION_bgr },
 { usbdevice, HAS_ARG, QEMU_OPTION_usbdevice },
 { smp, HAS_ARG, QEMU_OPTION_smp },
 { vnc, HAS_ARG, QEMU_OPTION_vnc },
@@ -5365,6 +5369,9 @@
 case QEMU_OPTION_std_vga:
 cirrus_vga_enabled = 0;
 break;
+case QEMU_OPTION_bgr:
+bgr_display_enabled = 1;
+break;
 case QEMU_OPTION_g:
 {
 const char *p;
diff -ruN qemu-solaris-sparc/vl.h qemu/vl.h
--- qemu-solaris-sparc/vl.h 2006-05-03 18:02:44.0 -0400
+++ qemu/vl.h   2006-05-10 12:31:51.368923000 -0400
@@ -135,6 +135,7 @@
 extern int bios_size;
 extern int rtc_utc;
 extern int cirrus_vga_enabled;
+extern int bgr_display_enabled;
 extern int graphic_width;
 extern int graphic_height;
 extern int graphic_depth;
  



___
Qemu-devel mailing list
Qemu-devel@nongnu.org

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Julian Seward]

 autodetect what color format to use. Also putting if inside the inner loop
 of the low-level conversion routines is a bad idea.

While that's per-se true, maybe it's not such a big deal.  The branch is
going to be perfectly predictable since the condition stays the same 
for the entire run, so I'd be surprised if you even lost one host cycle
per iteration overall.  Basically the hardware will fold it out.

J


___
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]

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.


Fabrice.


___
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

[Ben Taylor]

 Fabrice Bellard [EMAIL PROTECTED] 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 added an int bgr; to the displaystruct in vl.h, but that is now causing a 
core dump
upon starting qemu with the rest of your patch.

here's the back trace:

#0  0x00033204 in console_show_cursor (s=0x11f95bd8, show=301554760) at vl.h:692
#1  0x0003373c in console_puts (chr=0x36, buf=0x140c18 QEMU 0.8.1 monitor - 
type 'help' for more information\n, len=54)
at /export/src/qemu/May10-V2/qemu-solaris/console.c:825
#2  0x00024eb8 in qemu_chr_write (s=0x36, buf=0x140c18 QEMU 0.8.1 monitor - 
type 'help' for more information\n, len=54)
at /export/src/qemu/May10-V2/qemu-solaris/vl.c:1096
#3  0x0002d208 in term_flush () at 
/export/src/qemu/May10-V2/qemu-solaris/monitor.c:72
#4  0x0002d27c in term_puts (str=0xffbfb78e ) at 
/export/src/qemu/May10-V2/qemu-solaris/monitor.c:88
#5  0x0002d2d0 in term_vprintf (fmt=0xfcd68 QEMU %s monitor - type 'help' for 
more information\n, ap=0xffbfc820)
at /export/src/qemu/May10-V2/qemu-solaris/monitor.c:96
#6  0x0002d304 in term_printf (fmt=0xfcd68 QEMU %s monitor - type 'help' for 
more information\n)
at /export/src/qemu/May10-V2/qemu-solaris/monitor.c:103
#7  0x00030470 in monitor_init (hd=0x11f82f38, show_banner=1) at 
/export/src/qemu/May10-V2/qemu-solaris/monitor.c:2288
#8  0x00029804 in main (argc=7, argv=0xffbff33c) at 
/export/src/qemu/May10-V2/qemu-solaris/vl.c:5658


Ideas?

Ben


___
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]

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