On Tue, Mar 20, 2012 at 10:36:24AM -0700, Eric Anholt wrote:
> On Mon, 19 Mar 2012 09:38:03 +0800, Yuanhan Liu <yuanhan....@linux.intel.com>
> wrote:
> > On Fri, Mar 16, 2012 at 04:26:43PM -0700, Eric Anholt wrote:
> > > ---
> > > src/mesa/drivers/dri/intel/intel_screen.c | 23 ++++-------------------
> > > 1 files changed, 4 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> > > b/src/mesa/drivers/dri/intel/intel_screen.c
> > > index 7939c4d..3f1ef87 100644
> > > --- a/src/mesa/drivers/dri/intel/intel_screen.c
> > > +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> > > @@ -624,8 +624,7 @@ intel_init_bufmgr(struct intel_screen *intelScreen)
> > > __DRIscreen *spriv = intelScreen->driScrnPriv;
> > > int num_fences = 0;
> > >
> > > - intelScreen->no_hw = (getenv("INTEL_NO_HW") != NULL ||
> > > - getenv("INTEL_DEVID_OVERRIDE") != NULL);
> > > + intelScreen->no_hw = getenv("INTEL_NO_HW") != NULL;
> >
> > Seems that we are doing duplicate things here in Mesa and Libdrm-intel:
> > mesa will bypass hardware rendering if INTEL_NO_HW env is set
> > libdrm-intel also will bypass hardware rendering if INTEL_DEVID_OVERRIDE
> > is set
> >
> > They are doing the same thing, but by different env variable, is that
> > necessary?
>
> INTEL_DEVID_OVERRIDE obviously implies INTEL_NO_HW, but INTEL_NO_HW is
> independently very useful for looking at debug output on your current
> hardware for a workload that hangs the GPU.
Got it. Thanks, then
Reviewed-by: Yuanhan Liu <yuanhan....@linux.intel.com>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
