[Intel-gfx] [PATCH] i830: use GTT maps for fallbacks & fence setup

Jesse Barnes jbarnes at virtuousgeek.org
Fri Mar 27 02:34:01 CET 2009


On Thu, 26 Mar 2009 18:21:57 -0700
Eric Anholt <eric at anholt.net> wrote:
> If something actually dereferences that pointer, it's not going to get
> the sort of results it's hoping for.  What happens if we set it to
> NULL, anyone know?  EXA/UXA should be cool with that, I think.

Yeah if it's NULL it should be ok...  So really we only have to worry
about noaccel and XAA here (arg too many damned configurations).
Neither of those will set kernel_exec_fencing right?  So they'll always
have fence regs set up and the memory mapped, so we can just use FbBase
+ fbOffset in those cases, will fix.

> >  #define ALWAYS_SYNC		0
> >  #define ALWAYS_FLUSH		0
> > @@ -837,8 +838,6 @@ i830_uxa_set_pixmap_bo (PixmapPtr pixmap,
> > dri_bo *bo) static Bool
> >  i830_uxa_prepare_access (PixmapPtr pixmap, uxa_access_t access)
> >  {
> > -    ScrnInfoPtr pScrn =
> > xf86Screens[pixmap->drawable.pScreen->myNum];
> > -    I830Ptr pI830 = I830PTR(pScrn);
> >      dri_bo *bo = i830_get_pixmap_bo (pixmap);
> >  
> >      if (bo) {
> > @@ -853,16 +852,22 @@ i830_uxa_prepare_access (PixmapPtr pixmap,
> > uxa_access_t access) i830->need_sync = FALSE;
> >  	}
> >  
> > -	if (pScrn->vtSema && !pI830->use_drm_mode &&
> > pI830->memory_manager) {
> > +	if (!scrn->vtSema)
> > +	    return TRUE;
> 
> Err, if !scrn->vtSema we'll now dereference NULL for software
> rendering, I think.

Oops I was trying to capture the pre-patch logic but failed, will fix.
Why do we check for vtSema here anyway?

> > UXA_ACCESS_RW);
> > -	    pixmap->devPrivate.ptr = pI830->FbBase + bo->offset;
> > -	} else {
> > -	    if (dri_bo_map(bo, access == UXA_ACCESS_RW) != 0)
> > -		return FALSE;
> > -	    pixmap->devPrivate.ptr = bo->virtual;
> >  	}
> > +	pixmap->devPrivate.ptr = bo->virtual;
> >      }
> >      return TRUE;
> >  }
> 
> non-GEM UXA will now completely fail, I think, since drm_intel_bo_pin
> won't work.  It was so slow it couldn't really be called working, so
> I'm not too worried (and if it were to be made decent, it would
> probably involve implementing bo_pin).

I tried testing non-GEM UXA and it failed, but somewhere else I think.
I'll try to fix anyway and re-post.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list