From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: Design of a GPU profiling debug interface Date: Tue, 09 Nov 2010 14:27:43 -0800 Message-ID: <87mxpim8tc.fsf@pollan.anholt.net> References: <1288443851.21112.30.camel@pcjc2lap> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1000710233==" Return-path: In-Reply-To: <1288443851.21112.30.camel@pcjc2lap> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Peter Clifton , "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org --===============1000710233== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable On Sat, 30 Oct 2010 14:04:11 +0100, Peter Clifton wrote: > I think I'll need some help with this. I'm by no means a kernel > programmer, so I'm feeling my way in the dark with this. >=20 > I want to design an interface so I can synchronise my GPU idle flags > polling with batchbuffer execution. I'm imagining at a high level, doing > something like this in my application (or mesa). (Hand-wavey-pseudocode) Here's a thought. It ties in a little with something Arjan was asking for. Have trace events around batchbuffer submit that report the timestamp before and after -- you can do this on G45+ at least using PIPE_CONTROL writes to a temporary BO that the kernel makes for the job. The idle-bit tracing daemon would ask for those events, then run (CPU-side) doing the capture of INSTDONEs and the TIMESTAMP register, and also collecting the perf events. It could throw out reg captures that aren't within start/end of batchbuffers once perf events beyond those points arrive so you don't spew irrelevant data to disk. I think we've got pids of requester in the trace events, so you could correlate the records with which app did the rendering. The tricky part would be that the kernel needs to collect the PIPE_CONTROL-written timestamp values out "some time later" after the GPU is done with them and generate the events at that point -- so if you enabled lots of tracking, you'd see a tracing stream that looks something like: i915_gem_request_submit i915_gem_request_retire i915_gem_request_started # the new gpu-side timestamp event i915_gem_request_finished # the new gpu-side timestamp event --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzZyt8ACgkQHUdvYGzw6vdvsACfQ+7BGa8ykAKUx33HriXjqbLu SWoAn2C6IuxcXbpcSiCSk1Qci0CXxj+H =yDKU -----END PGP SIGNATURE----- --=-=-=-- --===============1000710233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1000710233==--