[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 00/10] R300 QEMU device V2
From: |
BALATON Zoltan |
Subject: |
Re: [RFC 00/10] R300 QEMU device V2 |
Date: |
Fri, 29 Nov 2019 19:03:05 +0100 (CET) |
User-agent: |
Alpine 2.21.99999 (BSF 352 2019-06-22) |
Hello,
On Thu, 28 Nov 2019, Aaron Zakhrov wrote:
I tested my code with the vgabios-ati.bin rom file and it seems to get
passed the earlier issue I had.
Good, so then the BIOS problem seems to be sorted for now. (Maybe it
needed the tables or EDID support that some drivers use from the VGA
BIOS.)
I have cleaned up my code and have sent a new patch series. The new one is
I still got pathces twice so rebase may not have worked completely and
changes are still not separate patches but hopefully there are less
unnecessary files in the last series. If you have problem with rebase and
using git to rework patches you could also start from a clean git tree
then apply patches with patch command and make new separate commits to
clean them up. This may be easier to do until you get familiar with git's
more obscure commands.
pretty big but it contains only the necessary header files and it should be
a little easier to review
I don't have time now to check all the added registers but is there a
reason you're targetting r300 instead of trying to make rv100 working
first? RV100 is a simpler chip with less features so you probably will
have less to implement and it's also clearer what might be needed than
having to implement a lot of new features the newer r300 may have. Once
rv100 works it may be easier to update that to r300 than going for that
right away, at least that's what I thought. If you think you can do all of
r300 features or you need that for some reason I'm fine with trying to
target r300 just saying that a more incremental approach may be easier to
do.
I haven't checked this but I think what you get now is that the driver is
trying to set up shared memory buffers via GART that it will use to send
command packets to the GPU that the emulated chip will need to parse and
convert to register access. This is the microengine/command
processor/CCE/PM4 I've referred to before. Unless we implement this in
some way it won't work as communication between the driver and card is
done using this facility so this should be the next step before adding
more registers and emulation. If you search for "ati microengine" it may
turn up some documentation on this where the buffers and command packets
are described but the actual microengine and it's microcode appears to be
undocumented. I've also said before that Xenia emulator has some code to
parse command packets of the XBox 360 GPU which is similar to some late
r5xx GPUs so some of these might be useful for emulating previous Radeons
as well.
Regards,
BALATON Zoltan
- Re: [RFC 09/10] Clean up Radeon Header files, (continued)
- Re: [RFC 00/10] R300 QEMU device V2, Daniel P . Berrangé, 2019/11/26
- Re: [RFC 00/10] R300 QEMU device V2, Philippe Mathieu-Daudé, 2019/11/27
- Re: [RFC 00/10] R300 QEMU device V2, BALATON Zoltan, 2019/11/27
- Re: [RFC 00/10] R300 QEMU device V2, Gerd Hoffmann, 2019/11/27
- Re: [RFC 00/10] R300 QEMU device V2, Daniel P . Berrangé, 2019/11/27
- Re: [RFC 00/10] R300 QEMU device V2, Aaron Zakhrov, 2019/11/28
- Re: [RFC 00/10] R300 QEMU device V2,
BALATON Zoltan <=