[Mesa-dev] [PATCH 5/7] intel: Remove silly check for !bufmgr.

[Kenneth Graunke]

On 09/26/2013 08:36 PM, Eric Anholt wrote:
> If bufmgr didn't get created, then screen creation failed, and we never
> should have got here in the first place.  This was added by Chris Wilson
> in 2010 with no explanation for why it would be needed.
> ---
>  src/mesa/drivers/dri/i915/intel_context.c | 6 ------
>  src/mesa/drivers/dri/i965/intel_context.c | 6 ------
>  2 files changed, 12 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i915/intel_context.c b/src/mesa/drivers/dri/i915/intel_context.c
> index aff51e8..d25358b 100644
> --- a/src/mesa/drivers/dri/i915/intel_context.c
> +++ b/src/mesa/drivers/dri/i915/intel_context.c
> @@ -385,12 +385,6 @@ intelInitContext(struct intel_context *intel,
>     int bo_reuse_mode;
>     struct gl_config visual;
>  
> -   /* we can't do anything without a connection to the device */
> -   if (intelScreen->bufmgr == NULL) {
> -      *dri_ctx_error = __DRI_CTX_ERROR_NO_MEMORY;
> -      return false;
> -   }
> -
>     /* Can't rely on invalidate events, fall back to glViewport hack */
>     if (!driContextPriv->driScreenPriv->dri2.useInvalidate) {
>        intel->saved_viewport = functions->Viewport;
> diff --git a/src/mesa/drivers/dri/i965/intel_context.c b/src/mesa/drivers/dri/i965/intel_context.c
> index 7526b38..3eb5b8b 100644
> --- a/src/mesa/drivers/dri/i965/intel_context.c
> +++ b/src/mesa/drivers/dri/i965/intel_context.c
> @@ -412,12 +412,6 @@ intelInitContext(struct brw_context *brw,
>     int bo_reuse_mode;
>     struct gl_config visual;
>  
> -   /* we can't do anything without a connection to the device */
> -   if (intelScreen->bufmgr == NULL) {
> -      *dri_ctx_error = __DRI_CTX_ERROR_NO_MEMORY;
> -      return false;
> -   }
> -
>     /* Can't rely on invalidate events, fall back to glViewport hack */
>     if (!driContextPriv->driScreenPriv->dri2.useInvalidate) {
>        brw->saved_viewport = functions->Viewport;
> 

Huh, you're right, this doesn't look useful at all.  I verified that the
screen code does indeed prevent the driver from loading (so this is
indeed redundant).  Also, we need bufmgr to get the device ID, which is
well before we get here.

I could've sworn this was useful, but I bet I observed the driver
failing to load due to !bufmgr, then saw this code, and assumed it was
responsible for making that happen.  But it isn't.

Reviewed-and-tested-by: Kenneth Graunke <kenneth at whitecape.org>