From: "Zhigang Gong" <zhigang.gong@linux.intel.com>
To: 'Chris Wilson' <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] uxa/glamor: Fallback to new glamor pixmap if failed to create textured pixmap.
Date: Fri, 16 Dec 2011 19:31:20 +0800 [thread overview]
Message-ID: <00c601ccbbe6$3c8827d0$b5987770$@linux.intel.com> (raw)
In-Reply-To: <d08817$2ic3ti@azsmga001.ch.intel.com>
> -----Original Message-----
> From: Chris Wilson [mailto:chris@chris-wilson.co.uk]
> Sent: Friday, December 16, 2011 5:21 PM
> To: zhigang.gong@linux.intel.com
> Cc: intel-gfx@lists.freedesktop.org; zhigang.gong@gmail.com; Zhigang
> Gong
> Subject: Re: [PATCH] uxa/glamor: Fallback to new glamor pixmap if failed
> to create textured pixmap.
>
> On Fri, 16 Dec 2011 15:39:55 +0800, zhigang.gong@linux.intel.com
> wrote:
> > +fallback_glamor:
> > + /* Create textured pixmap failed means glamor failed to
> > + * create a texture from current BO for some reasons. We turn
> > + * to create a new glamor pixmap and clean up current one.
> > + * One thing need to be noted, this new pixmap doesn't
> > + * has a priv and bo attached to it. It's glamor's responsbility
> > + * to take care it.
> > + */
> This then fails intel_uxa_is_offscreen() and we can no longer fallback to
> swrast correctly as uxa_prepare_access() becomes a no-op.
Right. IMO, this is not a big problem here, as in glamor this type
of pixmap will be marked as texture only pixmap and will never
fallback to DDX layer for any rendering operation.
>
> > + if (usage & INTEL_CREATE_PIXMAP_DRI2) {
> > + xf86DrvMsg(scrn->scrnIndex, X_WARNING,
> > + "Failed to create textured DRI2 pixmap.");
> > + return pixmap;
> At which point we really do need a better means for integrating glamor
> and UXA ops...
Actually, I haven't thought out a good idea for this case , say how to
handle such a BO
only pixmap in glamor. For almost all the other scenarios, we can easily
avoid
BO only pixmap by using a texture only pixmap or an in-memory pixmap. This
case is an exception.
And if I mesa/gbm can support all DRI format, then this case will also be
eliminated, as
It should never fail at glamor side. And if it failed we can just abort, as
that may indicates
a serious low level problem.
If we have to live with a BO only pixmap in glamor environment, one possible
fallback
method is to create another compatible BO for the same DRI2 pixmap. Then at
prepare
access glamor, we can copy the real BO's content to the compatible BO, and
at
finish access glamor, we can copy back the compatible BO's content to the
real DRI2
buffer's BO.
Does this way work?
But I really want the mesa/gbm to support all DRI2 formats and then....
>
> > + }
> > + new_pixmap = intel_glamor_create_pixmap(screen, w, h,
> > + depth, usage);
> > dri_bo_unreference(priv->bo);
> > fallback_priv:
> > free(priv);
> > fallback_pixmap:
> > fbDestroyPixmap(pixmap);
> > - return fbCreatePixmap(screen, w, h, depth, usage);
> > + if (new_pixmap)
> > + return new_pixmap;
> > + else
> > + return fbCreatePixmap(screen, w, h, depth, usage);
> > }
>
> Otherwise, it does look to be a step in the right direction.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2011-12-16 11:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-16 7:39 [PATCH] uxa/glamor: Fallback to new glamor pixmap if failed to create textured pixmap zhigang.gong
2011-12-16 9:21 ` Chris Wilson
2011-12-16 11:31 ` Zhigang Gong [this message]
2011-12-16 11:53 ` Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00c601ccbbe6$3c8827d0$b5987770$@linux.intel.com' \
--to=zhigang.gong@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.