From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Graunke Subject: Command parser breaks the 3D driver. Date: Tue, 25 Mar 2014 22:12:07 -0700 Message-ID: <533261A7.5090805@whitecape.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1198246595==" Return-path: Received: from homiemail-a6.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by gabe.freedesktop.org (Postfix) with ESMTP id 4F6FB6E4B9 for ; Tue, 25 Mar 2014 22:11:47 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 984D7598076 for ; Tue, 25 Mar 2014 22:11:46 -0700 (PDT) Received: from [10.0.0.232] (unknown [50.126.105.238]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kenneth@whitecape.org) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 7AF1F598074 for ; Tue, 25 Mar 2014 22:11:46 -0700 (PDT) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: "Intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============1198246595== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="THFWAeQhquTJ8grvU4fQpgTXgiA9vjrFU" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --THFWAeQhquTJ8grvU4fQpgTXgiA9vjrFU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, The version of the command parser which landed in drm-intel-nightly (and is now enabled by default) completely breaks the 3D driver. Running any program - glxgears, KDE, GNOME, whatever - results in: intel_do_flush_locked failed: Invalid argument and then Mesa aborts the program. When Mesa initializes, it tries to submit several small batches to see if it can write various registers. For example: MI_LOAD_REGISTER_IMM | (3 - 2) OACONTROL 0x31337000 (expected value) MI_STORE_REGISTER_MEM OACONTROL
MI_LOAD_REGISTER_IMM | (3 - 2) OACONTROL 0 MI_BATCH_BUFFER_END We then map the buffer to see what the value is. If it's our expected value, we know we can write that register, and enable features. If not, we disable the functionality and never write that register again. This works because the hardware validator implicitly converts privileged commands (like MI_LOAD_REGISTER_IMM) to MI_NOOP, but otherwise accepts and processes the batch. This is well-documented behavior, and we've been relying on it since May 2013. In contrast, the software validator returns -EINVAL and skips executing the batch. It rejects this particular batch since OACONTROL is not in the kernel's register whitelist. I'm not sure I'm quite comfortable with the software validator implementing different behavior than the hardware validator. Then again, it's probably better behavior... Also, I'm surprised to see that the software validator is always enabled on Haswell. The hardware validator actually works on Haswell, and the majority of our batches don't need to run privileged commands, so it seems like we're just burning CPU pointlessly. I thought the plan was to have userspace add an execbuf flag to explicitly request software scanning when it emits privileged commands, and (on Haswell) use the hardware scanner normally. --Ken --THFWAeQhquTJ8grvU4fQpgTXgiA9vjrFU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTMmGvAAoJEFtb2gcdScw4ufoP/2Uyx3xdbC1KbeS78TQag3jW CmXLd8LXGU+IgitPb5ymbFE9gFoXjEhxyUXSMKBFZ04B55GnAI9eQzePmPKk9dX6 GBz9ckRYtIZ26I/gzHD5qrvw86cnmwApvzNQvZNmMZNU5rOrBiPE637k7QWbsD24 t91y98qYwVGG1HsQM2JwqPhyXroo74ARUmZDASKyH7WzC25+cMQodjSKDBbEJtRP armHWPO0wDxm+JSZnkvD8dFayb0VbBBzbmuoqUjh2ct5WoaO5abWa5TLcWjBUYaj bQglnPvyvZiqs1Byffu66+/yj4WRgkwTKcdvWAtz+Gctf0e72L5ya7z9qq9HvuZY 14QuCAEg5dx43vxfCRF1C0hQnyDkRegNAqqYAgLj2vHuU1qJi6ruf2skdR8Y3nTE 8YrYQ2e7E8Ozn1FJ1Odc3zcL9ECm4e3EFYuL5NTwwUBhPWEIEomvRVSYFfNVVkPj UwpfxCRtlBUWOkSIfDxvarnoDB+OS0B7yLubZzqIQaVmu3pqlv1JygIGtfBGBP/7 LJ9dAUs78maJJso7PzwAUaOAgOrzY1yI2Xm8Ed/QHfp1wRjEfrOdDrJPzPou34xr m3kj3Cf7eijESezTFUD0bAqHI10u8c2TXBlGUsciUvCLZzdCfxgktwmadIrv077M 1Dtj5KJ5BA2r0CU3HK6j =pJ6U -----END PGP SIGNATURE----- --THFWAeQhquTJ8grvU4fQpgTXgiA9vjrFU-- --===============1198246595== 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 --===============1198246595==--