qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: BALATON Zoltan <balaton@eik.bme.hu>
To: Aaron Zakhrov <aaron.zakhrov@gmail.com>
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [RFC 00/10] R300 QEMU device V2
Date: Fri, 29 Nov 2019 19:03:05 +0100 (CET)	[thread overview]
Message-ID: <alpine.BSF.2.21.99999.352.1911291837080.15049@zero.eik.bme.hu> (raw)
In-Reply-To: <CAApBzg9c9rwgAd1forny9QGgz8-fA60QBcRQbsMSmTwB_h12pQ@mail.gmail.com>

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


  reply	other threads:[~2019-11-29 18:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26 12:44 [RFC 00/10] R300 QEMU device V2 aaron.zakhrov
2019-11-26 12:44 ` [RFC 05/10] Add Radeon kernel headers. Will clean up later aaron.zakhrov
2019-11-26 12:44 ` [RFC 06/10] Fix MC STATUS resgister aaron.zakhrov
2019-11-26 12:44 ` [RFC 07/10] R300 fixes aaron.zakhrov
2019-11-26 12:44 ` [RFC 08/10] Got GPU init working. Stops at probing display aaron.zakhrov
2019-11-26 12:44 ` [RFC 09/10] Clean up Radeon Header files aaron.zakhrov
2019-11-27  9:55   ` Aleksandar Markovic
2019-11-27 14:42     ` BALATON Zoltan
2019-11-26 14:19 ` [RFC 00/10] R300 QEMU device V2 Daniel P. Berrangé
2019-11-27 15:00   ` Philippe Mathieu-Daudé
2019-11-27 15:05     ` Daniel P. Berrangé
2019-11-27 15:13       ` Philippe Mathieu-Daudé
2019-11-27 15:54         ` Daniel P. Berrangé
2019-11-27 16:12       ` Gerd Hoffmann
2019-11-27 16:32         ` Daniel P. Berrangé
2019-11-28  6:51           ` Aaron Zakhrov
2019-11-29 18:03             ` BALATON Zoltan [this message]
2019-11-27 16:17       ` BALATON Zoltan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.BSF.2.21.99999.352.1911291837080.15049@zero.eik.bme.hu \
    --to=balaton@eik.bme.hu \
    --cc=aaron.zakhrov@gmail.com \
    --cc=berrange@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).