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.
pgpRTD15GxNKq.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
