[Intel-gfx] [PATCH 1/2] intel: Add support for overriding the PCI ID via an environment variable
daniel at ffwll.ch
Wed Feb 22 00:05:17 PST 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?
> 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.
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
More information about the Intel-gfx