Hi Mark, On Sun, Nov 03, 2019 at 08:56:43PM +0000, Mark Cave-Ayland wrote: > On 01/11/2019 21:59, Sven Schnelle wrote: > > > On Sat, Oct 26, 2019 at 07:54:40PM +0200, Sven Schnelle wrote: > >> Hi Mark, > >> > >> On Sat, Oct 26, 2019 at 10:35:20AM +0100, Mark Cave-Ayland wrote: > >> > >>>> However, the VRAM in Artist is not really exposed to the Host. Instead, > >>>> there's the Chipset inbetween that can do byte swapping (Colormap is LE, > >>>> VRAM is BE) and Bit-to-Byte/Word/Dword conversion. For example you could > >>>> write 0x55 into that VRAM region, and the chipset would expand that to > >>>> VRAM Bytes: 00 01 00 01 00 01 00 01. And to make it even worse emulation > >>>> wise it can also do different encodings for Read or Write accesses, and > >>>> mask out certain bits of the data. So after trying to convert it to the > >>>> "dirty bitmap" API i decided to just leave it as it is. The CPU load > >>>> used by the display update code is usually < 1%, so it's ok for me. > >>> > >>> Wow that sounds that some interesting hardware(!). Does it make sense to > >>> model the > >>> behaviour of the chipset separately using a proxy MemoryRegion similar to > >>> virtio i.e. > >>> introduce an intermediate IO MemoryRegion that does the swapping and then > >>> forward it > >>> onto the VRAM MemoryRegion? > >> > >> Thanks for the pointer, i'll check whether that would work. For now i > >> think i'll remove the Artist patch from the series, so we can apply the > >> other patches, and i'll re-submit Artist when it's done. I guess the > >> rewrite to use a MemRegion is a bit bigger. But i would to get the other > >> patches in especially the LASI Stuff as both Helge and i have a lot of > >> stuff depending on that. > > > > I've looked into it again and changed my mind. There are at least the > > following > > functions that the Artist chip does before a Read/Write is passed to/from > > VRAM: > > > > - endianess conversion (actually configurable via some register, but i don't > > know how and hardwired it depending on CMAP / FB access) > > > > - The Address passed on the System bus are the X/Y coordinates added to the > > FB > > base address in the selected buffer instead of the VRAM offset for pixel > > data. > > I think that's configurable via the some registers, but i don't know how. > > Unfortunately there's absolutely no documentation about Artist available > > and > > everything was developed by reverse engineering. > > > > - bitmap to Byte/Word conversion (not implemented yet for the VRAM window, > > only > > for the I/O register window) > > > > So in my opinion it's way to much effort to squeeze all of that into the > > memory > > space, and it is not really a Memory range that's just behind a bus bridge. > > Hi Sven, > > Certainly in some cases it isn't possible to model devices in QEMU exactly as > real > hardware, although I think that some of the ideas above could be used to > improve the > implementation without too much extra effort. > > Then again from my work on QEMU I completely understand that sometimes this > can be > difficult with older, more esoteric devices. Ultimately after review that > decision > has to come from the maintainer(s) for the relevant devices/machines, so I > guess that > would be Richard and/or Gerd in this case?
I think that would be Richard. I rewrote the code to at least use the generic framebuffer functions now, and added dirty memory tracking. I'm still not happy with all the endianess conversion that are going on, but without any Documentation about chip it's impossible to say how the chip really works. Regards Sven
