[Intel-gfx] [PATCH 1/2] intel: Add support for overriding the PCI ID via an environment variable

Daniel Vetter daniel at ffwll.ch
Wed Feb 22 09:05:17 CET 2012


On Tue, Feb 21, 2012 at 02:42:37PM -0800, Kenneth Graunke wrote:
> On 02/21/2012 01:11 PM, Chris Wilson wrote:
> >On Tue, 21 Feb 2012 12:59:37 -0800, Kenneth Graunke<kenneth at whitecape.org>  wrote:
> >>@@ -1828,6 +1829,9 @@ drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used,
> >>  	execbuf.rsvd1 = 0;
> >>  	execbuf.rsvd2 = 0;
> >>
> >>+	if (getenv("INTEL_DEVID_OVERRIDE"))
> >>+		goto skip_execution;
> >
> >I'm not thrilled about calling getenv() for every execbuffer.
> 
> Good point.  I'll have to fix that.
> 
> >And what about the original execbuffer path?
> >-Chris
> 
> Does anybody care?  I'm not even sure how I'd test it.
> 
> A little bit of background: this is a stepping stone on the way to
> simulator support.
> 
> When INTEL_DEVID_OVERRIDE is set, Mesa will generate code/batches
> for that system, rather than the current machine.  It also
> implicitly sets INTEL_NO_HW=1, which makes it avoid calling
> execbuf2.  This at least allows INTEL_DEBUG=vs,wm,bat style dumps,
> which is handy.
> 
> However, our .aub trace file support is in libdrm, so I need Mesa to
> execbuf, or I don't get aub file dumps.  But I don't want libdrm to
> -actually- exec it.

What about adding a function to libdrm to stop all execbuf calls from
actually calling the kernel ioctl? Something like
drm_intel_gem_bufmgr_enable_no_hw() ... Maybe combine it right away with
the aub-trace grabbing code.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48



More information about the Intel-gfx mailing list