From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYNHZ-000656-ER for qemu-devel@nongnu.org; Sun, 19 Jun 2011 15:03:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYNHX-0007bM-Sc for qemu-devel@nongnu.org; Sun, 19 Jun 2011 15:03:41 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:60637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYNHX-0007bF-Hl for qemu-devel@nongnu.org; Sun, 19 Jun 2011 15:03:39 -0400 Received: by qwj8 with SMTP id 8so414540qwj.4 for ; Sun, 19 Jun 2011 12:03:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <8D086BA8-5717-4D1A-AD73-ED6FF5478CD6@web.de> References: <67D16361-9E4A-489C-B671-B7D08A50123F@web.de> <1308182564-11748-1-git-send-email-andreas.faerber@web.de> <8D086BA8-5717-4D1A-AD73-ED6FF5478CD6@web.de> From: Blue Swirl Date: Sun, 19 Jun 2011 22:03:18 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC v2 23/23] 40p: Add an IBM 8514/A graphics card List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Andreas_F=C3=A4rber?= Cc: =?UTF-8?Q?Herv=C3=A9_Poussineau?= , "qemu-devel@nongnu.org Developers" , Roy Tam On Sun, Jun 19, 2011 at 9:40 PM, Andreas F=C3=A4rber wrote: > Am 19.06.2011 um 15:27 schrieb Blue Swirl: > >> On Sun, Jun 19, 2011 at 1:04 PM, Andreas F=C3=A4rber >> wrote: >>> >>> Am 18.06.2011 um 22:42 schrieb Blue Swirl: >>> >>>> On Thu, Jun 16, 2011 at 3:02 AM, Andreas F=C3=A4rber >>>> wrote: >>>>> >>>>> The IBM E15 is equivalent to an S3 Vision864. >>>>> >>>>> Lacking S3 SDAC (86C716) support, the DAC indizes are translated >>>>> to greyscale colors. This works sufficiently to observe firmware >>>>> boot progress. >>>>> >>>>> Cc: Herv=C3=A9 Poussineau >>>>> >>>>> Fixed off-by-one drawing issue. >>>>> Replaced hardcoded color for RECT. >>>>> Separate I/O debug output for readability. >>>>> Start cleaning up the naming s3 vs. ibm8514. >>>>> Prepare support for DAC_MASK, DAC_R_INDEX, DAC_W_INDEX, DAC_DATA regs= . >>>>> >>>>> Cc: Roy Tam >>>>> Signed-off-by: Andreas F=C3=A4rber >>>>> --- >>>>> =C2=A0Makefile.objs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 =C2=A01 + >>>>> =C2=A0default-configs/ppc-softmmu.mak | =C2=A0 =C2=A01 + >>>>> =C2=A0hw/pci_ids.h =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A03 + >>>>> =C2=A0hw/ppc_prep.c =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 =C2=A02 + >>>>> =C2=A0hw/vga-ibm8514.c =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0780 >>>>> +++++++++++++++++++++++++++++++++++++++ >>>>> =C2=A05 files changed, 787 insertions(+), 0 deletions(-) >>>>> =C2=A0create mode 100644 hw/vga-ibm8514.c >>> >>>>> diff --git a/hw/vga-ibm8514.c b/hw/vga-ibm8514.c >>>>> new file mode 100644 >>>>> index 0000000..a87afe1 >>>>> --- /dev/null >>>>> +++ b/hw/vga-ibm8514.c > >>>>> +static void my_update_display(void *opaque) >>>>> +{ >>>>> + =C2=A0 =C2=A0VGACommonState *s =3D opaque; >>>>> + =C2=A0 =C2=A0int w; >>>>> + =C2=A0 =C2=A0uint8_t *vram; >>>>> + =C2=A0 =C2=A0uint8_t *data_display, *dd; >>>>> + =C2=A0 =C2=A0int x, y; >>>>> + =C2=A0 =C2=A0unsigned int (*rgb_to_pixel)(unsigned int r, unsigned = int g, >>>>> unsigned int b); >>>>> + >>>>> + =C2=A0 =C2=A0if (ds_get_width(s->ds) !=3D 640 || ds_get_height(s->d= s) !=3D 480) { >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0qemu_console_resize(s->ds, 640, 480); >>>>> + =C2=A0 =C2=A0} >>>>> + >>>>> + =C2=A0 =C2=A0switch (ds_get_bits_per_pixel(s->ds)) { >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0case 8: >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgb_to_pixel =3D rgb_to_pi= xel8; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0w =3D 1; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0case 15: >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgb_to_pixel =3D rgb_to_pi= xel15; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0w =3D 2; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0case 16: >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgb_to_pixel =3D rgb_to_pi= xel16; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0w =3D 2; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0case 32: >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgb_to_pixel =3D rgb_to_pi= xel32; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0w =3D 4; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0default: >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BADF("unknown host depth %= d\n", >>>>> ds_get_bits_per_pixel(s->ds)); >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return; >>>>> + =C2=A0 =C2=A0} >>>>> + >>>>> + =C2=A0 =C2=A0vram =3D s->vram_ptr; >>>>> + =C2=A0 =C2=A0/* XXX: out of range in vram? */ >>>>> + =C2=A0 =C2=A0data_display =3D dd =3D ds_get_data(s->ds); >>>>> + =C2=A0 =C2=A0for (y =3D 0; y < 480; y++) { >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0for (x =3D 0; x < 640; x++) { >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned int color; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0color =3D (*rgb_to_pixel)(= vram[0], vram[1], vram[2]); >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0memcpy(dd, &color, w); >>>> >>>> Please take a look at tcx.c for a 8 bit mode frame buffer with palette >>>> translation. Also VGA_DIRTY bit handling should be added to this loop >>>> to speed it up. >>> >>> Will look into it. >>> >>> I doubt this is causing the long delays though. >> >> The difference is that only areas which have been written after last >> update are copied to display instead of updating the whole screen >> every time. IIRC for TCX it was a major speedup. > > Some remarks: > > * TCX seems to assume that TARGET_HOST_PAGE =3D=3D 4 * 1024 in the unroll= ed loop > in tcx_update_display(). You might want to assert that. TCX was only used on Sparc32. Though some Ultra machines had SBus, there the page size would be 8k (also bigger pages, but that is what QEMU uses for TARGET_PAGE_SIZE). > * The check page < page_min with page_min =3D=3D -1 seems unintended in > tcx_update_display() and would have undesired effects on resetting the di= rty > bit. I used page_min < 0 instead. No, the check is correct since the type of page_min is ram_addr_t (unsigned long). > * The reset code seems wrong wrt dirty bit: after zero-ing VRAM the dirty > bit should be set, not reset. Otherwise the screen is not redrawn. Actually reset should not touch VRAM, the screen is cleared by OpenBIOS.