Re: [Freedreno] [PATCH v3 00/23] drm/msm: de-struct_mutex-ification

[Kristian Høgsberg]

On Mon, Oct 19, 2020 at 10:45 PM Rob Clark  wrote:
>
> From: Rob Clark 
>
> This doesn't remove *all* the struct_mutex, but it covers the worst
> of it, ie. shrinker/madvise/free/retire.  The submit path still uses
> struct_mutex, but it still needs *something* serialize a portion of
> the submit path, and lock_stat mostly just shows the lock contention
> there being with other submits.  And there are a few other bits of
> struct_mutex usage in less critical paths (debugfs, etc).  But this
> seems like a reasonable step in the right direction.
>
> v2: teach lockdep about shrinker locking patters (danvet) and
> convert to obj->resv locking (danvet)
> v3: fix get_vaddr locking for legacy userspace (relocs), devcoredump,
> and rd/hangrd

For the series:

Reviewed-by: Kristian H. Kristensen 

> Rob Clark (23):
>   drm/msm: Fix a couple incorrect usages of get_vaddr_active()
>   drm/msm/gem: Add obj->lock wrappers
>   drm/msm/gem: Rename internal get_iova_locked helper
>   drm/msm/gem: Move prototypes to msm_gem.h
>   drm/msm/gem: Add some _locked() helpers
>   drm/msm/gem: Move locking in shrinker path
>   drm/msm/submit: Move copy_from_user ahead of locking bos
>   drm/msm: Do rpm get sooner in the submit path
>   drm/msm/gem: Switch over to obj->resv for locking
>   drm/msm: Use correct drm_gem_object_put() in fail case
>   drm/msm: Drop chatty trace
>   drm/msm: Move update_fences()
>   drm/msm: Add priv->mm_lock to protect active/inactive lists
>   drm/msm: Document and rename preempt_lock
>   drm/msm: Protect ring->submits with it's own lock
>   drm/msm: Refcount submits
>   drm/msm: Remove obj->gpu
>   drm/msm: Drop struct_mutex from the retire path
>   drm/msm: Drop struct_mutex in free_object() path
>   drm/msm: Remove msm_gem_free_work
>   drm/msm: Drop struct_mutex in madvise path
>   drm/msm: Drop struct_mutex in shrinker path
>   drm/msm: Don't implicit-sync if only a single ring
>
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c |   6 +-
>  drivers/gpu/drm/msm/adreno/a5xx_preempt.c |  12 +-
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c |   6 +-
>  drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |   1 +
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |   1 +
>  drivers/gpu/drm/msm/dsi/dsi_host.c|   1 +
>  drivers/gpu/drm/msm/msm_debugfs.c |   7 +
>  drivers/gpu/drm/msm/msm_drv.c |  21 +-
>  drivers/gpu/drm/msm/msm_drv.h |  73 +-
>  drivers/gpu/drm/msm/msm_fbdev.c   |   1 +
>  drivers/gpu/drm/msm/msm_gem.c | 266 +++---
>  drivers/gpu/drm/msm/msm_gem.h | 133 +--
>  drivers/gpu/drm/msm/msm_gem_shrinker.c|  81 ++-
>  drivers/gpu/drm/msm/msm_gem_submit.c  | 158 -
>  drivers/gpu/drm/msm/msm_gpu.c | 110 +
>  drivers/gpu/drm/msm/msm_gpu.h |   5 +-
>  drivers/gpu/drm/msm/msm_rd.c  |   2 +-
>  drivers/gpu/drm/msm/msm_ringbuffer.c  |   3 +-
>  drivers/gpu/drm/msm/msm_ringbuffer.h  |  13 +-
>  19 files changed, 495 insertions(+), 405 deletions(-)
>
> --
> 2.26.2
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH v3 07/23] drm/msm/submit: Move copy_from_user ahead of locking bos

[Kristian Høgsberg]

On Mon, Oct 19, 2020 at 10:45 PM Rob Clark  wrote:
>
> From: Rob Clark 
>
> We cannot switch to using obj->resv for locking without first moving all
> the copy_from_user() ahead of submit_lock_objects().  Otherwise in the
> mm fault path we aquire mm->mmap_sem before obj lock, but in the submit
> path the order is reversed.
>
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/msm_gem.h|   3 +
>  drivers/gpu/drm/msm/msm_gem_submit.c | 121 ---
>  2 files changed, 76 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index c5232b8da794..0b7dda312992 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -240,7 +240,10 @@ struct msm_gem_submit {
> uint32_t type;
> uint32_t size;  /* in dwords */
> uint64_t iova;
> +   uint32_t offset;/* in dwords */
> uint32_t idx;   /* cmdstream buffer idx in bos[] */
> +   uint32_t nr_relocs;
> +   struct drm_msm_gem_submit_reloc *relocs;
> } *cmd;  /* array of size nr_cmds */
> struct {
> uint32_t flags;
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index aa5c60a7132d..002130d826aa 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -62,11 +62,16 @@ static struct msm_gem_submit *submit_create(struct 
> drm_device *dev,
>
>  void msm_gem_submit_free(struct msm_gem_submit *submit)
>  {
> +   unsigned i;
> +
> dma_fence_put(submit->fence);
> list_del(>node);
> put_pid(submit->pid);
> msm_submitqueue_put(submit->queue);
>
> +   for (i = 0; i < submit->nr_cmds; i++)
> +   kfree(submit->cmd[i].relocs);
> +
> kfree(submit);
>  }
>
> @@ -150,6 +155,60 @@ static int submit_lookup_objects(struct msm_gem_submit 
> *submit,
> return ret;
>  }
>
> +static int submit_lookup_cmds(struct msm_gem_submit *submit,
> +   struct drm_msm_gem_submit *args, struct drm_file *file)
> +{
> +   unsigned i, sz;
> +   int ret = 0;
> +
> +   for (i = 0; i < args->nr_cmds; i++) {
> +   struct drm_msm_gem_submit_cmd submit_cmd;
> +   void __user *userptr =
> +   u64_to_user_ptr(args->cmds + (i * 
> sizeof(submit_cmd)));
> +
> +   ret = copy_from_user(_cmd, userptr, 
> sizeof(submit_cmd));
> +   if (ret) {
> +   ret = -EFAULT;
> +   goto out;
> +   }
> +
> +   /* validate input from userspace: */
> +   switch (submit_cmd.type) {
> +   case MSM_SUBMIT_CMD_BUF:
> +   case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> +   case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> +   break;
> +   default:
> +   DRM_ERROR("invalid type: %08x\n", submit_cmd.type);
> +   return -EINVAL;
> +   }
> +
> +   if (submit_cmd.size % 4) {
> +   DRM_ERROR("non-aligned cmdstream buffer size: %u\n",
> +   submit_cmd.size);
> +   ret = -EINVAL;
> +   goto out;
> +   }
> +
> +   submit->cmd[i].type = submit_cmd.type;
> +   submit->cmd[i].size = submit_cmd.size / 4;
> +   submit->cmd[i].offset = submit_cmd.submit_offset / 4;
> +   submit->cmd[i].idx  = submit_cmd.submit_idx;
> +   submit->cmd[i].nr_relocs = submit_cmd.nr_relocs;
> +
> +   sz = sizeof(struct drm_msm_gem_submit_reloc) * 
> submit_cmd.nr_relocs;
> +   submit->cmd[i].relocs = kmalloc(sz, GFP_KERNEL);

kmalloc_array() or check_mul_overflow() here for the integer overflow check.

> +   ret = copy_from_user(submit->cmd[i].relocs, userptr, sz);
> +   if (ret) {
> +   ret = -EFAULT;
> +   goto out;
> +   }
> +   }
> +
> +out:
> +   return ret;
> +}
> +
>  static void submit_unlock_unpin_bo(struct msm_gem_submit *submit,
> int i, bool backoff)
>  {
> @@ -301,7 +360,7 @@ static int submit_bo(struct msm_gem_submit *submit, 
> uint32_t idx,
>
>  /* process the reloc's and patch up the cmdstream as needed: */
>  static int submit_reloc(struct msm_gem_submit *submit, struct msm_gem_object 
> *obj,
> -   uint32_t offset, uint32_t nr_relocs, uint64_t relocs)
> +   uint32_t offset, uint32_t nr_relocs, struct 
> drm_msm_gem_submit_reloc *relocs)
>  {
> uint32_t i, last_offset = 0;
> uint32_t *ptr;
> @@ -327,18 +386,11 @@ static int submit_reloc(struct msm_gem_submit *submit, 
> struct msm_gem_object *ob
> }
>
> for (i = 0; i < nr_relocs; i++) {
> - 

Re: [Freedreno] [PATCH v3 06/23] drm/msm/gem: Move locking in shrinker path

[Kristian Høgsberg]

On Mon, Oct 19, 2020 at 10:45 PM Rob Clark  wrote:
>
> From: Rob Clark 
>
> Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to
> skip over bo's that are already locked.  This gets rid of the nested
> lock classes.
>
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/msm_gem.c  | 24 +
>  drivers/gpu/drm/msm/msm_gem.h  | 29 ++
>  drivers/gpu/drm/msm/msm_gem_shrinker.c | 27 +---
>  3 files changed, 35 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index e0d8d739b068..1195847714ba 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -17,8 +17,6 @@
>  #include "msm_gpu.h"
>  #include "msm_mmu.h"
>
> -static void msm_gem_vunmap_locked(struct drm_gem_object *obj);
> -
>
>  static dma_addr_t physaddr(struct drm_gem_object *obj)
>  {
> @@ -693,20 +691,19 @@ int msm_gem_madvise(struct drm_gem_object *obj, 
> unsigned madv)
> return (madv != __MSM_MADV_PURGED);
>  }
>
> -void msm_gem_purge(struct drm_gem_object *obj, enum msm_gem_lock subclass)
> +void msm_gem_purge(struct drm_gem_object *obj)
>  {
> struct drm_device *dev = obj->dev;
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
>
> WARN_ON(!mutex_is_locked(>struct_mutex));
> +   WARN_ON(!msm_gem_is_locked(obj));
> WARN_ON(!is_purgeable(msm_obj));
> WARN_ON(obj->import_attach);
>
> -   mutex_lock_nested(_obj->lock, subclass);
> -
> put_iova(obj);
>
> -   msm_gem_vunmap_locked(obj);
> +   msm_gem_vunmap(obj);
>
> put_pages(obj);
>
> @@ -724,11 +721,9 @@ void msm_gem_purge(struct drm_gem_object *obj, enum 
> msm_gem_lock subclass)
>
> invalidate_mapping_pages(file_inode(obj->filp)->i_mapping,
> 0, (loff_t)-1);
> -
> -   msm_gem_unlock(obj);
>  }
>
> -static void msm_gem_vunmap_locked(struct drm_gem_object *obj)
> +void msm_gem_vunmap(struct drm_gem_object *obj)
>  {
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
>
> @@ -741,15 +736,6 @@ static void msm_gem_vunmap_locked(struct drm_gem_object 
> *obj)
> msm_obj->vaddr = NULL;
>  }
>
> -void msm_gem_vunmap(struct drm_gem_object *obj, enum msm_gem_lock subclass)
> -{
> -   struct msm_gem_object *msm_obj = to_msm_bo(obj);
> -
> -   mutex_lock_nested(_obj->lock, subclass);
> -   msm_gem_vunmap_locked(obj);
> -   msm_gem_unlock(obj);
> -}
> -
>  /* must be called before _move_to_active().. */
>  int msm_gem_sync_object(struct drm_gem_object *obj,
> struct msm_fence_context *fctx, bool exclusive)
> @@ -986,7 +972,7 @@ static void free_object(struct msm_gem_object *msm_obj)
>
> drm_prime_gem_destroy(obj, msm_obj->sgt);
> } else {
> -   msm_gem_vunmap_locked(obj);
> +   msm_gem_vunmap(obj);
> put_pages(obj);
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index d55d5401a2d2..c5232b8da794 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -162,6 +162,13 @@ msm_gem_lock(struct drm_gem_object *obj)
> mutex_lock(_obj->lock);
>  }
>
> +static inline bool __must_check
> +msm_gem_trylock(struct drm_gem_object *obj)
> +{
> +   struct msm_gem_object *msm_obj = to_msm_bo(obj);
> +   return mutex_trylock_recursive(_obj->lock) == 
> MUTEX_TRYLOCK_SUCCESS;

This can just be

return mutex_trylock(_obj->lock) == 1;

now, right?

> +}
> +
>  static inline int
>  msm_gem_lock_interruptible(struct drm_gem_object *obj)
>  {
> @@ -190,6 +197,7 @@ static inline bool is_active(struct msm_gem_object 
> *msm_obj)
>
>  static inline bool is_purgeable(struct msm_gem_object *msm_obj)
>  {
> +   WARN_ON(!msm_gem_is_locked(_obj->base));
> WARN_ON(!mutex_is_locked(_obj->base.dev->struct_mutex));
> return (msm_obj->madv == MSM_MADV_DONTNEED) && msm_obj->sgt &&
> !msm_obj->base.dma_buf && 
> !msm_obj->base.import_attach;
> @@ -197,27 +205,12 @@ static inline bool is_purgeable(struct msm_gem_object 
> *msm_obj)
>
>  static inline bool is_vunmapable(struct msm_gem_object *msm_obj)
>  {
> +   WARN_ON(!msm_gem_is_locked(_obj->base));
> return (msm_obj->vmap_count == 0) && msm_obj->vaddr;
>  }
>
> -/* The shrinker can be triggered while we hold objA->lock, and need
> - * to grab objB->lock to purge it.  Lockdep just sees these as a single
> - * class of lock, so we use subclasses to teach it the difference.
> - *
> - * OBJ_LOCK_NORMAL is implicit (ie. normal mutex_lock() call), and
> - * OBJ_LOCK_SHRINKER is used by shrinker.
> - *
> - * It is *essential* that we never go down paths that could trigger the
> - * shrinker for a purgable object.  This is ensured by checking that
> - * msm_obj->madv == MSM_MADV_WILLNEED.
> - */
> -enum msm_gem_lock {
> -   OBJ_LOCK_NORMAL,
> 

Re: [Freedreno] [PATCH 00/14] drm/msm: de-struct_mutex-ification

[Kristian Høgsberg]

On Sun, Oct 4, 2020 at 9:21 PM Rob Clark  wrote:
>
> From: Rob Clark 
>
> This doesn't remove *all* the struct_mutex, but it covers the worst
> of it, ie. shrinker/madvise/free/retire.  The submit path still uses
> struct_mutex, but it still needs *something* serialize a portion of
> the submit path, and lock_stat mostly just shows the lock contention
> there being with other submits.  And there are a few other bits of
> struct_mutex usage in less critical paths (debugfs, etc).  But this
> seems like a reasonable step in the right direction.

What a great patch set. Daniel has some good points and nothing that
requires big changes, but on the other hand, I'm not sure it's
something that needs to block this set either.

Either way, for the series

Reviewed-by: Kristian H. Kristensen 

> Rob Clark (14):
>   drm/msm: Use correct drm_gem_object_put() in fail case
>   drm/msm: Drop chatty trace
>   drm/msm: Move update_fences()
>   drm/msm: Add priv->mm_lock to protect active/inactive lists
>   drm/msm: Document and rename preempt_lock
>   drm/msm: Protect ring->submits with it's own lock
>   drm/msm: Refcount submits
>   drm/msm: Remove obj->gpu
>   drm/msm: Drop struct_mutex from the retire path
>   drm/msm: Drop struct_mutex in free_object() path
>   drm/msm: remove msm_gem_free_work
>   drm/msm: drop struct_mutex in madvise path
>   drm/msm: Drop struct_mutex in shrinker path
>   drm/msm: Don't implicit-sync if only a single ring
>
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c |  4 +-
>  drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 12 +--
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c |  4 +-
>  drivers/gpu/drm/msm/msm_debugfs.c |  7 ++
>  drivers/gpu/drm/msm/msm_drv.c | 15 +---
>  drivers/gpu/drm/msm/msm_drv.h | 19 +++--
>  drivers/gpu/drm/msm/msm_gem.c | 76 ++
>  drivers/gpu/drm/msm/msm_gem.h | 53 +
>  drivers/gpu/drm/msm/msm_gem_shrinker.c| 58 ++
>  drivers/gpu/drm/msm/msm_gem_submit.c  | 17 ++--
>  drivers/gpu/drm/msm/msm_gpu.c | 96 ++-
>  drivers/gpu/drm/msm/msm_gpu.h |  5 +-
>  drivers/gpu/drm/msm/msm_ringbuffer.c  |  3 +-
>  drivers/gpu/drm/msm/msm_ringbuffer.h  | 13 ++-
>  14 files changed, 188 insertions(+), 194 deletions(-)
>
> --
> 2.26.2
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/14] drm/msm: Drop struct_mutex in shrinker path

[Kristian Høgsberg]

On Mon, Oct 5, 2020 at 4:02 PM Daniel Vetter  wrote:
>
> On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> >
> > On Sun,  4 Oct 2020 12:21:45
> > > From: Rob Clark 
> > >
> > > Now that the inactive_list is protected by mm_lock, and everything
> > > else on per-obj basis is protected by obj->lock, we no longer depend
> > > on struct_mutex.
> > >
> > > Signed-off-by: Rob Clark 
> > > ---
> > >  drivers/gpu/drm/msm/msm_gem.c  |  1 -
> > >  drivers/gpu/drm/msm/msm_gem_shrinker.c | 54 --
> > >  2 files changed, 55 deletions(-)
> > >
> > [...]
> >
> > > @@ -71,13 +33,8 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, 
> > > struct shrink_control *sc)
> > >  {
> > > struct msm_drm_private *priv =
> > > container_of(shrinker, struct msm_drm_private, shrinker);
> > > -   struct drm_device *dev = priv->dev;
> > > struct msm_gem_object *msm_obj;
> > > unsigned long freed = 0;
> > > -   bool unlock;
> > > -
> > > -   if (!msm_gem_shrinker_lock(dev, ))
> > > -   return SHRINK_STOP;
> > >
> > > mutex_lock(>mm_lock);
> >
> > Better if the change in behavior is documented that SHRINK_STOP will
> > no longer be needed.
>
> btw I read through this and noticed you have your own obj lock, plus
> mutex_lock_nested. I strongly recommend to just cut over to dma_resv_lock
> for all object lock needs (soc drivers have been terrible with this
> unfortuntaly), and in the shrinker just use dma_resv_trylock instead of
> trying to play clever games outsmarting lockdep.
>
> I recently wrote an entire blog length rant on why I think
> mutex_lock_nested is too dangerous to be useful:
>
> https://blog.ffwll.ch/2020/08/lockdep-false-positives.html
>
> Not anything about this here, just general comment. The problem extends to
> shmem helpers and all that also having their own locks for everything.

This is definitely a tangible improvement though - very happy to see
msm_gem_shrinker_lock() go.

Reviewed-by: Kristian H. Kristensen 

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH 2/3] drm/msm: Convert shrinker msgs to tracepoints

[Kristian Høgsberg]

On Tue, Sep 1, 2020 at 8:41 AM Rob Clark  wrote:
>
> From: Rob Clark 
>
> This reduces the spam in dmesg when we start hitting the shrinker, and
> replaces it with something we can put on a timeline while profiling or
> debugging system issues.

That is a good solution,

Reviewed-by: Kristian H. Kristensen 

> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/msm_gem_shrinker.c |  5 +++--
>  drivers/gpu/drm/msm/msm_gpu_trace.h| 26 ++
>  2 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c 
> b/drivers/gpu/drm/msm/msm_gem_shrinker.c
> index 722d61668a97..482576d7a39a 100644
> --- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
> +++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
> @@ -6,6 +6,7 @@
>
>  #include "msm_drv.h"
>  #include "msm_gem.h"
> +#include "msm_gpu_trace.h"
>
>  static bool msm_gem_shrinker_lock(struct drm_device *dev, bool *unlock)
>  {
> @@ -87,7 +88,7 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct 
> shrink_control *sc)
> mutex_unlock(>struct_mutex);
>
> if (freed > 0)
> -   pr_info_ratelimited("Purging %lu bytes\n", freed << 
> PAGE_SHIFT);
> +   trace_msm_gem_purge(freed << PAGE_SHIFT);
>
> return freed;
>  }
> @@ -123,7 +124,7 @@ msm_gem_shrinker_vmap(struct notifier_block *nb, unsigned 
> long event, void *ptr)
> *(unsigned long *)ptr += unmapped;
>
> if (unmapped > 0)
> -   pr_info_ratelimited("Purging %u vmaps\n", unmapped);
> +   trace_msm_gem_purge_vmaps(unmapped);
>
> return NOTIFY_DONE;
>  }
> diff --git a/drivers/gpu/drm/msm/msm_gpu_trace.h 
> b/drivers/gpu/drm/msm/msm_gpu_trace.h
> index 07572ab179fa..1079fe551279 100644
> --- a/drivers/gpu/drm/msm/msm_gpu_trace.h
> +++ b/drivers/gpu/drm/msm/msm_gpu_trace.h
> @@ -114,6 +114,32 @@ TRACE_EVENT(msm_gmu_freq_change,
> TP_printk("freq=%u, perf_index=%u", __entry->freq, 
> __entry->perf_index)
>  );
>
> +
> +TRACE_EVENT(msm_gem_purge,
> +   TP_PROTO(u32 bytes),
> +   TP_ARGS(bytes),
> +   TP_STRUCT__entry(
> +   __field(u32, bytes)
> +   ),
> +   TP_fast_assign(
> +   __entry->bytes = bytes;
> +   ),
> +   TP_printk("Purging %u bytes", __entry->bytes)
> +);
> +
> +
> +TRACE_EVENT(msm_gem_purge_vmaps,
> +   TP_PROTO(u32 unmapped),
> +   TP_ARGS(unmapped),
> +   TP_STRUCT__entry(
> +   __field(u32, unmapped)
> +   ),
> +   TP_fast_assign(
> +   __entry->unmapped = unmapped;
> +   ),
> +   TP_printk("Purging %u vmaps", __entry->unmapped)
> +);
> +
>  #endif
>
>  #undef TRACE_INCLUDE_PATH
> --
> 2.26.2
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Kristian Høgsberg]

On Thu, Feb 27, 2020 at 7:38 PM Dave Airlie  wrote:
>
> On Fri, 28 Feb 2020 at 07:27, Daniel Vetter  wrote:
> >
> > Hi all,
> >
> > You might have read the short take in the X.org board meeting minutes
> > already, here's the long version.
> >
> > The good news: gitlab.fd.o has become very popular with our
> > communities, and is used extensively. This especially includes all the
> > CI integration. Modern development process and tooling, yay!
> >
> > The bad news: The cost in growth has also been tremendous, and it's
> > breaking our bank account. With reasonable estimates for continued
> > growth we're expecting hosting expenses totalling 75k USD this year,
> > and 90k USD next year. With the current sponsors we've set up we can't
> > sustain that. We estimate that hosting expenses for gitlab.fd.o
> > without any of the CI features enabled would total 30k USD, which is
> > within X.org's ability to support through various sponsorships, mostly
> > through XDC.
> >
> > Note that X.org does no longer sponsor any CI runners themselves,
> > we've stopped that. The huge additional expenses are all just in
> > storing and serving build artifacts and images to outside CI runners
> > sponsored by various companies. A related topic is that with the
> > growth in fd.o it's becoming infeasible to maintain it all on
> > volunteer admin time. X.org is therefore also looking for admin
> > sponsorship, at least medium term.
> >
> > Assuming that we want cash flow reserves for one year of gitlab.fd.o
> > (without CI support) and a trimmed XDC and assuming no sponsor payment
> > meanwhile, we'd have to cut CI services somewhere between May and June
> > this year. The board is of course working on acquiring sponsors, but
> > filling a shortfall of this magnitude is neither easy nor quick work,
> > and we therefore decided to give an early warning as soon as possible.
> > Any help in finding sponsors for fd.o is very much appreciated.
>
> a) Ouch.
>
> b) we probably need to take a large step back here.

If we're taking a step back here, I also want to recognize what a
tremendous success this has been so far and thank everybody involved
for building something so useful. Between gitlab and the CI, our
workflow has improved and code quality has gone up.  I don't have
anything useful to add to the technical discussion, except that that
it seems pretty standard engineering practice to build a system,
observe it and identify and eliminate bottlenecks. Planning never
hurts, of course, but I don't think anybody could have realistically
modeled and projected the cost of this infrastructure as it's grown
organically and fast.

Kristian

> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor way from these
> hosting credits being bought by us, and I assume we aren't getting any
> sort of discounts here. Having google sponsor the credits costs google
> substantially less than having any other company give us money to do
> it.
>
> If our current CI architecture is going to burn this amount of money a
> year and we hadn't worked this out in advance of deploying it then I
> suggest the system should be taken offline until we work out what a
> sustainable system would look like within the budget we have, whether
> that be never transferring containers and build artifacts from the
> google network, just having local runner/build combos etc.
>
> Dave.
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH] drm/msm: Add syncobj support.

[Kristian Høgsberg]

On Tue, Jan 14, 2020 at 8:41 AM Rob Clark  wrote:
>
> On Tue, Jan 14, 2020 at 7:58 AM Jordan Crouse  wrote:
> >
> > On Tue, Jan 14, 2020 at 01:40:11AM +0100, Bas Nieuwenhuizen wrote:
> > > On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse  
> > > wrote:
> > > >
> > > > On Mon, Jan 13, 2020 at 09:25:57PM +0100, Bas Nieuwenhuizen wrote:
> > > > > This
> > > > >
> > > > > 1) Enables core DRM syncobj support.
> > > > > 2) Adds options to the submission ioctl to wait/signal syncobjs.
> > > > >
> > > > > Just like the wait fence fd, this does inline waits. Using the
> > > > > scheduler would be nice but I believe it is out of scope for
> > > > > this work.
> > > > >
> > > > > Support for timeline syncobjs is implemented and the interface
> > > > > is ready for it, but I'm not enabling it yet until there is
> > > > > some code for turnip to use it.
> > > > >
> > > > > The reset is mostly in there because in the presence of waiting
> > > > > and signalling the same semaphores, resetting them after
> > > > > signalling can become very annoying.
> > > > >
> > > > > Signed-off-by: Bas Nieuwenhuizen 
> > > > > ---
> > > > >
> > > > > Userspace code in
> > > > >
> > > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2769
> > > > >
> > > > >  drivers/gpu/drm/msm/msm_drv.c|   6 +-
> > > > >  drivers/gpu/drm/msm/msm_gem_submit.c | 241 
> > > > > ++-
> > > > >  include/uapi/drm/msm_drm.h   |  22 ++-
> > > > >  3 files changed, 265 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/msm_drv.c 
> > > > > b/drivers/gpu/drm/msm/msm_drv.c
> > > > > index c84f0a8b3f2c..ca36d6b21d8f 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_drv.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > > > > @@ -37,9 +37,10 @@
> > > > >   * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to 
> > > > > set/get
> > > > >   *   GEM object's debug name
> > > > >   * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> > > > > + * - 1.6.0 - Syncobj support
> > > > >   */
> > > > >  #define MSM_VERSION_MAJOR1
> > > > > -#define MSM_VERSION_MINOR5
> > > > > +#define MSM_VERSION_MINOR6
> > > > >  #define MSM_VERSION_PATCHLEVEL   0
> > > > >
> > > > >  static const struct drm_mode_config_funcs mode_config_funcs = {
> > > > > @@ -988,7 +989,8 @@ static struct drm_driver msm_driver = {
> > > > >   .driver_features= DRIVER_GEM |
> > > > >   DRIVER_RENDER |
> > > > >   DRIVER_ATOMIC |
> > > > > - DRIVER_MODESET,
> > > > > + DRIVER_MODESET|
> > > >
> > > > A space before the | would be preferred.
> > >
> > > Done.
> > > >
> > > > > + DRIVER_SYNCOBJ,
> > > > >   .open   = msm_open,
> > > > >   .postclose   = msm_postclose,
> > > > >   .lastclose  = drm_fb_helper_lastclose,
> > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> > > > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > index be5327af16fa..9085229f88e0 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > @@ -8,7 +8,9 @@
> > > > >  #include 
> > > > >  #include 
> > > > >
> > > > > +#include 
> > > > >  #include 
> > > > > +#include 
> > > > >
> > > > >  #include "msm_drv.h"
> > > > >  #include "msm_gpu.h"
> > > > > @@ -394,6 +396,196 @@ static void submit_cleanup(struct 
> > > > > msm_gem_submit *submit)
> > > > >   ww_acquire_fini(>ticket);
> > > > >  }
> > > > >
> > > > > +
> > > > > +struct msm_submit_post_dep {
> > > > > + struct drm_syncobj *syncobj;
> > > > > + uint64_t point;
> > > > > + struct dma_fence_chain *chain;
> > > > > +};
> > > > > +
> > > > > +static int msm_wait_deps(struct drm_device *dev,
> > > > > + struct drm_file *file,
> > > > > + uint64_t in_syncobjs_addr,
> > > > > + uint32_t nr_in_syncobjs,
> > > > > + struct msm_ringbuffer *ring,
> > > > > + struct drm_syncobj ***syncobjs)
> > > > > +{
> > > > > + struct drm_msm_gem_submit_syncobj *syncobj_descs;
> > > > > + int ret = 0;
> > > > > + uint32_t i, j;
> > > > > +
> > > > > + syncobj_descs = kmalloc_array(nr_in_syncobjs, 
> > > > > sizeof(*syncobj_descs),
> > > > > +   GFP_KERNEL);
> > > > > + if (!syncobj_descs)
> > > > > + return -ENOMEM;
> > > > > +
> > > > We would want to watch out here for fuzzers and malicious actors that 
> > > > try to
> > > > force an enormous memory allocation. It seems like we should be able to
> > > > iteratively read each fences in the loop and skip this memory 
> > > > allocation.
> > > >
> > > > > + *syncobjs = kcalloc(nr_in_syncobjs, sizeof(**syncobjs), 
> > > > > GFP_KERNEL);
> > > > > + if (!syncobjs) {
> > > > > + 

Re: [Freedreno] [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

[Kristian Høgsberg]

On Mon, Jan 13, 2020 at 3:17 PM Rob Clark  wrote:
>
> On Mon, Jan 13, 2020 at 2:55 PM Brian Ho  wrote:
> >
> > On Mon, Jan 13, 2020 at 09:57:43AM -0800, Kristian Kristensen wrote:
> > > On Mon, Jan 13, 2020 at 8:25 AM Rob Clark  wrote:
> > >
> > > > On Mon, Jan 13, 2020 at 7:37 AM Brian Ho  wrote:
> > > > >
> > > > > Implements an ioctl to wait until a value at a given iova is greater
> > > > > than or equal to a supplied value.
> > > > >
> > > > > This will initially be used by turnip (open-source Vulkan driver for
> > > > > QC in mesa) for occlusion queries where the userspace driver can
> > > > > block on a query becoming available before continuing via
> > > > > vkGetQueryPoolResults.
> > > > >
> > > > > Signed-off-by: Brian Ho 
> > > > > ---
> > > > >  drivers/gpu/drm/msm/msm_drv.c | 63 
> > > > > +--
> > > > >  include/uapi/drm/msm_drm.h| 13 
> > > > >  2 files changed, 74 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/msm_drv.c
> > > > b/drivers/gpu/drm/msm/msm_drv.c
> > > > > index c84f0a8b3f2c..dcc46874a5a2 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_drv.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > > > > @@ -36,10 +36,11 @@
> > > > >   *   MSM_GEM_INFO ioctl.
> > > > >   * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to 
> > > > > set/get
> > > > >   *   GEM object's debug name
> > > > > - * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> > > > > + * - 1.5.0 - Add SUBMITQUEUE_QUERY ioctl
> > > > > + * - 1.6.0 - Add WAIT_IOVA ioctl
> > > > >   */
> > > > >  #define MSM_VERSION_MAJOR  1
> > > > > -#define MSM_VERSION_MINOR  5
> > > > > +#define MSM_VERSION_MINOR  6
> > > > >  #define MSM_VERSION_PATCHLEVEL 0
> > > > >
> > > > >  static const struct drm_mode_config_funcs mode_config_funcs = {
> > > > > @@ -952,6 +953,63 @@ static int msm_ioctl_submitqueue_close(struct
> > > > drm_device *dev, void *data,
> > > > > return msm_submitqueue_remove(file->driver_priv, id);
> > > > >  }
> > > > >
> > > > > +static int msm_ioctl_wait_iova(struct drm_device *dev, void *data,
> > > > > +   struct drm_file *file)
> > > > > +{
> > > > > +   struct msm_drm_private *priv = dev->dev_private;
> > > > > +   struct drm_gem_object *obj;
> > > > > +   struct drm_msm_wait_iova *args = data;
> > > > > +   ktime_t timeout = to_ktime(args->timeout);
> > > > > +   unsigned long remaining_jiffies = 
> > > > > timeout_to_jiffies();
> > > > > +   struct msm_gpu *gpu = priv->gpu;
> > > > > +   void *base_vaddr;
> > > > > +   uint64_t *vaddr;
> > > > > +   int ret;
> > > > > +
> > > > > +   if (args->pad)
> > > > > +   return -EINVAL;
> > > > > +
> > > > > +   if (!gpu)
> > > > > +   return 0;
> > > >
> > > > hmm, I'm not sure we should return zero in this case.. maybe -ENODEV?
> > > >
> > > > > +
> > > > > +   obj = drm_gem_object_lookup(file, args->handle);
> > > > > +   if (!obj)
> > > > > +   return -ENOENT;
> > > > > +
> > > > > +   base_vaddr = msm_gem_get_vaddr(obj);
> > > > > +   if (IS_ERR(base_vaddr)) {
> > > > > +   ret = PTR_ERR(base_vaddr);
> > > > > +   goto err_put_gem_object;
> > > > > +   }
> > > > > +   if (args->offset + sizeof(*vaddr) > obj->size) {
> > > > > +   ret = -EINVAL;
> > > > > +   goto err_put_vaddr;
> > > > > +   }
> > > > > +
> > > > > +   vaddr = base_vaddr + args->offset;
> > > > > +
> > > > > +   /* Assumes WC mapping */
> > > > > +   ret = wait_event_interruptible_timeout(
> > > > > +   gpu->event, *vaddr >= args->value,
> > > > remaining_jiffies);
> > > >
> > >
> > > This needs to do the awkward looking
> > >
> > >   (int64_t)(*data - value) >= 0
> > >
> > > to properly handle the wraparound case.
> > >
> >
> > I think this comparison will run into issues if we allow for 64-bit
> > reference values. For example, if value is ULLONG_MAX, and *data
> > starts at 0 on the first comparison, we'll immediately return.

The comparison will have to account of the number of bits in the
serial number. The (int64_t) (*data - value) works for 64 bit unsigned
serial numbers, but for 32 bit serials as suggested below, we need to
cast to int32_t. It does work though, in the case where value is
ULLONG_MAX and and *data is 0, 0 - ULLONG_MAX is one, which is
correct. The serial numbers wrap around and the distance is computed
modulo 2^64. See
https://en.wikipedia.org/wiki/Serial_number_arithmetic.

> >
> > It's not too much of an issue in fence_completed (msm_fence.c), but
> > in this ioctl, *data can grow at an arbitrary rate. Are we concerned
> > about this?
> >
> > > > +
> > > > > +   if (ret == 0) {
> > > > > +   ret = -ETIMEDOUT;
> > > > > +   goto err_put_vaddr;
> > > > > +   } else if (ret == -ERESTARTSYS) {
> > > > > +   goto 

Re: [Freedreno] [PATCH 2/3] drm/msm/dpu: Avoid a null de-ref while recovering from kms init fail

[Kristian Høgsberg]

On Tue, May 7, 2019 at 12:18 PM Jordan Crouse  wrote:
>
> In the failure path for dpu_kms_init() it is possible to get to the MMU
> destroy function with uninitialized MMU structs. Check for NULl and skip

s/NULl/NULL

> if needed.
>
> Signed-off-by: Jordan Crouse 

Reviewed-by: Kristian H. Kristensen 

> ---
>
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 885bf88..1beaf29 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -56,7 +56,7 @@ static const char * const iommu_ports[] = {
>  #define DPU_DEBUGFS_HWMASKNAME "hw_log_mask"
>
>  static int dpu_kms_hw_init(struct msm_kms *kms);
> -static int _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
> +static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
>
>  static unsigned long dpu_iomap_size(struct platform_device *pdev,
> const char *name)
> @@ -725,17 +725,20 @@ static const struct msm_kms_funcs kms_funcs = {
>  #endif
>  };
>
> -static int _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
> +static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
>  {
> struct msm_mmu *mmu;
>
> +   if (!dpu_kms->base.aspace)
> +   return;
> +
> mmu = dpu_kms->base.aspace->mmu;
>
> mmu->funcs->detach(mmu, (const char **)iommu_ports,
> ARRAY_SIZE(iommu_ports));
> msm_gem_address_space_put(dpu_kms->base.aspace);
>
> -   return 0;
> +   dpu_kms->base.aspace = NULL;
>  }
>
>  static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
> --
> 2.7.4
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH v1 2/3] drm/msm: Print all 64 bits of the faulting IOMMU address

[Kristian Høgsberg]

On Tue, May 7, 2019 at 11:02 AM Jordan Crouse  wrote:
>
> When we move to 64 bit addressing for a5xx and a6xx targets we will start
> seeing pagefaults at larger addresses so format them appropriately in the
> log message for easier debugging.

Yes please, this has confused me more than once.

Reviewed-by: Kristian H. Kristensen 

> Signed-off-by: Jordan Crouse 
> ---
>
>  drivers/gpu/drm/msm/msm_iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 12bb54c..1926329 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -30,7 +30,7 @@ static int msm_fault_handler(struct iommu_domain *domain, 
> struct device *dev,
> struct msm_iommu *iommu = arg;
> if (iommu->base.handler)
> return iommu->base.handler(iommu->base.arg, iova, flags);
> -   pr_warn_ratelimited("*** fault: iova=%08lx, flags=%d\n", iova, flags);
> +   pr_warn_ratelimited("*** fault: iova=%16lx, flags=%d\n", iova, flags);
> return 0;
>  }
>
> --
> 2.7.4
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH] drm/msm: fix handling of cmdstream offset

[Kristian Høgsberg]

On Mon, Oct 15, 2018 at 10:33 AM Rob Clark  wrote:
>
> Userspace hasn't used submit cmds with submit_offset != 0 for a while,
> but this starts cropping up again with cmdstream sub-buffer-allocation
> in libdrm_freedreno.
>
> Doesn't do much good to increment the buf ptr before assigning it.

Reviewed-by: Kristian H. Kristensen 

> Fixes: 78b8e5b847b4 drm/msm: dump a rd GPUADDR header for all buffers in the 
> command
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/msm_rd.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
> index cca933458439..0c2c8d2c631f 100644
> --- a/drivers/gpu/drm/msm/msm_rd.c
> +++ b/drivers/gpu/drm/msm/msm_rd.c
> @@ -316,10 +316,11 @@ static void snapshot_buf(struct msm_rd_state *rd,
> uint64_t iova, uint32_t size)
>  {
> struct msm_gem_object *obj = submit->bos[idx].obj;
> +   unsigned offset = 0;
> const char *buf;
>
> if (iova) {
> -   buf += iova - submit->bos[idx].iova;
> +   offset = iova - submit->bos[idx].iova;
> } else {
> iova = submit->bos[idx].iova;
> size = obj->base.size;
> @@ -340,6 +341,8 @@ static void snapshot_buf(struct msm_rd_state *rd,
> if (IS_ERR(buf))
> return;
>
> +   buf += offset;
> +
> rd_write_section(rd, RD_BUFFER_CONTENTS, buf, size);
>
> msm_gem_put_vaddr(>base);
> --
> 2.17.2
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [ANNOUNCE] libdrm 2.4.94

[Kristian Høgsberg]

On Fri, Aug 24, 2018 at 1:13 AM Michel Dänzer  wrote:
>
> On 2018-08-24 12:37 a.m., Kristian H. Kristensen wrote:
> > Benjamin Gaignard (2):
> >   tests/modetest: Add atomic support
> >   tests/util: Add support for stm module
> >
> > Christian König (7):
> >   amdgpu: stop using the hash table for fd_tab
> >   amdgpu: add handle table implementation v2
> >   amdgpu: use handle table for KMS handles
> >   amdgpu: use handle table for flink names
> >   amdgpu: remove the hash table implementation
> >   amdgpu: always add all BOs to handle table
> >   amdgpu: fix off by one in handle_table_insert
> >
> > Junwei Zhang (5):
> >   amdgpu: add bo from user memory to handle table
> >   amdgpu: add a function to find bo by cpu mapping (v2)
> >   tests/amdgpu: add test for finding bo by CPU mapping
> >   amdgpu: free flink bo in bo import
> >   amdgpu: add a function to create amdgpu bo internally (v4)
> >
> > Kristian H. Kristensen (1):
> >   Bump to version 2.4.94
> >
> > Likun Gao (1):
> >   amdgpu: Disable deadlock test suite for RV
> >
> > Michel Dänzer (2):
> >   amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping
> >   amdgpu: Eliminate void* arithmetic in amdgpu_find_bo_by_cpu_mapping
> >
> > Mike Lothian (1):
> >   libdrm: Fix amdgpu build failure
> >
> > Rob Clark (2):
> >   freedreno: don't leak stateobj rb refs
> >   freedreno: fix use-after-free with stateobj rb's
> >
> > Rodrigo Vivi (1):
> >   intel: Add a new CFL PCI ID.
> >
> > Tanmay Shah (1):
> >   libdrm: add msm drm uapi header
>
> Would have been nice to wait for
> https://patchwork.freedesktop.org/patch/245762/ to land, or at least
> give a little heads up, before making a release.

I don't know what all is pending for libdrm, but I know that we've
agreed on a very low bar for when to release libdrm:

   "The release criteria for libdrm is essentially "if you need a release,
make one".  There is no designated release engineer or maintainer.
Anybody is free to make a release if there's a certain feature or bug
fix they need in a released version of libdrm."

Kristian


> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [ANNOUNCE] libdrm 2.4.94

[Kristian Høgsberg]

On Thu, Aug 23, 2018 at 10:44 PM Laurent Carlier  wrote:
>
> Le vendredi 24 août 2018, 00:37:51 CEST Kristian H. Kristensen a écrit :
> > https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2
>
> -> Forbidden
>
> You don't have permission to access /libdrm/libdrm-2.4.94.tar.bz2 on this
> server.

Fixed.

> > PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2.sig
>
> -> Not Found
>
> The requested URL /libdrm/libdrm-2.4.94.tar.bz2.sig was not found on this
> server.

Yes, I don't have a PGP key, I should have edited that out of the
email template.

thanks,
Kristian

> -
> Laurent Carlier
> http://www.archlinux.org___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/msm: Remove pm_runtime operations from msm_iommu

[Kristian Høgsberg]

On Mon, Jun 11, 2018 at 11:26 AM Jordan Crouse  wrote:
>
> Now that the IOMMU is the master of it's own power we don't need to bring
> up the GPU to do IOMMU operations. This is good because bringing up a6xx
> requires the GMU so calling pm_runtime_get_sync() too early in the process
> gets us into some nasty circular dependency situations.
>
> Signed-off-by: Jordan Crouse 

Reviewed-by: Kristian H. Kristensen 

> ---
>  drivers/gpu/drm/msm/msm_iommu.c | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index b23d33622f37..ccd93ac6a4d8 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -40,9 +40,7 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char 
> * const *names,
> struct msm_iommu *iommu = to_msm_iommu(mmu);
> int ret;
>
> -   pm_runtime_get_sync(mmu->dev);
> ret = iommu_attach_device(iommu->domain, mmu->dev);
> -   pm_runtime_put_sync(mmu->dev);
>
> return ret;
>  }
> @@ -52,9 +50,7 @@ static void msm_iommu_detach(struct msm_mmu *mmu, const 
> char * const *names,
>  {
> struct msm_iommu *iommu = to_msm_iommu(mmu);
>
> -   pm_runtime_get_sync(mmu->dev);
> iommu_detach_device(iommu->domain, mmu->dev);
> -   pm_runtime_put_sync(mmu->dev);
>  }
>
>  static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
> @@ -63,9 +59,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
> struct msm_iommu *iommu = to_msm_iommu(mmu);
> size_t ret;
>
> -// pm_runtime_get_sync(mmu->dev);
> ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
> -// pm_runtime_put_sync(mmu->dev);
> WARN_ON(ret < 0);
>
> return (ret == len) ? 0 : -EINVAL;
> @@ -76,9 +70,7 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t 
> iova,
>  {
> struct msm_iommu *iommu = to_msm_iommu(mmu);
>
> -   pm_runtime_get_sync(mmu->dev);
> iommu_unmap(iommu->domain, iova, len);
> -   pm_runtime_put_sync(mmu->dev);
>
> return 0;
>  }
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/rockchip: Filter out alpha formats for primary plane

[Kristian Høgsberg]

On Mon, Apr 16, 2018 at 2:59 PM Eric Anholt  wrote:

> "Kristian H. Kristensen"  writes:

> > Rockchip doesn't support per-pixel alpha blending for the lowest
> > window in the stack. While the hw supports restacking the windows, we
> > don't expose that in KMS, so just filter out alpha formats for the
> > primary plane.

> In discussing this for VC4, we noted that an alternative is to just set
> up the lowest plane as an RGBX format, since alpha is premultiplied and
> the background is black.

Doh, of course. Thanks Eric.

Kristian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Kristian Høgsberg]

On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher <alexdeuc...@gmail.com> wrote:

> On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace <chadvers...@chromium.org>
wrote:
> > On Thu 21 Dec 2017, Daniel Vetter wrote:
> >> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen <
hoegsb...@google.com> wrote:
> >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <
mvicom...@nvidia.com> wrote:
> >>>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg <
hoegsb...@gmail.com> wrote:
> >>>>> I'd like to see concrete examples of actual display controllers
> >>>>> supporting more format layouts than what can be specified with a 64
> >>>>> bit modifier.
> >>>>
> >>>> The main problem is our tiling and other metadata parameters can't
> >>>> generally fit in a modifier, so we find passing a blob of metadata a
> >>>> more suitable mechanism.
> >>>
> >>> I understand that you may have n knobs with a total of more than a
total of
> >>> 56 bits that configure your tiling/swizzling for color buffers. What
I don't
> >>> buy is that you need all those combinations when passing buffers
around
> >>> between codecs, cameras and display controllers. Even if you're
sharing
> >>> between the same 3D drivers in different processes, I expect just
locking
> >>> down, say, 64 different combinations (you can add more over time) and
> >>> assigning each a modifier would be sufficient. I doubt you'd extract
> >>> meaningful performance gains from going all the way to a blob.
> >
> > I agree with Kristian above. In my opinion, choosing to encode in
> > modifiers a precise description of every possible tiling/compression
> > layout is not technically incorrect, but I believe it misses the point.
> > The intention behind modifiers is not to exhaustively describe all
> > possibilites.
> >
> > I summarized this opinion in VK_EXT_image_drm_format_modifier,
> > where I wrote an "introdution to modifiers" section. Here's an excerpt:
> >
> > One goal of modifiers in the Linux ecosystem is to enumerate for
each
> > vendor a reasonably sized set of tiling formats that are
appropriate for
> > images shared across processes, APIs, and/or devices, where each
> > participating component may possibly be from different vendors.
> > A non-goal is to enumerate all tiling formats supported by all
vendors.
> > Some tiling formats used internally by vendors are inappropriate for
> > sharing; no modifiers should be assigned to such tiling formats.

> Where it gets tricky is how to select that subset?  Our tiling mode
> are defined more by the asic specific constraints than the tiling mode
> itself.  At a high level we have basically 3 tiling modes (out of 16
> possible) that would be the minimum we'd want to expose for gfx6-8.
> gfx9 uses a completely new scheme.
> 1. Linear (per asic stride requirements, not usable by many hw blocks)
> 2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick)
> 3. 2D Thin (1D tiling constraints, plus pipe config (18 possible),
> tile split (7 possible), sample split (4 possible), num banks (4
> possible), bank width (4 possible), bank height (4 possible), macro
> tile aspect (4 possible) all of which are asic config specific)

> I guess we could do something like:
> AMD_GFX6_LINEAR_ALIGNED_64B
> AMD_GFX6_LINEAR_ALIGNED_256B
> AMD_GFX6_LINEAR_ALIGNED_512B
> AMD_GFX6_1D_THIN_DISPLAY
> AMD_GFX6_1D_THIN_DEPTH
> AMD_GFX6_1D_THIN_ROTATED
> AMD_GFX6_1D_THIN_THIN
> AMD_GFX6_1D_THIN_THICK

AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Kristian Høgsberg]

On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson 
wrote:

> Quoting Andy Lutomirski (2018-02-01 17:40:22)
> > *However*, I do see one unfortunate side effect of turning on PSR.  It
> > seems that, when I move my cursor a little bit after a few seconds of
> > doing nothing, there seems to be a little bit of lag, as if either a
> > few frames are dropped at the beginning of the motion or maybe the
> > entire motion is delayed a bit.  I don't notice a similar delay when
> > typing, so I'm wondering if maybe there's a min
> or driver bug in which
> > the driver doesn't kick the panel out of PSR quite as quickly when the
> > cursor is updated as it does when the framebuffer is updated.

> One thing that's important know regarding the cursor is whether the
> display server is using a HW cursor or SW cursor. Could you please attach
> the log from the display server (or if you are using a stock
> distribution that's probably enough to work out what it is using)?
> -Chris

We had a similar problem for Rockchip in ChromeOS and ended up using an
input handler to let us start the PSR exit as early as possible:


https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_psr.c#345

It's similar in spirit to the interactive cpufreq governor:

   https://lwn.net/Articles/662209/

Kristian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [ANNOUNCE] Wayland/Weston/Mesa HDR support (proof of concept)

[Kristian Høgsberg]

On Thu, Dec 21, 2017 at 6:21 AM, Ville Syrjälä
 wrote:
> Here's a quick proof of concept implementation of HDR support
> for Wayland/Weston/Mesa.
>
> I'm not posting this as patches right now because I'm not sure
> that would do much good given how rough this is. But here are
> all the repos/branches:
> git://github.com/vsyrjala/wayland.git hdr_poc
> git://github.com/vsyrjala/wayland-protocols.git hdr_poc
> git://github.com/vsyrjala/weston.git hdr_poc
> git://github.com/vsyrjala/mesa.git hdr_poc
> git://github.com/vsyrjala/linux.git hdr_poc
>
> The kernel HDR bits were partially done by Uma Shankar, the rest
> I hacked together myself.

Hi Ville,

This looks really interesting, thanks for the heads up.

Kristian

> As far as Wayland protocol goes I'm adding three new
> extensions (should probably just have one with several requests?):
> - zwp_colorspace_v1 - Specify the primaries/whitepoint chromacities
>   and transfer function for a surface
> - zwp_ycbcr_encoding_v1 - Specify the encoding for YCbCr surfaces
> - zwp_hdr_metadata_v1 - Allow the client to pass HDR metadata to
>   the compositor
> Note that I've not given any thought to how the compositor might
> advertize its capabilities.
>
> I also hacked in a bunch of 10bpc+ YCbCr support to the protocol and
> Weston so that I can actually get some HDR video onto the screen.
>
> On the Mesa side I've crudely implementated the following egl/vk
> extesions:
> - EXT_gl_colorspace_*
> - EXT_surface_SMPTE2086_metadata
> - EXT_surface_CTA861_3_metadata
>   (sidenote: these egl extension don't seem to match CTA-861.3 nicely
>when it comes to the min/max luminance stuff)
> - VK_EXT_hdr_metadata
>
> VK_EXT_hdr_metadata I plugged in for anv only, but the implementation
> is in the common wayland wsi code. Note that I haven't actually tested
> the vulkan stuff at all because I don't talk Vulkan (at least not yet).
>
> Also note that I've not connected up the HDR metadata pipeline
> properly. The client can provide the metadata, but the compositor
> doesn't actually pass it on to the display. For the time being the
> HDR metadata that gets passed to the display is partially specified
> in weston.ini and partially just hardocded (see
> libweston/compositor-drm.c).
>
> The Weston implementation involves a bunch of shaders and matrices to
> do the ycbcr->rgb, "degamma", csc for each surface, blend it all as
> linear RGB into an fp16 fbo, and finally blit that out to the final
> framebuffer while applying the ST2084 PQ transfer function in the
> process.
>
> The reason for the fp16 fbo is that we store the full 1 nits of
> linear RGB. That needs plenty of precisions in the low end so your
> regular 10bpc fb doesn't seem to cut it. And also the display gamma LUT
> doesn't have enough input precision for it either. Sadly there's no
> fixed function hardware in the GPU to do the ST2084 PQ when blending.
> When the output is not HDR I do skip the fp16 fbo step and use the
> gamma LUT in the display engine instead.
>
> Another approach to the precisions problem might be to not store the
> entire 1 nits of linear, and just cut off the super bright stuff
> (your display can't show it anyway). But I've not really bothered to
> figure out how low in nits we'd have to go here, probably too low.
> Maybe blending as sRGB and the doing sRGB->PQ with the gamma LUT might
> help a little bit?
>
> Ideally we would bypass this all for a single fullscreen HDR surface
> and just pass the PQ encoded data directly through. But I've not
> implemented that. In fact I even disable the buffer_age damage stuff
> when using the fp16 fbo, so we'll recompose the entire screen every
> time. Yeah, I'm lazy.
>
> Another thought that occurred to me was that it shouldn't be too hard
> to make Weston do some tone mapping when there's a HDR client and no
> HDR screen. To that end I included the ACES colorspaces in my
> colorspace list, but I didn't actually look into plugging the ACES tone
> mapping curve into the shaders. Might be a fun excercise, even though
> the practical applications might be close to nil. Probably better to
> not advertize HDR/wide gamuts when we can't actually output the stuff,
> and instead let the client do its own tone mapping.
>
> OK, so what can you do with this? I've included a few test clients:
> - simple-colorspace
>   Just a copy of simple-egl but it uses the egl extension to specify
>   the colorspace, and produces ST2084 PQ encoded data when asked
> - simple-hdr-video
>   Uses ffmpeg to decode video into shm buffers, and sets the
>   colorspace/ycbcr encoding etc. appropriately. Ie. this one can
>   actually output HDR video
>
> Here's a weston.ini snippet that gets you outputting HDR:
> [core]
> gbm-format=xrgb2101010
>
> [output]
> name=HDMI-A-2
> colorspace=BT.2020
> gamma=ST2084
> max_sdr_nits=100
>
> Hardware wise you'll need a HDR capable display obviously, and
> you'll need an Intel Geminilake GPU. Older Intel platforms 

Re: [PATCH] drm/framebuffer: Add framebuffer debugfs file

[Kristian Høgsberg]

On Tue, Oct 24, 2017 at 9:39 AM, Noralf Trønnes <nor...@tronnes.org> wrote:
>
> Den 23.10.2017 23.32, skrev Kristian Høgsberg:
>>
>> On Mon, Oct 23, 2017 at 9:47 AM, Noralf Trønnes <nor...@tronnes.org>
>> wrote:
>>>
>>> Add debugfs file that dumps info about the framebuffers and its planes.
>>> Also dump info about any connected gem object(s).
>>>
>>> Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
>>> ---
>>>   drivers/gpu/drm/drm_debugfs.c |  6 +
>>>   drivers/gpu/drm/drm_framebuffer.c | 51
>>> +++
>>>   drivers/gpu/drm/drm_gem.c | 11 +
>>>   drivers/gpu/drm/drm_internal.h|  4 +++
>>>   4 files changed, 72 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_debugfs.c
>>> b/drivers/gpu/drm/drm_debugfs.c
>>> index c1807d5754b2..550f29de6c1f 100644
>>> --- a/drivers/gpu/drm/drm_debugfs.c
>>> +++ b/drivers/gpu/drm/drm_debugfs.c
>>> @@ -158,6 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int
>>> minor_id,
>>>  }
>>>  }
>>>
>>> +   ret = drm_framebuffer_debugfs_init(minor);
>>> +   if (ret) {
>>> +   DRM_ERROR("Failed to create framebuffer debugfs file\n");
>>> +   return ret;
>>> +   }
>>> +
>>>  if (dev->driver->debugfs_init) {
>>>  ret = dev->driver->debugfs_init(minor);
>>>  if (ret) {
>>> diff --git a/drivers/gpu/drm/drm_framebuffer.c
>>> b/drivers/gpu/drm/drm_framebuffer.c
>>> index af279844d7ce..ebdfe2b5689f 100644
>>> --- a/drivers/gpu/drm/drm_framebuffer.c
>>> +++ b/drivers/gpu/drm/drm_framebuffer.c
>>> @@ -25,7 +25,9 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>
>>> +#include "drm_internal.h"
>>>   #include "drm_crtc_internal.h"
>>>
>>>   /**
>>> @@ -955,3 +957,52 @@ int drm_framebuffer_plane_height(int height,
>>>  return fb_plane_height(height, fb->format, plane);
>>>   }
>>>   EXPORT_SYMBOL(drm_framebuffer_plane_height);
>>> +
>>> +#ifdef CONFIG_DEBUG_FS
>>> +static void drm_framebuffer_print(struct drm_framebuffer *fb,
>>> + struct drm_printer *p)
>>> +{
>>> +   unsigned int i;
>>> +
>>> +   drm_printf(p, "[FB:%d] %dx%d@%4.4s refcount=%d\n", fb->base.id,
>>> +  fb->width, fb->height, (char *)>format->format,
>>> +  drm_framebuffer_read_refcount(fb));
>>
>> Could you print the format modifier as well?
>>
>>> +
>>> +   for (i = 0; i < fb->format->num_planes; i++) {
>>> +   drm_printf(p, "\t%u: offset=%d pitch=%d",
>>> +  i, fb->offsets[i], fb->pitches[i]);
>>> +   if (fb->obj[i]) {
>>> +   drm_printf(p, " GEM: ");
>>> +   drm_gem_print(fb->obj[i], p);
>>> +   } else {
>>> +   drm_printf(p, "\n");
>>> +   }
>>> +   }
>>> +}
>>> +
>>> +static int drm_framebuffer_info(struct seq_file *m, void *data)
>>> +{
>>> +   struct drm_info_node *node = m->private;
>>> +   struct drm_device *dev = node->minor->dev;
>>> +   struct drm_printer p = drm_seq_file_printer(m);
>>> +   struct drm_framebuffer *fb;
>>> +
>>> +   mutex_lock(>mode_config.fb_lock);
>>> +   drm_for_each_fb(fb, dev)
>>> +   drm_framebuffer_print(fb, );
>>> +   mutex_unlock(>mode_config.fb_lock);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static const struct drm_info_list drm_framebuffer_debugfs_list[] = {
>>> +   { "framebuffer", drm_framebuffer_info, 0 },
>>
>> This is quite useful, thanks. Ultimately, it would be very nice to
>> have something like i915_display_info, but in a generic way. There's
>> not much there that's actually i915 specific:
>
>
> How about mimicking drm_state_info(), debugfs file 'state', and create
> an 'info' file?
>
> struct drm_crtc_funcs {
> /**
>  * @print_info:
>  *
>

Re: [PATCH] drm/framebuffer: Add framebuffer debugfs file

[Kristian Høgsberg]

On Mon, Oct 23, 2017 at 9:47 AM, Noralf Trønnes  wrote:
> Add debugfs file that dumps info about the framebuffers and its planes.
> Also dump info about any connected gem object(s).
>
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_debugfs.c |  6 +
>  drivers/gpu/drm/drm_framebuffer.c | 51 
> +++
>  drivers/gpu/drm/drm_gem.c | 11 +
>  drivers/gpu/drm/drm_internal.h|  4 +++
>  4 files changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index c1807d5754b2..550f29de6c1f 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -158,6 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int 
> minor_id,
> }
> }
>
> +   ret = drm_framebuffer_debugfs_init(minor);
> +   if (ret) {
> +   DRM_ERROR("Failed to create framebuffer debugfs file\n");
> +   return ret;
> +   }
> +
> if (dev->driver->debugfs_init) {
> ret = dev->driver->debugfs_init(minor);
> if (ret) {
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index af279844d7ce..ebdfe2b5689f 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -25,7 +25,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
> +#include "drm_internal.h"
>  #include "drm_crtc_internal.h"
>
>  /**
> @@ -955,3 +957,52 @@ int drm_framebuffer_plane_height(int height,
> return fb_plane_height(height, fb->format, plane);
>  }
>  EXPORT_SYMBOL(drm_framebuffer_plane_height);
> +
> +#ifdef CONFIG_DEBUG_FS
> +static void drm_framebuffer_print(struct drm_framebuffer *fb,
> + struct drm_printer *p)
> +{
> +   unsigned int i;
> +
> +   drm_printf(p, "[FB:%d] %dx%d@%4.4s refcount=%d\n", fb->base.id,
> +  fb->width, fb->height, (char *)>format->format,
> +  drm_framebuffer_read_refcount(fb));

Could you print the format modifier as well?

> +
> +   for (i = 0; i < fb->format->num_planes; i++) {
> +   drm_printf(p, "\t%u: offset=%d pitch=%d",
> +  i, fb->offsets[i], fb->pitches[i]);
> +   if (fb->obj[i]) {
> +   drm_printf(p, " GEM: ");
> +   drm_gem_print(fb->obj[i], p);
> +   } else {
> +   drm_printf(p, "\n");
> +   }
> +   }
> +}
> +
> +static int drm_framebuffer_info(struct seq_file *m, void *data)
> +{
> +   struct drm_info_node *node = m->private;
> +   struct drm_device *dev = node->minor->dev;
> +   struct drm_printer p = drm_seq_file_printer(m);
> +   struct drm_framebuffer *fb;
> +
> +   mutex_lock(>mode_config.fb_lock);
> +   drm_for_each_fb(fb, dev)
> +   drm_framebuffer_print(fb, );
> +   mutex_unlock(>mode_config.fb_lock);
> +
> +   return 0;
> +}
> +
> +static const struct drm_info_list drm_framebuffer_debugfs_list[] = {
> +   { "framebuffer", drm_framebuffer_info, 0 },

This is quite useful, thanks. Ultimately, it would be very nice to
have something like i915_display_info, but in a generic way. There's
not much there that's actually i915 specific:

localhost ~ # cat /sys/kernel/debug/dri/0/i915_display_info
CRTC info
-
CRTC 36: pipe: A, active=yes, (size=2400x1600), dither=no, bpp=24
fb: 88, pos: 0x0, size: 2400x1600
encoder 57: type: TMDS-57, connectors:
connector 58: type: eDP-1, status: connected, mode:
id 0:"2400x1600" freq 60 clock 252750 hdisp 2400 hss
2448 hse 2480 htot 2560 vdisp 1600 vss 1603 vse 1613 vtot 1646 type
0x48 flags 0xa
cursor visible? no, position (0, 0), size 0x0, addr
0x, active? no
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]:
use=no, mode=0, scalers[1]: use=no, mode=0
--Plane id 27: type=PRI, crtc_pos=   0x   0,
crtc_size=2400x1600, src_pos=0.x0.,
src_size=2400.x1600., format=XR24 little-endian (0x34325258),
rotation=0 (0x0001)
--Plane id 30: type=OVL, crtc_pos=   0x   0, crtc_size=   0x
0, src_pos=0.x0., src_size=0.x0., format=N/A,
rotation=0 (0x0001)
--Plane id 33: type=CUR, crtc_pos=   0x   0, crtc_size=   0x
0, src_pos=0.x0., src_size=0.x0., format=N/A,
rotation=0 (0x0001)
underrun reporting: cpu=yes pch=yes
CRTC 46: pipe: B, active=no, (size=0x0), dither=no, bpp=0
underrun reporting: cpu=yes pch=yes
CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0
underrun reporting: cpu=yes pch=yes

Connector info
--
connector 58: type eDP-1, status: connected
name:
physical dimensions: 260x170mm
subpixel order: Unknown
CEA rev: 0
DPCD rev: 12
audio 

Re: [PATCH v2] drm/rockchip: Use an enum to identify Rockchip VOPs

[Kristian Høgsberg]

On Wed, Oct 18, 2017 at 5:49 PM, Mark yao  wrote:
> On 2017年10月19日 01:52, Brian Norris wrote:
>>
>> Hi Kristian,
>>
>> On Thu, Nov 03, 2016 at 12:46:48PM -0700, Kristian Högsberg wrote:
>>>
>>> We used to call drm_of_encoder_active_endpoint_id() from
>>> rockchip_dp_drm_encoder_atomic_check() to determine the endpoint for the
>>> active encoder. However, the encoder isn't necessarily active at this
>>> point or it may be connected to different crtc than what we're switching
>>> to. Instead, look at the crtc from the drm_crtc_state.  This fixes wrong
>>> colors when driving the eDP with the big VOP.  Further, we can identify
>>> the type of VOP we're dealing with by just putting a VOP id enum in the
>>> vop_data.
>
>
> Unfortunately, vop iomux and vop data are not one-to-one correspondence.
>
> Such as rk3288, vop big and vop little both use rk3288_vop data, if you use
> vop data id will not be able
> to distinguish between them.

What would you suggest then? We need this to be able to drive eDP from
the big VOP. We've been carrying this patch for quite a while and it
hasn't regressed neither rk3288 nor rk3399 boards.

Kristian

> Mark
>>>
>>>
>>> On way to test this is to use the modetest tool from libdrm:
>>>
>>>$ modetest -M rockchip -s 32@28:2400x1600
>>>
>>> which displays dark or black colors because we fail to look up the
>>> endpoint and use default 0 (which is ROCKCHIP_OUT_MODE_P888) for big
>>> VOP instead of RGB10 as required.
>>>
>>> For reference,
>>>
>>>$ modetest -M rockchip -s 32@25:2400x1600
>>>
>>> drives the eDP from little VOP and displays correctly.
>>>
>>> Signed-off-by: Kristian H. Kristensen 
>>> ---
>>> v2: Stripped chromeos annotations, fix compile errors for drivers I
>>> didn't
>>> compile when I first wrote the patch.
>>
>> Do you plan to fix the errors Guenter pointed out and resend? This is
>> still causing conflicts between our ChromeOS kernel trees and upstream.
>>
>> Also, please CC linux-rockchip on Rockchip-related patches. It's much
>> easier for me to find your work that way :)
>>
>> Brian
>>
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 45
>>> ++---
>>>   drivers/gpu/drm/rockchip/cdn-dp-core.c  | 19 +--
>>>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 12 ---
>>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 
>>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 10 ++
>>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  4 +++
>>>   6 files changed, 56 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index 558a3bc..9ae4a9c 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -196,14 +196,16 @@ static void rockchip_dp_drm_encoder_enable(struct
>>> drm_encoder *encoder)
>>> int ret;
>>> u32 val;
>>>   - ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node,
>>> encoder);
>>> -   if (ret < 0)
>>> -   return;
>>> -
>>> -   if (ret)
>>> +   switch (vop_get_crtc_vop_id(encoder->crtc)) {
>>> +   case RK3399_VOP_LIT:
>>> val = dp->data->lcdsel_lit;
>>> -   else
>>> +   break;
>>> +   case RK3399_VOP_BIG:
>>> val = dp->data->lcdsel_big;
>>> +   break;
>>> +   default:
>>> +   return;
>>> +   }
>>> dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
>>>   @@ -231,34 +233,23 @@ rockchip_dp_drm_encoder_atomic_check(struct
>>> drm_encoder *encoder,
>>>   struct drm_connector_state
>>> *conn_state)
>>>   {
>>> struct rockchip_crtc_state *s =
>>> to_rockchip_crtc_state(crtc_state);
>>> -   struct rockchip_dp_device *dp = to_dp(encoder);
>>> -   int ret;
>>>   - /*
>>> -* The hardware IC designed that VOP must output the RGB10 video
>>> -* format to eDP contoller, and if eDP panel only support RGB8,
>>> -* then eDP contoller should cut down the video data, not via VOP
>>> -* contoller, that's why we need to hardcode the VOP output mode
>>> -* to RGA10 here.
>>> -*/
>>> -
>>> -   ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node,
>>> encoder);
>>> -   if (ret < 0)
>>> -   return 0;
>>> -
>>> -   switch (dp->data->chip_type) {
>>> -   case RK3399_EDP:
>>> +   switch (vop_get_crtc_vop_id(crtc_state->crtc)) {
>>> +   case RK3399_VOP_LIT:
>>> /*
>>>  * For RK3399, VOP Lit must code the out mode to RGB888,
>>>  * VOP Big must code the out mode to RGB10.
>>>  */
>>> -   if (ret)
>>> -   s->output_mode = ROCKCHIP_OUT_MODE_P888;
>>> -   else
>>> -   

Re: [PATCH libdrm] modetest: Decode IN_FORMATS plane blob property

[Kristian Høgsberg]

On Thu, Sep 28, 2017 at 4:44 PM, Kristian H. Kristensen
 wrote:
> This teaches modetest about the new IN_FORMATS blob and decodes the
> blob to show supported formats and modifiers.
>
> Signed-off-by: Kristian H. Kristensen 

I went ahead and pushed this.

Kristian

> ---
>  tests/modetest/modetest.c | 86 
> +++
>  1 file changed, 86 insertions(+)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index b8891ff5..8ad4766f 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -251,6 +251,89 @@ static void dump_blob(struct device *dev, uint32_t 
> blob_id)
> drmModeFreePropertyBlob(blob);
>  }
>
> +static const char *modifier_to_string(uint64_t modifier)
> +{
> +   switch (modifier) {
> +   case DRM_FORMAT_MOD_INVALID:
> +   return "INVALID";
> +   case DRM_FORMAT_MOD_LINEAR:
> +   return "LINEAR";
> +   case I915_FORMAT_MOD_X_TILED:
> +   return "X_TILED";
> +   case I915_FORMAT_MOD_Y_TILED:
> +   return "Y_TILED";
> +   case I915_FORMAT_MOD_Yf_TILED:
> +   return "Yf_TILED";
> +   case I915_FORMAT_MOD_Y_TILED_CCS:
> +   return "Y_TILED_CCS";
> +   case I915_FORMAT_MOD_Yf_TILED_CCS:
> +   return "Yf_TILED_CCS";
> +   case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
> +   return "SAMSUNG_64_32_TILE";
> +   case DRM_FORMAT_MOD_VIVANTE_TILED:
> +   return "VIVANTE_TILED";
> +   case DRM_FORMAT_MOD_VIVANTE_SUPER_TILED:
> +   return "VIVANTE_SUPER_TILED";
> +   case DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED:
> +   return "VIVANTE_SPLIT_TILED";
> +   case DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED:
> +   return "VIVANTE_SPLIT_SUPER_TILED";
> +   case NV_FORMAT_MOD_TEGRA_TILED:
> +   return "MOD_TEGRA_TILED";
> +   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(0):
> +   return "MOD_TEGRA_16BX2_BLOCK(0)";
> +   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(1):
> +   return "MOD_TEGRA_16BX2_BLOCK(1)";
> +   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(2):
> +   return "MOD_TEGRA_16BX2_BLOCK(2)";
> +   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(3):
> +   return "MOD_TEGRA_16BX2_BLOCK(3)";
> +   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(4):
> +   return "MOD_TEGRA_16BX2_BLOCK(4)";
> +   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(5):
> +   return "MOD_TEGRA_16BX2_BLOCK(5)";
> +   case DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED:
> +   return "MOD_BROADCOM_VC4_T_TILED";
> +   default:
> +   return "(UNKNOWN MODIFIER)";
> +   }
> +}
> +
> +static void dump_in_formats(struct device *dev, uint32_t blob_id)
> +{
> +   uint32_t i, j;
> +   drmModePropertyBlobPtr blob;
> +   struct drm_format_modifier_blob *header;
> +   uint32_t *formats;
> +   struct drm_format_modifier *modifiers;
> +
> +   printf("\t\tin_formats blob decoded:\n");
> +   blob = drmModeGetPropertyBlob(dev->fd, blob_id);
> +   if (!blob) {
> +   printf("\n");
> +   return;
> +   }
> +
> +   header = blob->data;
> +   formats = (uint32_t *) ((char *) header + header->formats_offset);
> +   modifiers = (struct drm_format_modifier *)
> +   ((char *) header + header->modifiers_offset);
> +
> +   for (i = 0; i < header->count_formats; i++) {
> +   printf("\t\t\t");
> +   dump_fourcc(formats[i]);
> +   printf(": ");
> +   for (j = 0; j < header->count_modifiers; j++) {
> +   uint64_t mask = 1ULL << i;
> +   if (modifiers[j].formats & mask)
> +   printf(" %s", 
> modifier_to_string(modifiers[j].modifier));
> +   }
> +   printf("\n");
> +   }
> +
> +   drmModeFreePropertyBlob(blob);
> +}
> +
>  static void dump_prop(struct device *dev, drmModePropertyPtr prop,
>   uint32_t prop_id, uint64_t value)
>  {
> @@ -328,6 +411,9 @@ static void dump_prop(struct device *dev, 
> drmModePropertyPtr prop,
> printf(" %"PRId64"\n", value);
> else
> printf(" %"PRIu64"\n", value);
> +
> +   if (strcmp(prop->name, "IN_FORMATS") == 0)
> +   dump_in_formats(dev, value);
>  }
>
>  static void dump_connectors(struct device *dev)
> --
> 2.14.2.822.g60be5d43e6-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2] Header: Add rotation property fields

[Kristian Høgsberg]

On Tue, Apr 18, 2017 at 11:03 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 18 April 2017 at 18:38, Kristian Høgsberg <hoegsb...@gmail.com> wrote:
>> On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss <robert.f...@collabora.com> 
>> wrote:
>>> From: Sean Paul <seanp...@chromium.org>
>>>
>>> From drm_crtc.h, for use with the plane "rotation" property.
>>>
>>> Signed-off-by: Sean Paul <seanp...@chromium.org>
>>> Signed-off-by: Robert Foss <robert.f...@collabora.com>
>>> Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>
>>> ---
>>> Changes since v1:
>>>  - Added r-b
>>>
>>>  include/drm/drm.h | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/include/drm/drm.h b/include/drm/drm.h
>>> index 1e7a4bc7a505..656c90045161 100644
>>> --- a/include/drm/drm.h
>>> +++ b/include/drm/drm.h
>>> @@ -74,6 +74,14 @@ extern "C" {
>>>  #define _DRM_LOCK_IS_CONT(lock)   ((lock) & _DRM_LOCK_CONT)
>>>  #define _DRM_LOCKING_CONTEXT(lock) ((lock) & 
>>> ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
>>>
>>> +/* Rotation property bits */
>>> +#define DRM_ROTATE_0   0
>>> +#define DRM_ROTATE_90  1
>>> +#define DRM_ROTATE_180 2
>>> +#define DRM_ROTATE_270 3
>>> +#define DRM_REFLECT_X  4
>>> +#define DRM_REFLECT_Y  5
>>
>> As far as I understand the property mechanism, the numeric values
>> aren't actually ABI. The string names of the enum values are the ABI
>> and you're supposed to parse the enum info and discover the numerical
>> values. For example:
>> https://git.collabora.com/cgit/user/daniels/weston.git/tree/libweston/compositor-drm.c?h=wip/2017-03/atomic-v10-WIP#n570
>>
> Note sure I agree, yet then again my kernel experience is less than yours.
> Do check the following commit and feel free to search the ML thread
> that inspired it.

I haven't worked much with the property mechanism tbh, but I know
Daniel (Stone) jumped through all those hoops to avoid hard-coding the
enum values.

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/drm/drm_blend.h?id=226714dc7c6af6d0acee449eb2afce08d128edad
>
> Thanks
> Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2] Header: Add rotation property fields

[Kristian Høgsberg]

On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss  wrote:
> From: Sean Paul 
>
> From drm_crtc.h, for use with the plane "rotation" property.
>
> Signed-off-by: Sean Paul 
> Signed-off-by: Robert Foss 
> Reviewed-by: Sumit Semwal 
> ---
> Changes since v1:
>  - Added r-b
>
>  include/drm/drm.h | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/include/drm/drm.h b/include/drm/drm.h
> index 1e7a4bc7a505..656c90045161 100644
> --- a/include/drm/drm.h
> +++ b/include/drm/drm.h
> @@ -74,6 +74,14 @@ extern "C" {
>  #define _DRM_LOCK_IS_CONT(lock)   ((lock) & _DRM_LOCK_CONT)
>  #define _DRM_LOCKING_CONTEXT(lock) ((lock) & 
> ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
>
> +/* Rotation property bits */
> +#define DRM_ROTATE_0   0
> +#define DRM_ROTATE_90  1
> +#define DRM_ROTATE_180 2
> +#define DRM_ROTATE_270 3
> +#define DRM_REFLECT_X  4
> +#define DRM_REFLECT_Y  5

As far as I understand the property mechanism, the numeric values
aren't actually ABI. The string names of the enum values are the ABI
and you're supposed to parse the enum info and discover the numerical
values. For example:
https://git.collabora.com/cgit/user/daniels/weston.git/tree/libweston/compositor-drm.c?h=wip/2017-03/atomic-v10-WIP#n570

Kristian

> +
>  typedef unsigned int drm_context_t;
>  typedef unsigned int drm_drawable_t;
>  typedef unsigned int drm_magic_t;
> --
> 2.11.0.453.g787f75f05
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kristian Høgsberg]

On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca <jfons...@vmware.com> wrote:
> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>
>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfons...@vmware.com> wrote:
>>>
>>> On 23/03/17 01:38, Rob Clark wrote:
>>>>
>>>>
>>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <j...@jsg.id.au> wrote:
>>>>>
>>>>>
>>>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeuc...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> I guess I'm a little late to the party here, but I haven't had time
>>>>>>> to
>>>>>>> really let all of this sink in and actually look at meson.  It
>>>>>>> doesn't
>>>>>>> seem so bad with a quick look and I think I could probably sort it
>>>>>>> out
>>>>>>> when the time came, but there would still be a bit of a learning
>>>>>>> curve.  While that may not be a big deal at the micro level, I have
>>>>>>> concerns at the macro level.
>>>>>>>
>>>>>>> First, I'm concerned it may discourage casual developers and
>>>>>>> packagers.  autotools isn't great, but most people are familiar
>>>>>>> enough
>>>>>>> with it that they can get by.  Most people have enough knowledge of
>>>>>>> autotools that they can pretty easily diagnose a configuration based
>>>>>>> failure. There are a lot of resources for autotools.  I'm not sure
>>>>>>> that would be the case for meson.  Do we as a community feel we have
>>>>>>> enough meson experience to get people over the hump?  Anything that
>>>>>>> makes it harder for someone to try a new build or do a bisect is a
>>>>>>> big
>>>>>>> problem in my opinion.
>>>>>>
>>>>>>
>>>>>>
>>>>>> One of the things that's prompted this on our side (I've talked this
>>>>>> over with
>>>>>> other people at Intel before starting), was that clearly we *don't*
>>>>>> know
>>>>>> autotools well enough to get it right. Emil almost always finds cases
>>>>>> were we've
>>>>>> done things *almost*, but not quite right.
>>>>>>
>>>>>> For my part, it took me about 3 or 4 days of reading through the docs
>>>>>> and
>>>>>> writing the libdrm port to get it right, and a lot of that is just the
>>>>>> boilerplate of having ~8 drivers that all need basically the same
>>>>>> logic.
>>>>>>
>>>>>>> Next, my bigger concern is for distro and casual packagers and people
>>>>>>> that maintain large build systems with lots of existing custom
>>>>>>> configurations.  Changing from autotools would basically require many
>>>>>>> of these existing tools and systems to be rewritten and then deal
>>>>>>> with
>>>>>>> the debugging and fall out from that.  The potential decreased build
>>>>>>> time is a nice bonus, but frankly a lot of people/companies have
>>>>>>> years
>>>>>>> of investment in existing tools.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sure, but we're also not the only ones investigating meson. Gnome is
>>>>>> using it
>>>>>> already, libepoxy is using it, gstreamer is using it. There are
>>>>>> patches
>>>>>> for
>>>>>> weston (written by Daniel Stone) and libinput (written by Peter
>>>>>> Hutterer), there
>>>>>> are some other projects in the graphics sphere that people are working
>>>>>> on. So
>>>>>> even if we as a community decide that meson isn't for us, it's not
>>>>>> going
>>>>>> away.
>>>>>
>>>>>
>>>>>
>>>>> It is worth pointing out that it is currently required by no component
>>>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>>>> main

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kristian Høgsberg]

On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:
> On 23/03/17 01:38, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
>>>
>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:

 On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
 wrote:
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.


 One of the things that's prompted this on our side (I've talked this
 over with
 other people at Intel before starting), was that clearly we *don't* know
 autotools well enough to get it right. Emil almost always finds cases
 were we've
 done things *almost*, but not quite right.

 For my part, it took me about 3 or 4 days of reading through the docs
 and
 writing the libdrm port to get it right, and a lot of that is just the
 boilerplate of having ~8 drivers that all need basically the same logic.

> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that.  The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.


 Sure, but we're also not the only ones investigating meson. Gnome is
 using it
 already, libepoxy is using it, gstreamer is using it. There are patches
 for
 weston (written by Daniel Stone) and libinput (written by Peter
 Hutterer), there
 are some other projects in the graphics sphere that people are working
 on. So
 even if we as a community decide that meson isn't for us, it's not going
 away.
>>>
>>>
>>> It is worth pointing out that it is currently required by no component
>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>> maintainer
>>> on a new release and even then autoconf remains.
>>>
>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>> currently requires meson to build including gnome and gstreamer.
>>>
>>
>> but I guess that is conflating two completely different topics..
>> addition of meson and removal of autotools.  It is probably better
>> that we treat the topics separately.  I don't see any way that the two
>> can happen at the same time.
>>
>> The autotools build probably needs to remain for at least a couple
>> releases, and I certainly wouldn't mind if some of the other desktop
>> projects took the leap of dropping autotools first (at least then
>> various different "distro" consumers will have already dealt with how
>> to build meson packages)
>>
>> None of that blocks addition of a meson build system (or what various
>> developers use day to day)
>>
>> BR,
>> -R
>
>
> I tend to disagree.  While we can't avoid a transitory period, when we
> embark on another build system (Meson or something else) I think we should
> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
> existing build system, 2) and aim at migration quickly.
>
> Otherwise we'll just end up with yet another build system, yet another way
> builds can fail, with some developers stuck on old build systems because it
> works, or because the new build system quite doesn't work.
>
> And this is from (painful) experience.

I agree, adding a meson build system should aim to phase out one of
the other build systems within one or two release cycles. But (and
maybe that was Robs point) that doesn't have be autotools. What if we
phase out scons? It doesn't seem like anybody is really attached to it
and if meson is as good as scons on windows, then if nothing else
happens we end up with the same number of build systems. What's more
likely to happen is that a lot of Linux developers (and CI systems)
will also start 

[PATCH 1/2] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Kristian Høgsberg]

On Wed, Dec 21, 2016 at 7:42 AM Rob Clark  wrote:

> On Wed, Dec 21, 2016 at 4:19 AM, Ville Syrjälä
>  wrote:
> > On Wed, Dec 21, 2016 at 10:15:15AM +0100, Daniel Vetter wrote:
> >> On Tue, Dec 20, 2016 at 07:46:12PM -0500, Rob Clark wrote:
> >> > On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
> >> >  wrote:
> >> > > diff --git a/include/uapi/drm/drm_mode.h
> b/include/uapi/drm/drm_mode.h
> >> > > index ce7efe2..cea3de3 100644
> >> > > --- a/include/uapi/drm/drm_mode.h
> >> > > +++ b/include/uapi/drm/drm_mode.h
> >> > > @@ -209,6 +209,33 @@ struct drm_mode_get_plane {
> >> > > __u64 format_type_ptr;
> >> > >  };
> >> > >
> >> > > +struct drm_format_modifier {
> >> > > +   /* Bitmask of formats in get_plane format list this info
> >> > > +* applies to. */
> >> > > +   uint64_t formats;
> >> >
> >> > Hmm, this seems a bit clunky/brittle when you have a lot of supported
> >> > formats (esp. if format order changes or new formats are not added at
> >> > end).  I guess fine when you support a four or five different formats,
> >> > but I think you'll start to hate maintaining those tables on hw that
> >> > supports more.
> >> >
> >> > Also I guess it limits you to modifiers only with the first 64
> >> > formats.. maybe not a problem right away, but a quick look and drm/msm
> >> > is already at 23 formats (and there are probably some more it could
> >> > do.. without even starting to get into "exotic" float/etc formats and
> >> > whatever else might come in the future.
> >>
> >> Hm, I'd have said with max 23 currently used 64 is good enough.
> >> >
> >> > Not that I really have a better idea..  maybe just instead of
> >> > getplane2 we just add a querymodifiers ioctl (ie. fourcc in, list of
> >> > modifiers out), with the idea that userspace probably knows what
> >> > format/fourcc it wants to use, and only just cares about modifiers for
> >> > that particular fourcc..
> >>
> >> Could we do a table of tables instead, at least internally? So
> >>
> >> struct drm_format_support {
> >>   u64 modifiers;
> >>   u32 *formats;
> >> };
> >>
> >> And then supply an array of those? Maybe with some magic to convert it
> in
> >> the ioctl since the proposed ioctl struct is easier to transport to
> >> userspace. Could also switch over to terminating arrays with a final 0
> >> element (like with pci tables and everything else used in the kernel) to
> >> get rid of all those silly ARRAY_SIZE lines. Totalling up:
> >>
> >> u32 format_list_untiled[] = { RGBX, RGBA, 0 };
> >> u32 format_list_tiled[] = { RGBX, 0 };
> >>
> >> struct drm_format_support formats[] = {
> >>   { MODE_NODE, format_untiled },
> >>   { MODE_TILED, format_tiled },
> >>   { 0, NULL }
> >> };
> >>
> >> Not sure that's any better really.
> >
> > I think what we might want is:
> >
> > u32 formats[]
> > u64 modifiers[]
> > bool (*format_mod_supported)(u32 format, u64 modifier);
> >
> > The driver provides those, and the core will then just go through the
> > combinations and build up the masks. We could then also reuse that stuff
> > for addfb2 so that the core will call that same hook to check whether
> > the format+modifier is supported. That way the driver .fb_create() will
> > never see any unsupported combinations and we avoid having to duplicate
> > any logic there to see which hardware supports which formats.
> >
>
> I do like this for internal API better, rather than driver building up
> tables itself.
>

Yeah, I like Ville's suggestion too, I'll give it a try.

Kristian


> BR,
> -R
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm_fourcc: Document linear modifier

[Kristian Høgsberg]

Did we forget about this one? I guess I could commit it myself, but I'm not
sure which branch to push it too...

Kristian

On Wed, Nov 9, 2016 at 4:10 PM Kristian Kristensen 
wrote:

> On Wed, Nov 9, 2016 at 4:36 AM, Daniel Vetter 
> wrote:
>
> Not setting the fb modifiers flag is something different from setting
> the fb modifiers to 0 (which means explicitly linear). We kinda failed
> to document that properly. Spotted by Kristian.
>
> Cc: hoegsberg at google.com
> Signed-off-by: Daniel Vetter 
>
>
> Thanks, looks good.
>
> Reviewed-by: Kristian H. Kristensen 
>
>
> ---
>  include/uapi/drm/drm_fourcc.h | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index da49f69e4d7e..2fca7e1f6aab 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -172,6 +172,16 @@ extern "C" {
>   * authoritative source for all of these.
>   */
>
> +/*
> + * Linear Layout
> + *
> + * Just plain linear layout. Note that this is different from no
> specifying any
> + * modifier (e.g. not setting DRM_MODE_FB_MODIFIERS in the DRM_ADDFB2
> ioctl),
> + * which tells the driver to also take driver-internal information into
> account
> + * and so might actually result in a tiled framebuffer.
> + */
> +#define DRM_FORMAT_MOD_LINEAR  fourcc_mod_code(NONE, 0)
> +
>  /* Intel framebuffer modifiers */
>
>  /*
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm/rockchip: Use an enum to identify Rockchip VOPs

[Kristian Høgsberg]

On Thu, Nov 3, 2016 at 8:47 AM Sean Paul  wrote:

> On Tue, Nov 1, 2016 at 3:41 PM, Kristian H. Kristensen
>  wrote:
> > We used to call drm_of_encoder_active_endpoint_id() from
> > rockchip_dp_drm_encoder_atomic_check() to determine the endpoint for the
> > active encoder. However, the encoder isn't necessarily active at this
> > point or it may be connected to different crtc than what we're switching
> > to. Instead, look at the crtc from the drm_crtc_state.  This fixes wrong
> > colors when driving the eDP with the big VOP.  Further, we can identify
> > the type of VOP we're dealing with by just putting a VOP id enum in the
> > vop_data.
> >
> > On way to test this is to use the modetest tool from libdrm:
> >
> >   $ modetest -M rockchip -s 32 at 28:2400x1600
> >
> > which displays dark or black colors because we fail to look up the
> > endpoint and use default 0 (which is ROCKCHIP_OUT_MODE_P888) for big
> > VOP instead of RGB10 as required.
> >
> > For reference,
> >
> >   $ modetest -M rockchip -s 32 at 25:2400x1600
> >
> > drives the eDP from little VOP and displays correctly.
> >
> > BUG=chrome-os-partner:56407
> > TEST=verify 'modetest -M rockchip -s 32 at 28:2400x1600' looks right
> > Signed-off-by: Kristian H. Kristensen 
> > Change-Id: If5c5f36bcee09113008ee5155a13337f0e69371f
>
> Thanks for the patch, Kristian. In the future, can you please strip
> out BUG/TEST/Change-Id when you upstream? I think checkpatch will
> gently remind you of this as well.
>

Yup, I sent a v2 with the headers stripped and fixed the compile errors in
the
encoder modules I didn't initially compile.

Kristian


>
>
> > ---
> >  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 45
> ++---
> >  drivers/gpu/drm/rockchip/cdn-dp-core.c  | 19 +--
>
> cdn-dp isn't upstream yet (I need to get that posted), I'll work on
> this next week when I'm back from Plumbers. If that goes smoothly, I
> can push this patch on top.
>
> Reviewed-by: Sean Paul 
>
>
> >  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |  9 +++--
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 10 ++
> >  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  4 +++
> >  6 files changed, 54 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > index 558a3bc..9ae4a9c 100644
> > --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > @@ -196,14 +196,16 @@ static void rockchip_dp_drm_encoder_enable(struct
> drm_encoder *encoder)
> > int ret;
> > u32 val;
> >
> > -   ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node,
> encoder);
> > -   if (ret < 0)
> > -   return;
> > -
> > -   if (ret)
> > +   switch (vop_get_crtc_vop_id(encoder->crtc)) {
> > +   case RK3399_VOP_LIT:
> > val = dp->data->lcdsel_lit;
> > -   else
> > +   break;
> > +   case RK3399_VOP_BIG:
> > val = dp->data->lcdsel_big;
> > +   break;
> > +   default:
> > +   return;
> > +   }
> >
> > dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
> >
> > @@ -231,34 +233,23 @@ rockchip_dp_drm_encoder_atomic_check(struct
> drm_encoder *encoder,
> >   struct drm_connector_state
> *conn_state)
> >  {
> > struct rockchip_crtc_state *s =
> to_rockchip_crtc_state(crtc_state);
> > -   struct rockchip_dp_device *dp = to_dp(encoder);
> > -   int ret;
> >
> > -   /*
> > -* The hardware IC designed that VOP must output the RGB10 video
> > -* format to eDP contoller, and if eDP panel only support RGB8,
> > -* then eDP contoller should cut down the video data, not via VOP
> > -* contoller, that's why we need to hardcode the VOP output mode
> > -* to RGA10 here.
> > -*/
> > -
> > -   ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node,
> encoder);
> > -   if (ret < 0)
> > -   return 0;
> > -
> > -   switch (dp->data->chip_type) {
> > -   case RK3399_EDP:
> > +   switch (vop_get_crtc_vop_id(crtc_state->crtc)) {
> > +   case RK3399_VOP_LIT:
> > /*
> >  * For RK3399, VOP Lit must code the out mode to RGB888,
> >  * VOP Big must code the out mode to RGB10.
> >  */
> > -   if (ret)
> > -   s->output_mode = ROCKCHIP_OUT_MODE_P888;
> > -   else
> > -   s->output_mode = ROCKCHIP_OUT_MODE_;
> > +   s->output_mode = ROCKCHIP_OUT_MODE_P888;
> > break;
> > -
> > default:
> > +   /*
> > +* The hardware IC designed that VOP must output the
> RGB10 video
> > +* format 

[PATCH] Add drmModeAddFB2WithModifiers() which takes format modifiers

[Kristian Høgsberg]

On Tue, Sep 13, 2016 at 3:59 PM, Rob Clark  wrote:
> On Tue, Sep 13, 2016 at 6:07 PM, Kristian H. Kristensen
>  wrote:
>> The only current user of this open codes the ioctl. Let's add an entry
>> point for this to libdrm.
>>
>> Signed-off-by: Kristian H. Kristensen 
>> ---
>>  xf86drmMode.c | 21 +
>>  xf86drmMode.h |  7 +++
>>  2 files changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/xf86drmMode.c b/xf86drmMode.c
>> index f7b5948..2907c5c 100644
>> --- a/xf86drmMode.c
>> +++ b/xf86drmMode.c
>> @@ -270,10 +270,10 @@ int drmModeAddFB(int fd, uint32_t width, uint32_t 
>> height, uint8_t depth,
>> return 0;
>>  }
>>
>> -int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
>> - uint32_t pixel_format, uint32_t bo_handles[4],
>> - uint32_t pitches[4], uint32_t offsets[4],
>> - uint32_t *buf_id, uint32_t flags)
>> +int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
>> +   uint32_t pixel_format, uint32_t 
>> bo_handles[4],
>> +   uint32_t pitches[4], uint32_t offsets[4],
>> +   uint64_t modifier[4], uint32_t *buf_id, 
>> uint32_t flags)
>>  {
>> struct drm_mode_fb_cmd2 f;
>> int ret;
>> @@ -286,6 +286,8 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t 
>> height,
>> memcpy(f.handles, bo_handles, 4 * sizeof(bo_handles[0]));
>> memcpy(f.pitches, pitches, 4 * sizeof(pitches[0]));
>> memcpy(f.offsets, offsets, 4 * sizeof(offsets[0]));
>> +if (modifier)
>> +   memcpy(f.modifier, modifier, 4 * sizeof(modifier[0]));
>
> I can't quite tell if it is my email client or not, but the
> whitespace/indentation here and below in drmModeAddFB2() looks funny..
> other than that (and with that potentially fixed if needed), lgtm

Ah, yup, there's some broken whitespace there, will fix.

> Reviewed-by: Rob Clark 

Thanks!

>
>> if ((ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ADDFB2, )))
>> return ret;
>> @@ -294,6 +296,17 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t 
>> height,
>> return 0;
>>  }
>>
>> +int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
>> +  uint32_t pixel_format, uint32_t bo_handles[4],
>> +  uint32_t pitches[4], uint32_t offsets[4],
>> +  uint32_t *buf_id, uint32_t flags)
>> +{
>> +  return drmModeAddFB2WithModifiers(fd, width, height,
>> +pixel_format, bo_handles,
>> +pitches, offsets, NULL,
>> +buf_id, flags);
>> +}
>> +
>>  int drmModeRmFB(int fd, uint32_t bufferId)
>>  {
>> return DRM_IOCTL(fd, DRM_IOCTL_MODE_RMFB, );
>> diff --git a/xf86drmMode.h b/xf86drmMode.h
>> index 4de7bbb..02190ea 100644
>> --- a/xf86drmMode.h
>> +++ b/xf86drmMode.h
>> @@ -369,6 +369,13 @@ extern int drmModeAddFB2(int fd, uint32_t width, 
>> uint32_t height,
>>  uint32_t pixel_format, uint32_t bo_handles[4],
>>  uint32_t pitches[4], uint32_t offsets[4],
>>  uint32_t *buf_id, uint32_t flags);
>> +
>> +/* ...with format modifiers */
>> +int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
>> +   uint32_t pixel_format, uint32_t 
>> bo_handles[4],
>> +   uint32_t pitches[4], uint32_t offsets[4],
>> +   uint64_t modifier[4], uint32_t *buf_id, 
>> uint32_t flags);
>> +
>>  /**
>>   * Destroies the given framebuffer.
>>   */
>> --
>> 2.8.0.rc3.226.g39d4020
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vgem: Allow root to inject hanging fences onto dmabufs

[Kristian Høgsberg]

Why is this useful if only root can use it?

Kristian

On Wed, Jul 20, 2016 at 12:39 PM, Chris Wilson  
wrote:
> When performing driver testing, one factor we want to test is how we
> handle a foreign fence that is never signaled. We can wait on that fence
> indefinitely, in which case the driver appears hung, or we can take some
> remedial action (with risks regarding the state of any shared content).
> Whatever the action choosen by the driver, in order to perform the test
> we want to disable the safety feature of vgem fence (which is then used
> to test implicit dma-buf fencing). This is regarded as a highly
> dangerous feature and so hidden behind an expert config option and only
> available to root when enabled.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/Kconfig   | 13 +
>  drivers/gpu/drm/vgem/vgem_fence.c | 14 --
>  include/uapi/drm/vgem_drm.h   |  1 +
>  3 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index fc357319de35..2b25bc38fad2 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -228,6 +228,19 @@ config DRM_VGEM
>   as used by Mesa's software renderer for enhanced performance.
>   If M is selected the module will be called vgem.
>
> +config DRM_VGEM_FENCE_HANG
> +   bool "Enable fence hang testing (DANGEROUS)"
> +   depends on DRM_VGEM
> +   depends on EXPERT
> +   depends on !COMPILE_TEST
> +   default n
> +   help
> + Enables support for root to use indefinite fences.
> + Do not enable this unless you are testing DRM drivers.
> +
> + Recommended for driver developers only.
> +
> + If in doubt, say "N".
>
>  source "drivers/gpu/drm/exynos/Kconfig"
>
> diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
> b/drivers/gpu/drm/vgem/vgem_fence.c
> index 5c57c1ffa1f9..91d3d75fc9c5 100644
> --- a/drivers/gpu/drm/vgem/vgem_fence.c
> +++ b/drivers/gpu/drm/vgem/vgem_fence.c
> @@ -107,7 +107,8 @@ static struct fence *vgem_fence_create(struct vgem_file 
> *vfile,
> setup_timer(>timer, vgem_fence_timeout, (unsigned long)fence);
>
> /* We force the fence to expire within 10s to prevent driver hangs */
> -   mod_timer(>timer, jiffies + VGEM_FENCE_TIMEOUT);
> +   if ((flags & VGEM_FENCE_NOTIMEOUT) == 0)
> +   mod_timer(>timer, jiffies + VGEM_FENCE_TIMEOUT);
>
> return >base;
>  }
> @@ -160,9 +161,18 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
> struct fence *fence;
> int ret;
>
> -   if (arg->flags & ~VGEM_FENCE_WRITE)
> +   if (arg->flags & ~(VGEM_FENCE_WRITE | VGEM_FENCE_NOTIMEOUT))
> return -EINVAL;
>
> +   if (arg->flags & VGEM_FENCE_NOTIMEOUT) {
> +   if (config_enabled(CONFIG_DRM_VGEM_FENCE_HANG)) {
> +   if (!capable(CAP_SYS_ADMIN))
> +   return -EPERM;
> +   } else {
> +   return -EINVAL;
> +   }
> +   }
> +
> if (arg->pad)
> return -EINVAL;
>
> diff --git a/include/uapi/drm/vgem_drm.h b/include/uapi/drm/vgem_drm.h
> index bf66f5db6da8..55fd08750773 100644
> --- a/include/uapi/drm/vgem_drm.h
> +++ b/include/uapi/drm/vgem_drm.h
> @@ -46,6 +46,7 @@ struct drm_vgem_fence_attach {
> __u32 handle;
> __u32 flags;
>  #define VGEM_FENCE_WRITE   0x1
> +#define VGEM_FENCE_NOTIMEOUT   0x2
> __u32 out_fence;
> __u32 pad;
>  };
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

Kristian Høgsberg  writes:

> "Song, Ruiling"  writes:
>
>>> -Original Message-
>>> From: hoegsberg at gmail.com [mailto:hoegsberg at gmail.com] On Behalf Of
>>> Kristian H?gsberg
>>> Sent: Monday, December 14, 2015 1:34 PM
>>> To: Song, Ruiling 
>>> Cc: Winiarski, Michal ; intel-
>>> gfx at lists.freedesktop.org; mesa-dev at lists.freedesktop.org; Ben 
>>> Widawsky
>>> ; dri-devel at lists.freedesktop.org
>>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>>> 
>>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
>>> wrote:
>>> >> -Original Message-
>>> >> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On
>>> Behalf
>>> >> Of Micha? Winiarski
>>> >> Sent: Wednesday, September 9, 2015 10:07 PM
>>> >> To: intel-gfx at lists.freedesktop.org
>>> >> Cc: Ben Widawsky ; dri-
>>> devel at lists.freedesktop.org;
>>> >> mesa-dev at lists.freedesktop.org
>>> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>>> >>
>>> >> Softpin allows userspace to take greater control of GPU virtual address
>>> >> space and eliminates the need of relocations. It can also be used to
>>> >> mirror addresses between GPU and CPU (shared virtual memory).
>>> >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
>>> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>>> >> created. Self-relocs don't make any sense for softpinned objects and can
>>> >> indicate a programming errors, thus are forbidden. Softpinned objects
>>> >> are marked by asterisk in debug dumps.
>>> >>
>>> >> Cc: Thomas Daniel 
>>> >> Cc: Kristian Høgsberg 
>>> >> Cc: Zou Nanhai 
>>> >> Cc: Michel Thierry 
>>> >> Cc: Ben Widawsky 
>>> >> Cc: Chris Wilson 
>>> >> Signed-off-by: Michał Winiarski 
>>> >> ---
>>> >>  include/drm/i915_drm.h|   4 +-
>>> >>  intel/intel_bufmgr.c  |   9 +++
>>> >>  intel/intel_bufmgr.h  |   1 +
>>> >>  intel/intel_bufmgr_gem.c  | 176
>>> >> --
>>> >>  intel/intel_bufmgr_priv.h |   7 ++
>>> >>  5 files changed, 173 insertions(+), 24 deletions(-)
>>> >
>>> > Will anybody help to push the patch to libdrm? Beignet highly depend on
>>> this to implement ocl2.0 svm.
>>> 
>>> Is the kernel patch upstream?
>>
>> Yes, the kernel patch already merged, see:
>> http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>>
>> I find below line of code in libdrm does not match the kernel version. The 
>> kernel patch defined as:
>> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
>
> I have the two 48 bit patches merge here. I'll pull in Michał's patch,
> update the kernel header and  then push it all.

All pushed now.

Kristian

>> Hello Michal,
>>
>> Could you help to rebase the patch against:
>> [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in  i915
>> I think we need both 48bit & softpin in libdrm.
>>
>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> index ded43b1..2b99fc6 100644
>> --- a/include/drm/i915_drm.h
>> +++ b/include/drm/i915_drm.h
>> @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>>  #define I915_PARAM_REVISION  32
>>  #define I915_PARAM_SUBSLICE_TOTAL33
>>  #define I915_PARAM_EU_TOTAL  34
>> +#define I915_PARAM_HAS_EXEC_SOFTPIN  37
>>  
>>  typedef struct drm_i915_getparam {
>>  int param;
>> @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>>  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>>  #define EXEC_OBJECT_NEEDS_GTT   (1<<1)
>>  #define EXEC_OBJECT_WRITE   (1<<2)
>> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
>> +#define EXEC_OBJECT_PINNED  (1<<3)
>> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
>>  __u64 flags;
>>  

[Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

"Song, Ruiling"  writes:

>> -Original Message-
>> From: hoegsberg at gmail.com [mailto:hoegsberg at gmail.com] On Behalf Of
>> Kristian H?gsberg
>> Sent: Monday, December 14, 2015 1:34 PM
>> To: Song, Ruiling 
>> Cc: Winiarski, Michal ; intel-
>> gfx at lists.freedesktop.org; mesa-dev at lists.freedesktop.org; Ben Widawsky
>> ; dri-devel at lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> 
>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
>> wrote:
>> >> -Original Message-
>> >> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On
>> Behalf
>> >> Of Micha? Winiarski
>> >> Sent: Wednesday, September 9, 2015 10:07 PM
>> >> To: intel-gfx at lists.freedesktop.org
>> >> Cc: Ben Widawsky ; dri-
>> devel at lists.freedesktop.org;
>> >> mesa-dev at lists.freedesktop.org
>> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> >>
>> >> Softpin allows userspace to take greater control of GPU virtual address
>> >> space and eliminates the need of relocations. It can also be used to
>> >> mirror addresses between GPU and CPU (shared virtual memory).
>> >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
>> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>> >> created. Self-relocs don't make any sense for softpinned objects and can
>> >> indicate a programming errors, thus are forbidden. Softpinned objects
>> >> are marked by asterisk in debug dumps.
>> >>
>> >> Cc: Thomas Daniel 
>> >> Cc: Kristian Høgsberg 
>> >> Cc: Zou Nanhai 
>> >> Cc: Michel Thierry 
>> >> Cc: Ben Widawsky 
>> >> Cc: Chris Wilson 
>> >> Signed-off-by: Michał Winiarski 
>> >> ---
>> >>  include/drm/i915_drm.h|   4 +-
>> >>  intel/intel_bufmgr.c  |   9 +++
>> >>  intel/intel_bufmgr.h  |   1 +
>> >>  intel/intel_bufmgr_gem.c  | 176
>> >> --
>> >>  intel/intel_bufmgr_priv.h |   7 ++
>> >>  5 files changed, 173 insertions(+), 24 deletions(-)
>> >
>> > Will anybody help to push the patch to libdrm? Beignet highly depend on
>> this to implement ocl2.0 svm.
>> 
>> Is the kernel patch upstream?
>
> Yes, the kernel patch already merged, see:
> http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>
> I find below line of code in libdrm does not match the kernel version. The 
> kernel patch defined as:
> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).

I have the two 48 bit patches merge here. I'll pull in Michał's patch,
update the kernel header and  then push it all.

Kristian

> Hello Michal,
>
> Could you help to rebase the patch against:
> [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in   i915
> I think we need both 48bit & softpin in libdrm.
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index ded43b1..2b99fc6 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_REVISION  32
>  #define I915_PARAM_SUBSLICE_TOTAL 33
>  #define I915_PARAM_EU_TOTAL   34
> +#define I915_PARAM_HAS_EXEC_SOFTPIN   37
>  
>  typedef struct drm_i915_getparam {
>   int param;
> @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>  #define EXEC_OBJECT_NEEDS_GTT(1<<1)
>  #define EXEC_OBJECT_WRITE(1<<2)
> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> +#define EXEC_OBJECT_PINNED   (1<<3)
> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
>   __u64 flags;
>  

[Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

"Song, Ruiling"  writes:

>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Monday, December 14, 2015 4:28 PM
>> To: Song, Ruiling 
>> Cc: krh at bitplanet.net; Winiarski, Michal ;
>> mesa-dev at lists.freedesktop.org; intel-gfx at lists.freedesktop.org; Ben
>> Widawsky ; dri-devel at lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> 
>> On Mon, Dec 14, 2015 at 07:24:29AM +, Song, Ruiling wrote:
>> >
>> >
>> > > -Original Message-
>> > > From: hoegsberg at gmail.com [mailto:hoegsberg at gmail.com] On Behalf
>> Of
>> > > Kristian H?gsberg
>> > > Sent: Monday, December 14, 2015 1:34 PM
>> > > To: Song, Ruiling 
>> > > Cc: Winiarski, Michal ; intel-
>> > > gfx at lists.freedesktop.org; mesa-dev at lists.freedesktop.org; Ben
>> Widawsky
>> > > ; dri-devel at lists.freedesktop.org
>> > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > >
>> > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling > > > intel.com>
>> > > wrote:
>> > > >> -Original Message-
>> > > >> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On
>> > > Behalf
>> > > >> Of Micha? Winiarski
>> > > >> Sent: Wednesday, September 9, 2015 10:07 PM
>> > > >> To: intel-gfx at lists.freedesktop.org
>> > > >> Cc: Ben Widawsky ; dri-
>> > > devel at lists.freedesktop.org;
>> > > >> mesa-dev at lists.freedesktop.org
>> > > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > > >>
>> > > >> Softpin allows userspace to take greater control of GPU virtual 
>> > > >> address
>> > > >> space and eliminates the need of relocations. It can also be used to
>> > > >> mirror addresses between GPU and CPU (shared virtual memory).
>> > > >> Calls to drm_intel_bo_emit_reloc are still required to build the list 
>> > > >> of
>> > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>> > > >> created. Self-relocs don't make any sense for softpinned objects and
>> can
>> > > >> indicate a programming errors, thus are forbidden. Softpinned objects
>> > > >> are marked by asterisk in debug dumps.
>> > > >>
>> > > >> Cc: Thomas Daniel 
>> > > >> Cc: Kristian Høgsberg 
>> > > >> Cc: Zou Nanhai 
>> > > >> Cc: Michel Thierry 
>> > > >> Cc: Ben Widawsky 
>> > > >> Cc: Chris Wilson 
>> > > >> Signed-off-by: Michał Winiarski 
>> > > >> ---
>> > > >>  include/drm/i915_drm.h|   4 +-
>> > > >>  intel/intel_bufmgr.c  |   9 +++
>> > > >>  intel/intel_bufmgr.h  |   1 +
>> > > >>  intel/intel_bufmgr_gem.c  | 176
>> > > >> --
>> > > >>  intel/intel_bufmgr_priv.h |   7 ++
>> > > >>  5 files changed, 173 insertions(+), 24 deletions(-)
>> > > >
>> > > > Will anybody help to push the patch to libdrm? Beignet highly depend
>> on
>> > > this to implement ocl2.0 svm.
>> > >
>> > > Is the kernel patch upstream?
>> >
>> > Yes, the kernel patch already merged, see:
>> > http://cgit.freedesktop.org/drm-
>> intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>> >
>> > I find below line of code in libdrm does not match the kernel version. The
>> kernel patch defined as:
>> > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
>> 
>> Please always regenerate the entire headers from the kernel sources using
>> 
>> $ make headers_install
>> 
>> Then copy the headers from the kernel's usr/include/drm to libdrm. Never
>> patch i915_drm.h manually.
>
> Thanks for the info. But the problem is libdrm still tracks such kind of 
> header files.
> Should this kind of header file be removed from libdrm? Or any document in 
> libdrm to make this explicit?

The motivation is that compiling libdrm should be independent of
kernel headers on the system. You could probably get away with requiring
some recent enough linux-headers pkg or something, but in the end this
seemed more pragmatic.

Kristian

> Thanks!
> Ruiling
>  
>> Thanks, Daniel
>> 
>> >
>> > Hello Michal,
>> >
>> > Could you help to rebase the patch against:
>> > [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in
>> > i915
>> > I think we need both 48bit & softpin in libdrm.
>> >
>> > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> > index ded43b1..2b99fc6 100644
>> > --- a/include/drm/i915_drm.h
>> > +++ b/include/drm/i915_drm.h
>> > @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>> >  #define I915_PARAM_REVISION  32
>> >  #define I915_PARAM_SUBSLICE_TOTAL  33
>> >  #define I915_PARAM_EU_TOTAL34
>> > +#define I915_PARAM_HAS_EXEC_SOFTPIN37
>> >
>> >  typedef struct drm_i915_getparam {
>> >int param;
>> > @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>> >  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>> >  #define EXEC_OBJECT_NEEDS_GTT (1<<1)
>> >  #define EXEC_OBJECT_WRITE (1<<2)
>> > -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
>> > 

[Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling  
wrote:
>> -Original Message-
>> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf
>> Of Micha? Winiarski
>> Sent: Wednesday, September 9, 2015 10:07 PM
>> To: intel-gfx at lists.freedesktop.org
>> Cc: Ben Widawsky ; dri-devel at lists.freedesktop.org;
>> mesa-dev at lists.freedesktop.org
>> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>>
>> Softpin allows userspace to take greater control of GPU virtual address
>> space and eliminates the need of relocations. It can also be used to
>> mirror addresses between GPU and CPU (shared virtual memory).
>> Calls to drm_intel_bo_emit_reloc are still required to build the list of
>> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>> created. Self-relocs don't make any sense for softpinned objects and can
>> indicate a programming errors, thus are forbidden. Softpinned objects
>> are marked by asterisk in debug dumps.
>>
>> Cc: Thomas Daniel 
>> Cc: Kristian Høgsberg 
>> Cc: Zou Nanhai 
>> Cc: Michel Thierry 
>> Cc: Ben Widawsky 
>> Cc: Chris Wilson 
>> Signed-off-by: Michał Winiarski 
>> ---
>>  include/drm/i915_drm.h|   4 +-
>>  intel/intel_bufmgr.c  |   9 +++
>>  intel/intel_bufmgr.h  |   1 +
>>  intel/intel_bufmgr_gem.c  | 176
>> --
>>  intel/intel_bufmgr_priv.h |   7 ++
>>  5 files changed, 173 insertions(+), 24 deletions(-)
>
> Will anybody help to push the patch to libdrm? Beignet highly depend on this 
> to implement ocl2.0 svm.

Is the kernel patch upstream?

> Thanks!
> Ruiling
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Mesa-dev] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

[Kristian Høgsberg]

On Fri, Dec 4, 2015 at 6:24 AM, Michel Thierry  
wrote:
> On 11/18/2015 10:53 PM, Kristian Høgsberg wrote:
>>
>> On Wed, Oct 14, 2015 at 5:11 AM, Michel Thierry
>>  wrote:
>>>
>>> On 10/14/2015 8:19 AM, Daniel Vetter wrote:


 On Tue, Oct 13, 2015 at 02:51:36PM -0700, Kristian Høgsberg wrote:
>
>
> On Tue, Oct 13, 2015 at 7:55 AM, Michel Thierry
>  wrote:
>>
>>
>> On 10/13/2015 3:13 PM, Emil Velikov wrote:
>>>
>>>
>>>
>>> On 13 October 2015 at 13:16, Michel Thierry
>>> 
>>> wrote:



 On 10/6/2015 2:12 PM, Michel Thierry wrote:
>
>
>
>
> On 10/5/2015 7:06 PM, Kristian Høgsberg wrote:
>>
>>
>>
>>
>> On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry
>>  wrote:
>>>
>>>
>>>
>>>
>>> On 9/14/2015 2:54 PM, Michał Winiarski wrote:





 On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:
>
>
>
>
>
> Gen8+ supports 48-bit virtual addresses, but some objects must
> always be
> allocated inside the 32-bit address range.
>
> In specific, any resource used with flat/heapless
> (0x-0xf000)
> General State Heap (GSH) or Instruction State Heap (ISH) must
> be
> in
> a
> 32-bit range, because the General State Offset and Instruction
> State
> Offset
> are limited to 32-bits.
>
> The i915 driver has been modified to provide a flag to set when
> the
> 4GB
> limit is not necessary in a given bo
> (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
> 48-bit range will only be used when explicitly requested.
>
> Callers to the existing drm_intel_bo_emit_reloc function should
> set
> the
> use_48b_address_range flag beforehand, in order to use full
> ppgtt
> range.
>
> v2: Make set/clear functions nops on pre-gen8 platforms, and
> use
> them
>  internally in emit_reloc functions (Ben)
>  s/48BADDRESS/48B_ADDRESS/ (Dave)
> v3: Keep set/clear functions internal, no-one needs to use them
> directly.
> v4: Don't set 48bit-support flag in emit reloc, check for ppgtt
> type
>  before enabling set/clear function, print full offsets
> in
> debug
>  statements, using port of lower_32_bits and
> upper_32_bits
> from linux
>  kernel (Michał)
>
> References:
>
>
>
> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
> Cc: Ben Widawsky 
> Cc: Michał Winiarski 






 +Kristian

 LGTM.
 Acked-by: Michał Winiarski 

> Signed-off-by: Michel Thierry 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi Kristian,
>>>
>>> More comments on this?
>>> I've resent the mesa patch with the last changes
>>>
>>>
>>>
>>>
>>> (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).
>>>
>>>
>>> Michał has agreed with the interface and will use it for his
>>> work.
>>> If mesa doesn't plan to use this for now, it's ok. The kernel
>>> changes
>>> have
>>> been done to prevent any regressions when the support 48-bit flag
>>> is
>>> not
>>> set.
>>
>>
>>
>>
>>
>> I didn't get any replies to my last comments on this:
>>
>>
>>
>> http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html
>>
>> Basically, I tried explicitly placing buffers above 8G and didn't
>> see
>> the HW problem described (ie it all worked fine).  I still think
>> there's some confusion as to what the W/A is about.
>>
>> Here's my take: the W/A is a SW-only workaround to handle the
>> cases
>> where a driver uses heapless and 48-bit ppgtt. The problem is that
>> the
>> heaps are limited to 4G but with 48bit ppgtt a buffer can be
>> placed
>> anywhere it the 48 bit address space. If that happens it's

[Mesa-dev] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

[Kristian Høgsberg]

On Wed, Oct 14, 2015 at 5:11 AM, Michel Thierry
 wrote:
> On 10/14/2015 8:19 AM, Daniel Vetter wrote:
>>
>> On Tue, Oct 13, 2015 at 02:51:36PM -0700, Kristian Høgsberg wrote:
>>>
>>> On Tue, Oct 13, 2015 at 7:55 AM, Michel Thierry
>>>  wrote:

 On 10/13/2015 3:13 PM, Emil Velikov wrote:
>
>
> On 13 October 2015 at 13:16, Michel Thierry 
> wrote:
>>
>>
>> On 10/6/2015 2:12 PM, Michel Thierry wrote:
>>>
>>>
>>>
>>> On 10/5/2015 7:06 PM, Kristian Høgsberg wrote:



 On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry
  wrote:
>
>
>
> On 9/14/2015 2:54 PM, Michał Winiarski wrote:
>>
>>
>>
>>
>> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:
>>>
>>>
>>>
>>>
>>> Gen8+ supports 48-bit virtual addresses, but some objects must
>>> always be
>>> allocated inside the 32-bit address range.
>>>
>>> In specific, any resource used with flat/heapless
>>> (0x-0xf000)
>>> General State Heap (GSH) or Instruction State Heap (ISH) must be
>>> in
>>> a
>>> 32-bit range, because the General State Offset and Instruction
>>> State
>>> Offset
>>> are limited to 32-bits.
>>>
>>> The i915 driver has been modified to provide a flag to set when
>>> the
>>> 4GB
>>> limit is not necessary in a given bo
>>> (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
>>> 48-bit range will only be used when explicitly requested.
>>>
>>> Callers to the existing drm_intel_bo_emit_reloc function should
>>> set
>>> the
>>> use_48b_address_range flag beforehand, in order to use full ppgtt
>>> range.
>>>
>>> v2: Make set/clear functions nops on pre-gen8 platforms, and use
>>> them
>>> internally in emit_reloc functions (Ben)
>>> s/48BADDRESS/48B_ADDRESS/ (Dave)
>>> v3: Keep set/clear functions internal, no-one needs to use them
>>> directly.
>>> v4: Don't set 48bit-support flag in emit reloc, check for ppgtt
>>> type
>>> before enabling set/clear function, print full offsets in
>>> debug
>>> statements, using port of lower_32_bits and upper_32_bits
>>> from linux
>>> kernel (Michał)
>>>
>>> References:
>>>
>>>
>>> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
>>> Cc: Ben Widawsky 
>>> Cc: Michał Winiarski 
>>
>>
>>
>>
>>
>> +Kristian
>>
>> LGTM.
>> Acked-by: Michał Winiarski 
>>
>>> Signed-off-by: Michel Thierry 
>
>
>
>
>
>
> Hi Kristian,
>
> More comments on this?
> I've resent the mesa patch with the last changes
>
>
>
> (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).
>
>
> Michał has agreed with the interface and will use it for his work.
> If mesa doesn't plan to use this for now, it's ok. The kernel
> changes
> have
> been done to prevent any regressions when the support 48-bit flag
> is
> not
> set.




 I didn't get any replies to my last comments on this:


 http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html

 Basically, I tried explicitly placing buffers above 8G and didn't
 see
 the HW problem described (ie it all worked fine).  I still think
 there's some confusion as to what the W/A is about.

 Here's my take: the W/A is a SW-only workaround to handle the cases
 where a driver uses heapless and 48-bit ppgtt. The problem is that
 the
 heaps are limited to 4G but with 48bit ppgtt a buffer can be placed
 anywhere it the 48 bit address space. If that happens it's
 consideredd
 out-of-bounds for the heap and access fails. To prevent this we need
 to make sure the bos we address in a heapless fashion are placed
 below
 4g.

 For mesa, we only configure general state base as heap-less, which
 affects scratch bos. What this boils down to is that we need the 4G
 restriction only for the scratch bos set up on 3DSTATE_VS,
 3DSTATE_GS
 and 3DSTATE_PS (and tesselation stage eventually). Look for the
 OUT_RELOC64 for stage->scratch_bo in gen8_vs_state.c,
 gen8_gs_state.c
 and gen8_ps_state.c
>>>
>>>
>>>
>>>
>>> I 

[PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

[Kristian Høgsberg]

On Tue, Oct 13, 2015 at 7:55 AM, Michel Thierry
 wrote:
> On 10/13/2015 3:13 PM, Emil Velikov wrote:
>>
>> On 13 October 2015 at 13:16, Michel Thierry 
>> wrote:
>>>
>>> On 10/6/2015 2:12 PM, Michel Thierry wrote:


 On 10/5/2015 7:06 PM, Kristian Høgsberg wrote:
>
>
> On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry
>  wrote:
>>
>>
>> On 9/14/2015 2:54 PM, Michał Winiarski wrote:
>>>
>>>
>>>
>>> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:



 Gen8+ supports 48-bit virtual addresses, but some objects must
 always be
 allocated inside the 32-bit address range.

 In specific, any resource used with flat/heapless
 (0x-0xf000)
 General State Heap (GSH) or Instruction State Heap (ISH) must be in
 a
 32-bit range, because the General State Offset and Instruction State
 Offset
 are limited to 32-bits.

 The i915 driver has been modified to provide a flag to set when the
 4GB
 limit is not necessary in a given bo
 (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
 48-bit range will only be used when explicitly requested.

 Callers to the existing drm_intel_bo_emit_reloc function should set
 the
 use_48b_address_range flag beforehand, in order to use full ppgtt
 range.

 v2: Make set/clear functions nops on pre-gen8 platforms, and use
 them
internally in emit_reloc functions (Ben)
s/48BADDRESS/48B_ADDRESS/ (Dave)
 v3: Keep set/clear functions internal, no-one needs to use them
 directly.
 v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
before enabling set/clear function, print full offsets in
 debug
statements, using port of lower_32_bits and upper_32_bits
 from linux
kernel (Michał)

 References:

 http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
 Cc: Ben Widawsky 
 Cc: Michał Winiarski 
>>>
>>>
>>>
>>>
>>> +Kristian
>>>
>>> LGTM.
>>> Acked-by: Michał Winiarski 
>>>
 Signed-off-by: Michel Thierry 
>>
>>
>>
>>
>>
>> Hi Kristian,
>>
>> More comments on this?
>> I've resent the mesa patch with the last changes
>>
>>
>> (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).
>>
>>
>> Michał has agreed with the interface and will use it for his work.
>> If mesa doesn't plan to use this for now, it's ok. The kernel changes
>> have
>> been done to prevent any regressions when the support 48-bit flag is
>> not
>> set.
>
>
>
> I didn't get any replies to my last comments on this:
>
> http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html
>
> Basically, I tried explicitly placing buffers above 8G and didn't see
> the HW problem described (ie it all worked fine).  I still think
> there's some confusion as to what the W/A is about.
>
> Here's my take: the W/A is a SW-only workaround to handle the cases
> where a driver uses heapless and 48-bit ppgtt. The problem is that the
> heaps are limited to 4G but with 48bit ppgtt a buffer can be placed
> anywhere it the 48 bit address space. If that happens it's consideredd
> out-of-bounds for the heap and access fails. To prevent this we need
> to make sure the bos we address in a heapless fashion are placed below
> 4g.
>
> For mesa, we only configure general state base as heap-less, which
> affects scratch bos. What this boils down to is that we need the 4G
> restriction only for the scratch bos set up on 3DSTATE_VS, 3DSTATE_GS
> and 3DSTATE_PS (and tesselation stage eventually). Look for the
> OUT_RELOC64 for stage->scratch_bo in gen8_vs_state.c, gen8_gs_state.c
> and gen8_ps_state.c



 I think it also affects _3DSTATE_VIEWPORT_STATE_POINTERS_CC, maybe it
 isn't exclusive to the scratch bos (the error state points to that
 instruction).


>>>
>>> Hi,
>>>
>>> Anymore inputs about this patch?
>>> AFAIK, if changes are required based on further comments from Kristian,
>>> these will be in the mesa patch[1], not libdrm. Also, Michał will use
>>> this
>>> flag in another project.
>>>
>> The comment seems quite brief and I'm not sure it fully addresses
>> Kristian's concern. I'd suspect that providing reference to the HW
>> documentation (confirming your assumption) might be beneficial.
>>
>
> Sure, attached is the hang I get if I don't set the restriction in
> gen8_misc_state.c and try to use the full 48-bit range
> (i915_error_state_nowa.txt). This is just running gfxbench t-rex.
>
> I see the 

[PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

[Kristian Høgsberg]

On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry  
wrote:
> On 9/14/2015 2:54 PM, Michał Winiarski wrote:
>>
>> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:
>>>
>>> Gen8+ supports 48-bit virtual addresses, but some objects must always be
>>> allocated inside the 32-bit address range.
>>>
>>> In specific, any resource used with flat/heapless (0x-0xf000)
>>> General State Heap (GSH) or Instruction State Heap (ISH) must be in a
>>> 32-bit range, because the General State Offset and Instruction State
>>> Offset
>>> are limited to 32-bits.
>>>
>>> The i915 driver has been modified to provide a flag to set when the 4GB
>>> limit is not necessary in a given bo (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
>>> 48-bit range will only be used when explicitly requested.
>>>
>>> Callers to the existing drm_intel_bo_emit_reloc function should set the
>>> use_48b_address_range flag beforehand, in order to use full ppgtt range.
>>>
>>> v2: Make set/clear functions nops on pre-gen8 platforms, and use them
>>>  internally in emit_reloc functions (Ben)
>>>  s/48BADDRESS/48B_ADDRESS/ (Dave)
>>> v3: Keep set/clear functions internal, no-one needs to use them directly.
>>> v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
>>>  before enabling set/clear function, print full offsets in debug
>>>  statements, using port of lower_32_bits and upper_32_bits from linux
>>>  kernel (Michał)
>>>
>>> References:
>>> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
>>> Cc: Ben Widawsky 
>>> Cc: Michał Winiarski 
>>
>>
>> +Kristian
>>
>> LGTM.
>> Acked-by: Michał Winiarski 
>>
>>> Signed-off-by: Michel Thierry 
>
>
>
> Hi Kristian,
>
> More comments on this?
> I've resent the mesa patch with the last changes
> (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).
>
> Michał has agreed with the interface and will use it for his work.
> If mesa doesn't plan to use this for now, it's ok. The kernel changes have
> been done to prevent any regressions when the support 48-bit flag is not
> set.

I didn't get any replies to my last comments on this:

http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html

Basically, I tried explicitly placing buffers above 8G and didn't see
the HW problem described (ie it all worked fine).  I still think
there's some confusion as to what the W/A is about.

Here's my take: the W/A is a SW-only workaround to handle the cases
where a driver uses heapless and 48-bit ppgtt. The problem is that the
heaps are limited to 4G but with 48bit ppgtt a buffer can be placed
anywhere it the 48 bit address space. If that happens it's consideredd
out-of-bounds for the heap and access fails. To prevent this we need
to make sure the bos we address in a heapless fashion are placed below
4g.

For mesa, we only configure general state base as heap-less, which
affects scratch bos. What this boils down to is that we need the 4G
restriction only for the scratch bos set up on 3DSTATE_VS, 3DSTATE_GS
and 3DSTATE_PS (and tesselation stage eventually). Look for the
OUT_RELOC64 for stage->scratch_bo in gen8_vs_state.c, gen8_gs_state.c
and gen8_ps_state.c

Kristian

> Thanks,
>
> -Michel
>
>
>>> ---
>>>   include/drm/i915_drm.h|  3 +-
>>>   intel/intel_bufmgr.c  | 11 ++
>>>   intel/intel_bufmgr.h  |  1 +
>>>   intel/intel_bufmgr_gem.c  | 88
>>> +--
>>>   intel/intel_bufmgr_priv.h | 14 
>>>   5 files changed, 97 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>>> index ded43b1..426b25c 100644
>>> --- a/include/drm/i915_drm.h
>>> +++ b/include/drm/i915_drm.h
>>> @@ -680,7 +680,8 @@ struct drm_i915_gem_exec_object2 {
>>>   #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>>>   #define EXEC_OBJECT_NEEDS_GTT (1<<1)
>>>   #define EXEC_OBJECT_WRITE (1<<2)
>>> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
>>> +#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
>>> +#define __EXEC_OBJECT_UNKNOWN_FLAGS
>>> -(EXEC_OBJECT_SUPPORTS_48B_ADDRESS<<1)
>>> __u64 flags;
>>>
>>> __u64 rsvd1;
>>> diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
>>> index 14ea9f9..0856e60 100644
>>> --- a/intel/intel_bufmgr.c
>>> +++ b/intel/intel_bufmgr.c
>>> @@ -293,6 +293,17 @@ drm_intel_bo_madvise(drm_intel_bo *bo, int madv)
>>>   }
>>>
>>>   int
>>> +drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable)
>>> +{
>>> +   if (bo->bufmgr->bo_use_48b_address_range) {
>>> +   bo->bufmgr->bo_use_48b_address_range(bo, enable);
>>> +   return 0;
>>> +   }
>>> +
>>> +   return -ENODEV;
>>> +}
>>> +
>>> +int
>>>   drm_intel_bo_references(drm_intel_bo *bo, drm_intel_bo *target_bo)
>>>   {
>>> return bo->bufmgr->bo_references(bo, target_bo);
>>> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
>>> index 95eecb8..a14c78f 100644
>>> --- a/intel/intel_bufmgr.h

[Intel-gfx] [PATCH mesa v3] i965/gen8+: bo in state base address must be in 32-bit address range

[Kristian Høgsberg]

On Mon, Aug 10, 2015 at 2:21 AM, Michel Thierry
 wrote:
> Hi,
>
> Thanks for the comments,
>
> On 8/7/2015 11:46 PM, Kristian Høgsberg wrote:
>>
>> On Fri, Aug 7, 2015 at 2:45 AM, Michel Thierry 
>> wrote:
>>>
>>> Gen8+ supports 48-bit virtual addresses, but some objects must always be
>>> allocated inside the 32-bit address range.
>>>
>>> In specific, any resource used with flat/heapless (0x-0xf000)
>>> General State Heap or Intruction State Heap must be in a 32-bit range
>>> (GSH / ISH), because the General State Offset and Instruction State
>>> Offset
>>> are limited to 32-bits.
>>
>>
>> This doesn't look right. From the workaround text, it doesn't sound
>> like this is a HW problem, it only affects GMM. In mesa, we don't use
>> "heapless" (which I assume means setting the base to 0 and max range)
>
>
> It is a hw problem, specifically in the state base address command. General
> State Base Address and Instruction Base Address shouldn't be > 4GB.
>
>> for instructions, dynamic state or surface state. Surface state and
>> dynamic state is always in our batch bo which is limited to 8k.
>> Provided STATE_BASE_ADDRESS works correctly in the HW, the batch bo
>> can be places anywhere in the aperture. Offsets to dynamic or surface
>> state is relative to the beginning of the batch bo and will always be
>> less than 4g. Instructions are in their own bo (brw->cache.bo), but
>> again, we point instruction state base to it and all our shader stage
>> setup code references the instructions relative to the beginning of
>> the instruction bo.
>
>
> I've seen the issue when the driver allocates mapped objects from bottom to
> top and the other bo's from top to bottom (gpu hangs). So I say this wa is
> needed.

mesa does use heapless for the scratch buffers, and on  BDW+ that's
the only address type that's relative to general state base address.
So we need the workaround there, whether or not there's a HW
limitation/bug.

I don't think there is a HW problem though. The driver I'm working on
can use 48 bit ppgtt and Chris Wilson's softpin ioctl for userspace BO
placement. I enabled that and made the userspace allocator place all
BOs above 8g, and it all stilll worked. In particular, the
instructions were above 8g and referenced relative to instruction base
address. If the instruction base was limited to 4g, this would have
hung the GPU.

The fact that the HW limits the size of the heaps to 4g can be
restriction when we move to full 48 ppgtt, but for how mesa uses
STATE_BASE_ADDRESS, it only affects general state base address.

Kristiain

> -Michel
>
>>
>> Kristian
>>
>>> Use drm_intel_bo_emit_reloc_48bit when the 4GB limit is not necessary,
>>> and
>>> the bo can be in the full address space.
>>>
>>> This commit introduces a dependency of libdrm 2.4.63, which introduces
>>> the
>>> drm_intel_bo_emit_reloc_48bit function.
>>>
>>> v2: s/48baddress/48b_address/,
>>>  Only use in OUT_RELOC64 cases, OUT_RELOC implies a 32-bit address
>>> offset
>>>  is needed (Ben)
>>> v3: Added OUT_RELOC64_INSIDE_4G, so it stands out when a 64-bit
>>> relocation
>>>  needs the 32-bit workaround (Chris)
>>>
>>> References:
>>> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
>>> Cc: Ben Widawsky 
>>> Cc: Chris Wilson 
>>> Signed-off-by: Michel Thierry 
>>> ---
>>>   configure.ac  |  2 +-
>>>   src/mesa/drivers/dri/i965/gen8_misc_state.c   | 19 +++
>>>   src/mesa/drivers/dri/i965/intel_batchbuffer.c | 20 
>>>   src/mesa/drivers/dri/i965/intel_batchbuffer.h | 10 --
>>>   4 files changed, 36 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index af61aa2..c92ca44 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -68,7 +68,7 @@ AC_SUBST([OSMESA_VERSION])
>>>   dnl Versions for external dependencies
>>>   LIBDRM_REQUIRED=2.4.38
>>>   LIBDRM_RADEON_REQUIRED=2.4.56
>>> -LIBDRM_INTEL_REQUIRED=2.4.60
>>> +LIBDRM_INTEL_REQUIRED=2.4.63
>>>   LIBDRM_NVVIEUX_REQUIRED=2.4.33
>>>   LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
>>>   LIBDRM_FREEDRENO_REQUIRED=2.4.57
>>> diff --git a/src/mesa/drivers/dri/i965/gen8_misc_state.c
>>> b/src/mesa/drivers/dri/i965/gen8_misc_state.c
>>> index b20038e..73eba06 100644
>>> --- a/src/mesa/drivers/dri/i965/gen8_misc_state.c
>>> +++ b/src/mesa/drivers/dri/i965/gen8_misc_state.c
>>> @@ -28,6 +28,10 @@
>>>
>>>   /**
>>>* Define the base addresses which some state is referenced from.
>>> + *
>>> + * Use OUT_RELOC64_INSIDE_4G instead of OUT_RELOC64, the General State
>>> + * Offset and Instruction State Offset are limited to 32-bits by
>>> hardware,
>>> + * and must be located in the first 4GBs (32-bit offset).
>>>*/
>>>   void gen8_upload_state_base_address(struct brw_context *brw)
>>>   {
>>> @@ -41,19 +45,18 @@ void gen8_upload_state_base_address(struct
>>> brw_context *brw)
>>>  OUT_BATCH(0);
>>>  OUT_BATCH(mocs_wb << 16);
>>>  /* 

[Intel-gfx] [PATCH mesa v3] i965/gen8+: bo in state base address must be in 32-bit address range

[Kristian Høgsberg]

On Fri, Aug 7, 2015 at 2:45 AM, Michel Thierry  
wrote:
> Gen8+ supports 48-bit virtual addresses, but some objects must always be
> allocated inside the 32-bit address range.
>
> In specific, any resource used with flat/heapless (0x-0xf000)
> General State Heap or Intruction State Heap must be in a 32-bit range
> (GSH / ISH), because the General State Offset and Instruction State Offset
> are limited to 32-bits.

This doesn't look right. From the workaround text, it doesn't sound
like this is a HW problem, it only affects GMM. In mesa, we don't use
"heapless" (which I assume means setting the base to 0 and max range)
for instructions, dynamic state or surface state. Surface state and
dynamic state is always in our batch bo which is limited to 8k.
Provided STATE_BASE_ADDRESS works correctly in the HW, the batch bo
can be places anywhere in the aperture. Offsets to dynamic or surface
state is relative to the beginning of the batch bo and will always be
less than 4g. Instructions are in their own bo (brw->cache.bo), but
again, we point instruction state base to it and all our shader stage
setup code references the instructions relative to the beginning of
the instruction bo.

Kristian

> Use drm_intel_bo_emit_reloc_48bit when the 4GB limit is not necessary, and
> the bo can be in the full address space.
>
> This commit introduces a dependency of libdrm 2.4.63, which introduces the
> drm_intel_bo_emit_reloc_48bit function.
>
> v2: s/48baddress/48b_address/,
> Only use in OUT_RELOC64 cases, OUT_RELOC implies a 32-bit address offset
> is needed (Ben)
> v3: Added OUT_RELOC64_INSIDE_4G, so it stands out when a 64-bit relocation
> needs the 32-bit workaround (Chris)
>
> References: 
> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
> Cc: Ben Widawsky 
> Cc: Chris Wilson 
> Signed-off-by: Michel Thierry 
> ---
>  configure.ac  |  2 +-
>  src/mesa/drivers/dri/i965/gen8_misc_state.c   | 19 +++
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 20 
>  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 10 --
>  4 files changed, 36 insertions(+), 15 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index af61aa2..c92ca44 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -68,7 +68,7 @@ AC_SUBST([OSMESA_VERSION])
>  dnl Versions for external dependencies
>  LIBDRM_REQUIRED=2.4.38
>  LIBDRM_RADEON_REQUIRED=2.4.56
> -LIBDRM_INTEL_REQUIRED=2.4.60
> +LIBDRM_INTEL_REQUIRED=2.4.63
>  LIBDRM_NVVIEUX_REQUIRED=2.4.33
>  LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
>  LIBDRM_FREEDRENO_REQUIRED=2.4.57
> diff --git a/src/mesa/drivers/dri/i965/gen8_misc_state.c 
> b/src/mesa/drivers/dri/i965/gen8_misc_state.c
> index b20038e..73eba06 100644
> --- a/src/mesa/drivers/dri/i965/gen8_misc_state.c
> +++ b/src/mesa/drivers/dri/i965/gen8_misc_state.c
> @@ -28,6 +28,10 @@
>
>  /**
>   * Define the base addresses which some state is referenced from.
> + *
> + * Use OUT_RELOC64_INSIDE_4G instead of OUT_RELOC64, the General State
> + * Offset and Instruction State Offset are limited to 32-bits by hardware,
> + * and must be located in the first 4GBs (32-bit offset).
>   */
>  void gen8_upload_state_base_address(struct brw_context *brw)
>  {
> @@ -41,19 +45,18 @@ void gen8_upload_state_base_address(struct brw_context 
> *brw)
> OUT_BATCH(0);
> OUT_BATCH(mocs_wb << 16);
> /* Surface state base address: */
> -   OUT_RELOC64(brw->batch.bo, I915_GEM_DOMAIN_SAMPLER, 0,
> -   mocs_wb << 4 | 1);
> +   OUT_RELOC64_INSIDE_4G(brw->batch.bo, I915_GEM_DOMAIN_SAMPLER, 0,
> + mocs_wb << 4 | 1);
> /* Dynamic state base address: */
> -   OUT_RELOC64(brw->batch.bo,
> -   I915_GEM_DOMAIN_RENDER | I915_GEM_DOMAIN_INSTRUCTION, 0,
> -   mocs_wb << 4 | 1);
> +   OUT_RELOC64_INSIDE_4G(brw->batch.bo,
> + I915_GEM_DOMAIN_RENDER | 
> I915_GEM_DOMAIN_INSTRUCTION, 0,
> + mocs_wb << 4 | 1);
> /* Indirect object base address: MEDIA_OBJECT data */
> OUT_BATCH(mocs_wb << 4 | 1);
> OUT_BATCH(0);
> /* Instruction base address: shader kernels (incl. SIP) */
> -   OUT_RELOC64(brw->cache.bo, I915_GEM_DOMAIN_INSTRUCTION, 0,
> -   mocs_wb << 4 | 1);
> -
> +   OUT_RELOC64_INSIDE_4G(brw->cache.bo, I915_GEM_DOMAIN_INSTRUCTION, 0,
> + mocs_wb << 4 | 1);
> /* General state buffer size */
> OUT_BATCH(0xf001);
> /* Dynamic state buffer size */
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 54081a1..ca90784 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -409,11 +409,23 @@ bool
>  intel_batchbuffer_emit_reloc64(struct brw_context *brw,
> drm_intel_bo *buffer,
> 

[PATCH] Prevent zero sized wl_egl_window

[Kristian Høgsberg]

On Fri, Feb 14, 2014 at 09:31:45AM +0200, Pekka Paalanen wrote:
> On Thu, 13 Feb 2014 18:18:23 +
> "Yeh, Sinclair"  wrote:
> 
> > > The below seems fine, but I wonder if we could make this one cause an
> > > error to be returned later where we can, rather than silently ignoring.
> > > I'm not sure where or how, though.
> > 
> > Would it make sense to change wl_egl_window_resize() so that it return a
> > value?  Either that, or it should be documented somewhere in the API
> > spec that setting width/height <=0 will be ignored.
> 
> I'm not sure we can change the function signature, it's public stable
> ABI.
> 
> > > Surely drivers have maximum size limits, too, those must be catched
> > > somewhere already.
> 
> But this might be worth looking into: if the window system produces a
> bad size, what do drivers do when they cannot allocate or render to it?
> 
> In X11 it's all hidden from the app, but I don't think the gfx stack can
> guarantee valid sizes in all cases, can it?
> 
> Anyway, my suggestion is just for convenience, and if drivers already
> just silently do whatever on a bad size, being silent here does not
> make it any worse.

We could maybe make it raise an EGL error, I'm a little concerned with how
this silently fails.  However, the behavior with Sinclairs patch is 
better than what we had before, so I've pushed that.

> Thanks,
> pq
> 
> > > 
> > > > egl_window->width  = width;
> > > > egl_window->height = height;
> > > > egl_window->dx = dx;
> > > > @@ -24,6 +27,9 @@ wl_egl_window_create(struct wl_surface *surface,
> > > >  {
> > > > struct wl_egl_window *egl_window;
> > > >  
> > > > +   if (width <= 0 || height <= 0)
> > > > +   return NULL;
> > > > +
> > > > egl_window = malloc(sizeof *egl_window);
> > > > if (!egl_window)
> > > > return NULL;
> > > 
> > > Thanks,
> > > pq
> > > ___
> > > wayland-devel mailing list
> > > wayland-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > 
> 
> ___
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] drm: Don't reference objects in the flink name idr

[Kristian Høgsberg]

On Tue, Dec 3, 2013 at 7:26 AM, Daniel Vetter  wrote:
> On Mon, Dec 02, 2013 at 05:36:17PM -0800, Kristian H?gsberg wrote:
>> There's no reason to keep a reference to objects in the name idr.  Each
>> handle to an object has a reference to the object and just before we
>> destroy the last handle we take the object out of the name idr.  Thus,
>> if an object is in the name idr, there's at least one reference to the
>> object.
>>
>> Or to put it another way, the name idr reference will never keep the
>> object alive.  It just looks like it, which is confusing.
>>
>> Signed-off-by: Kristian H?gsberg 
>
> I expect this to blow up when you race gem_close ioctl calls with flink
> open. i-g-t/gem_flink_close tests actually have been written specifically
> to exercise these races.
> -Daniel

Can you be more specific about what race you see?  The one thing that
could go wrong is that the last handle is delete after we enter
drm_gem_flink_ioctl() and look up the object but before taking the
object_name_lock, but that's handled by checking obj->handle_count
under the lock.  Deleting handles and removing the name is always done
under the object_name_lock from
drm_gem_object_handle_unreference_unlocked().

Kristian

>> ---
>>  drivers/gpu/drm/drm_gem.c | 15 ---
>>  1 file changed, 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>> index 4761ade..3ff39bb 100644
>> --- a/drivers/gpu/drm/drm_gem.c
>> +++ b/drivers/gpu/drm/drm_gem.c
>> @@ -175,11 +175,6 @@ drm_gem_remove_prime_handles(struct drm_gem_object 
>> *obj, struct drm_file *filp)
>>   mutex_unlock(>prime.lock);
>>  }
>>
>> -static void drm_gem_object_ref_bug(struct kref *list_kref)
>> -{
>> - BUG();
>> -}
>> -
>>  /**
>>   * Called after the last handle to the object has been closed
>>   *
>> @@ -195,13 +190,6 @@ static void drm_gem_object_handle_free(struct 
>> drm_gem_object *obj)
>>   if (obj->name) {
>>   idr_remove(>object_name_idr, obj->name);
>>   obj->name = 0;
>> - /*
>> -  * The object name held a reference to this object, drop
>> -  * that now.
>> - *
>> - * This cannot be the last reference, since the handle holds 
>> one too.
>> -  */
>> - kref_put(>refcount, drm_gem_object_ref_bug);
>>   }
>>  }
>>
>> @@ -602,9 +590,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
>>   goto err;
>>
>>   obj->name = ret;
>> -
>> - /* Allocate a reference for the name table.  */
>> - drm_gem_object_reference(obj);
>>   }
>>
>>   args->name = (uint64_t) obj->name;
>> --
>> 1.8.3.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: Don't reference objects in the flink name idr

[Kristian Høgsberg]

There's no reason to keep a reference to objects in the name idr.  Each
handle to an object has a reference to the object and just before we
destroy the last handle we take the object out of the name idr.  Thus,
if an object is in the name idr, there's at least one reference to the
object.

Or to put it another way, the name idr reference will never keep the
object alive.  It just looks like it, which is confusing.

Signed-off-by: Kristian H?gsberg 
---
 drivers/gpu/drm/drm_gem.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4761ade..3ff39bb 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -175,11 +175,6 @@ drm_gem_remove_prime_handles(struct drm_gem_object *obj, 
struct drm_file *filp)
mutex_unlock(>prime.lock);
 }

-static void drm_gem_object_ref_bug(struct kref *list_kref)
-{
-   BUG();
-}
-
 /**
  * Called after the last handle to the object has been closed
  *
@@ -195,13 +190,6 @@ static void drm_gem_object_handle_free(struct 
drm_gem_object *obj)
if (obj->name) {
idr_remove(>object_name_idr, obj->name);
obj->name = 0;
-   /*
-* The object name held a reference to this object, drop
-* that now.
-   *
-   * This cannot be the last reference, since the handle holds one 
too.
-*/
-   kref_put(>refcount, drm_gem_object_ref_bug);
}
 }

@@ -602,9 +590,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
goto err;

obj->name = ret;
-
-   /* Allocate a reference for the name table.  */
-   drm_gem_object_reference(obj);
}

args->name = (uint64_t) obj->name;
-- 
1.8.3.1

[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

[Kristian Høgsberg]

On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
> On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard  wrote:
> > Daniel Vetter  writes:
> >
> >> Hm, where do we have the canonical source for all these fourcc codes? I'm
> >> asking since we have our own copy in the kernel as drm_fourcc.h, and that
> >> one is part of the userspace ABI since we use it to pass around
> >> framebuffer formats and format lists.
> >
> > I think it's the kernel? I really don't know, as the whole notion of
> > fourcc codes seems crazy to me...
> >
> > Feel free to steal this code and stick it in the kernel if you like.
> 
> Well, I wasn't ever in favour of using fourcc codes since they're just
> not standardized at all, highly redundant in some cases and also miss
> lots of stuff we actually need (like all the rgb formats).

These drm codes are not fourcc codes in any other way than that
they're defined by creating a 32 bit value by picking four characters.
I don't know what PTSD triggers people have from hearing "fourcc", but
it seems severe.  Forget all that, these codes are DRM specific
defines that are not inteded to match anything anybody else does.  It
doesn't matter if these match of conflict with v4l, fourcc.org,
wikipedia.org or what the amiga did.  They're just tokens that let us
define succintly what the pixel format of a kms framebuffer is and
tell the kernel.

I don't know what else you'd propose?  Pass an X visual in the ioctl?
An EGL config?  This is our name space, we can add stuff as we need
(as Keith is doing here). include/uapi/drm/drm_fourcc.h is the
canonical source for these values and we should add
DRM_FORMAT_SARGB there to make sure we don't clash.

Why are these codes in mesa (and gbm and wl_drm protocol) then?
Because it turns out that once you have an stable and established
namespace for pixel formats (and a kernel userspace header is about as
stable and established as it gets) it makes a lot of sense to reuse
those values.

I already explained to Keith why we use different sets of format codes
in the DRI interface, but it's always fun to slam other peoples code.
Anyway, it's pretty simple, the __DRI_IMAGE_FORMAT_* defines predate
the introduction of drm_fourcc.h.  When we later added suport for
planar YUV __DRIimages, the kernel had picked up drm_fourcc.h after a
long sad bikeshedding flamewar, which included the planar formats we
needed.  At this point we could continue using our custom
__DRI_IMAGE_FORMAT_* defines or we could switch to the tokens that we
had finally converged on.  But don't let me ruin a good old snide remark.

> Cc'ing the heck out of this to get kernel people to hopefully notice.
> Maybe someone takes charge of this ... Otherwise meh.

I don't know what you want to change.  These values are already kernel
ABI, we use them in drmAddFB2, and again, I don't understand what
problem you're seeing.

Kristian

> >> Just afraid to create long-term maintainance madness here with the
> >> kernel's iron thou-shalt-not-break-userspace-ever rule ... Not likely
> >> we'll ever accept srgb for framebuffers though.
> >
> > Would suck to collide with something we do want though.
> 
> Yeah, it'd suck. But given how fourcc works we probably have that
> already, just haven't noticed yet :(
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension

[Kristian Høgsberg]

On Wed, Nov 6, 2013 at 10:09 AM, Keith Packard  wrote:
> Kristian H?gsberg  writes:
>
>> It just the two older create context functions (which fall back to
>> calling driCreateContextAtribs) and allocateBuffer and releaseBuffer.
>> The two buffer functions are __DRIbuffer specific of course, but we
>> can implement them in terms of __DRIimage in dri_util.c now.
>
> I guess the benefit is that we could remove the DRIdri2Extension
> functions from each driver and just use the DRIimage-based wrappers in
> dri_util then?
>
> We're still stuck with leaving the DRIdri2Extension as the interface
> From the loader though.
>
>> There is a third option, which is to pull the functions we need from
>> __DRIcoreExtension into the __DRIimageDriverExtension, which then is
>> all you need along with __DRIimageExtension.  This is as painful in
>> the short term as the current __DRIimageDriverExtension, but it lets
>> of cut loose of the DRI1 (__DRIcoreExtension has the DRI1
>> createNewScreen in it) and DRI2 baggage properly later on.  And
>> pulling out the functions into a loader private struct as you suggest
>> will make it a lot less painful.  The functions we move from core to
>> _DRIimageDriverExtension will share the same implementation in
>> dri_util.c so there's no new code.
>
> That doesn't seem like a crazy plan; at least Image-based loaders would
> be simple then; find the DRIimageDriverExtension and that's it.
>
>> Right - I actually like the clean break idea, but if we're going to
>> take that pain I want to get rid of all the junk and avoid the awkward
>> "use some stuff from __DRIcoreExtension and other stuff from
>> __DRIimageDriverExtension" setup.  So we should either 1) make
>> __DRIimageDriverExtension completely replace __DRIcoreExtension and
>> __DRIdri2Extension, or 2) just do a minimal, incremental change (just
>> the extension to indicate the support for __DRIimage based
>> getbuffers).
>
> If we're going to get drivers to add DRIimageExtension to the list of
> exported extensions, then it doesn't seem like it matters which way we
> go here -- we can move from 2) to 1) in the future without changing any
> drivers, only the dri_util bits and the loaders.
>
> However, if we think that 1) is the way to go, we might as well just do
> it as that'd avoid having to ever fix the loaders.

I'm OK with either approach. It does seem like cleaning up the DRI
driver interface is orthogonal to enabling the __DRIimage based
getBuffer callout though.

>> The difference is that there the loader returns a packed array of the
>> buffers the driver asked for. Now we're using a struct which can be
>> sparsely populated, so the driver should only look at the fields it
>> asked for.
>
> My concern is that the DRI2 drivers always return a front buffer for
> pixmap drawables, and I think this is actually required for things to
> work right (I have vague memories of hacking at this when I started
> this).
>
> How about I just stick the set of returned images back into the
> DRIimageList struct:

I think that's fine.  I was going to say that if we expect the
requested and the returned set of buffers to differ, we might as well
just memset the struct and let non-NULL images indicate returned
images.  But in case of a driver with a newer interface that extends
the struct (stereoscopic buffers), the loader can't memset the entire
struct (it only knows the smaller, previous version), and the driver
will think the non-NULL garbage fields are valid images.  So the
image_mask makes sense.

Kristian

> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index 2601249..2a873d8 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -1319,6 +1319,7 @@ enum __DRIimageBufferMask {
>  };
>
>  struct __DRIimageList {
> +   uint32_t image_mask;
> __DRIimage *back;
> __DRIimage *front;
>  };
> diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
> index 1bb8241..7de7abd 100644
> --- a/src/glx/dri3_glx.c
> +++ b/src/glx/dri3_glx.c
> @@ -1208,6 +1208,7 @@ dri3_get_buffers(__DRIdrawable *driDrawable,
> struct dri3_drawable *priv = loaderPrivate;
> struct dri3_buffer   *front, *back;
>
> +   buffers->image_mask = 0;
> buffers->front = NULL;
> buffers->back = NULL;
>
> @@ -1254,12 +1255,15 @@ dri3_get_buffers(__DRIdrawable *driDrawable,
> }
>
> if (front) {
> +  buffers->image_mask |= __DRI_IMAGE_BUFFER_FRONT;
>buffers->front = front->image;
>priv->have_fake_front = !priv->is_pixmap;
> }
>
> -   if (back)
> +   if (back) {
> +  buffers->image_mask |= __DRI_IMAGE_BUFFER_BACK;
>buffers->back = back->image;
> +   }
>
> priv->stamp = stamp;
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 90bbbfc..273d455 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -1338,7 +1338,7 @@ 

[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension

[Kristian Høgsberg]

On Wed, Nov 6, 2013 at 6:55 AM, Keith Packard  wrote:
> Kristian H?gsberg  writes:
>
>> Having written the GBM and Wayland suport for this, it's pretty clear
>> that we just want to use __DRIdri2Extension instead of duplicating
>> these functions.  Support for the __DRIimage based getBuffers is a
>> small incremental patch to src/egl/drivers/dri2:
>
> That would require drivers to support all of the DRI2 functions, rather
> than just the few needed for Image support though.

It just the two older create context functions (which fall back to
calling driCreateContextAtribs) and allocateBuffer and releaseBuffer.
The two buffer functions are __DRIbuffer specific of course, but we
can implement them in terms of __DRIimage in dri_util.c now.

>> The problem is that technically we would have to do:
>>
>>   if (dri2_dpy->image_driver) {
>>
>>  /* use dri2_dpy->image_driver->createContextAttribs
>>
>>   } else if (dri2_dpy->dri2 &&
>>dri2_dpy->dri2->base.version >= 3) {
>>
>>  /* use dri2_dpy->dri2->createContextAttribs
>>
>> all over the place even though they end up calling the same function.
>> The only real purpose of __DRIimageDriverExtension is to let the
>> loader know that the DRI driver supports and will use
>> __DRIimageLoaderExtension if provided, but we can just expose an empty
>> dummy extension to indicate that.
>
> Alternatively, the loader could simply call through the DRI2 version,
> acknowledging that they must be the same function? I'd sure like to be
> able to create an ImageLoader-only driver, even if that's not practical
> today.
>
> A couple of other options:
>
>  * Move the shared functions into a new structure which is embedded
>in both the DRIdri2ExtensionRec and the DRIimageDriverExtensionRec,
>then the loader could set a pointer to whichever it wanted to use
>in it's own structure.
>
>  * Have the loader pull the functions out of the ExtensionRec and stick
>them directly into its own structure. Then it could use those
>directly and avoid version checks while running.

There is a third option, which is to pull the functions we need from
__DRIcoreExtension into the __DRIimageDriverExtension, which then is
all you need along with __DRIimageExtension.  This is as painful in
the short term as the current __DRIimageDriverExtension, but it lets
of cut loose of the DRI1 (__DRIcoreExtension has the DRI1
createNewScreen in it) and DRI2 baggage properly later on.  And
pulling out the functions into a loader private struct as you suggest
will make it a lot less painful.  The functions we move from core to
_DRIimageDriverExtension will share the same implementation in
dri_util.c so there's no new code.

> But, if we just want to use the DRI2 driver interface and create an
> extension purely to mark that the driver will use an Image loader,
> that's easy too.

Right - I actually like the clean break idea, but if we're going to
take that pain I want to get rid of all the junk and avoid the awkward
"use some stuff from __DRIcoreExtension and other stuff from
__DRIimageDriverExtension" setup.  So we should either 1) make
__DRIimageDriverExtension completely replace __DRIcoreExtension and
__DRIdri2Extension, or 2) just do a minimal, incremental change (just
the extension to indicate the support for __DRIimage based
getbuffers).

Kristian

>> I think we should only look at image.front if the
>> __DRI_IMAGE_BUFFER_FRONT bit is set.  We never want to set up a front
>> buffer that we didn't ask for and it seems wrong that the loader has
>> to clear image.front, if the driver didn't ask for front.
>
> I simply duplicated the logic from the DRI2 path which works exactly the
> same way (asks for buffers, then looks to see what it got). I didn't dig
> into the details further than this, I'm afraid. The only case where asks
> != received is for pixmap targets where you always get a front buffer. I
> assumed there was some deep semantic requirement for that...

The difference is that there the loader returns a packed array of the
buffers the driver asked for. Now we're using a struct which can be
sparsely populated, so the driver should only look at the fields it
asked for.

[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension

[Kristian Høgsberg]

On Mon, Nov 04, 2013 at 06:23:27PM -0800, Keith Packard wrote:
> These provide an interface between the driver and the loader to allocate
> color buffers through the DRIimage extension interface rather than through a
> loader-specific extension (as is used by DRI2, for instance).
> 
> The driver uses the loader 'getBuffers' interface to allocate color buffers.
> 
> The loader uses the createNewScreen2, createNewDrawable, createNewContext,
> getAPIMask and createContextAttribs APIS (mostly shared with DRI2).
> 
> This interface will work with the DRI3 loader, and should also work with GBM
> and other loaders so that drivers need not be customized for each new loader
> interface, as long as they provide this image interface.
> 
> Signed-off-by: Keith Packard 
> ---
>  include/GL/internal/dri_interface.h   | 112 +
>  src/mesa/drivers/dri/common/dri_util.c| 113 +
>  src/mesa/drivers/dri/common/dri_util.h|   6 ++
>  src/mesa/drivers/dri/i915/intel_context.c | 111 -
>  src/mesa/drivers/dri/i915/intel_mipmap_tree.c |  33 
>  src/mesa/drivers/dri/i915/intel_mipmap_tree.h |   8 ++
>  src/mesa/drivers/dri/i915/intel_screen.c  |   1 +
>  src/mesa/drivers/dri/i965/brw_context.c   | 114 
> --
>  src/mesa/drivers/dri/i965/brw_context.h   |  16 ++--
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c |  61 ++
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |   8 ++
>  src/mesa/drivers/dri/i965/intel_screen.c  |   5 +-
>  12 files changed, 568 insertions(+), 20 deletions(-)
> 
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index 907aeca..8fc1fa6 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -86,6 +86,10 @@ typedef struct __DRIdri2LoaderExtensionRec 
> __DRIdri2LoaderExtension;
>  typedef struct __DRI2flushExtensionRec   __DRI2flushExtension;
>  typedef struct __DRI2throttleExtensionRec__DRI2throttleExtension;
>  
> +
> +typedef struct __DRIimageLoaderExtensionRec __DRIimageLoaderExtension;
> +typedef struct __DRIimageDriverExtensionRec __DRIimageDriverExtension;
> +
>  /*@}*/
>  
>  
> @@ -1288,4 +1292,112 @@ typedef struct __DRIDriverVtableExtensionRec {
>  const struct __DriverAPIRec *vtable;
>  } __DRIDriverVtableExtension;
>  
> +/**
> + * Image Loader extension. Drivers use this to allocate color buffers
> + */
> +
> +#define __DRI_DRIVER_EXTENSIONS "__driDriverExtensions"
> +
> +enum __DRIimageBufferMask {
> +   __DRI_IMAGE_BUFFER_BACK = (1 << 0),
> +   __DRI_IMAGE_BUFFER_FRONT = (1 << 1)
> +};
> +
> +struct __DRIimageList {
> +   __DRIimage *back;
> +   __DRIimage *front;
> +};
> +
> +#define __DRI_IMAGE_LOADER "DRI_IMAGE_LOADER"
> +#define __DRI_IMAGE_LOADER_VERSION 1
> +
> +struct __DRIimageLoaderExtensionRec {
> +__DRIextension base;
> +
> +   /**
> +* Allocate color buffers.
> +*
> +* \param driDrawable
> +* \param width  Width of allocated buffers
> +* \param height Height of allocated buffers
> +* \param format one of __DRI_IMAGE_FORMAT_*
> +* \param stamp  Address of variable to be updated when
> +*   getBuffers must be called again
> +* \param loaderPrivate  The loaderPrivate for driDrawable
> +* \param buffer_maskSet of buffers to allocate
> +* \param buffersReturned buffers
> +*/
> +   int (*getBuffers)(__DRIdrawable *driDrawable,
> + int *width, int *height,
> + unsigned int format,
> + uint32_t *stamp,
> + void *loaderPrivate,
> + uint32_t buffer_mask,
> + struct __DRIimageList *buffers);
> +
> +/**
> + * Flush pending front-buffer rendering
> + *
> + * Any rendering that has been performed to the
> + * fake front will be flushed to the front
> + *
> + * \param driDrawableDrawable whose front-buffer is to be flushed
> + * \param loaderPrivate  Loader's private data that was previously passed
> + *   into __DRIdri2ExtensionRec::createNewDrawable
> + */
> +void (*flushFrontBuffer)(__DRIdrawable *driDrawable, void 
> *loaderPrivate);
> +};
> +
> +/**
> + * DRI extension.
> + */
> +
> +//struct gl_context;
> +//struct dd_function_table;
> +
> +typedef __DRIscreen *
> +(*__DRIcreateNewScreen2)(int screen, int fd,
> + const __DRIextension **extensions,
> + const __DRIextension **driver_extensions,
> + const __DRIconfig ***driver_configs,
> + void *loaderPrivate);
> +
> +typedef __DRIdrawable *
> +(*__DRIcreateNewDrawable)(__DRIscreen *screen,
> +  const __DRIconfig *config,
> +   

[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension

[Kristian Høgsberg]

On Tue, Nov 5, 2013 at 4:59 PM, Keith Packard  wrote:
> Kristian H?gsberg  writes:
>
>
>> We can drop width and height now and just get it from either of the
>> returned images.  Format is a function of the __DRIconfig and doesn't
>> change, so we could make that something you can query from the config
>> in the interest of further reducing the number of arguments.
>
> Sure would be nice if there were simpler ways than calling the
> getAttribs function though; I'm tempted to just leave these params in as
> every single driver will need those values and passing them back here
> will make the driver code shorter.

I would say that it's more important to keep the interfaces between
components as simple as possible, even if it incurs a little
inconvenience inside the driver.

But it's a non-issue, since inside the driver you can just access them
as image->width/height.

>> I'll give this a try with the GBM and Wayland EGL backends now.
>
> Cool. Having two backends using this same interface would really help
> out.

I got this running now and I found a few other things.  I'll reply to
the patch again.

Kristian

[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension

[Kristian Høgsberg]

On Mon, Nov 04, 2013 at 06:23:27PM -0800, Keith Packard wrote:
> These provide an interface between the driver and the loader to allocate
> color buffers through the DRIimage extension interface rather than through a
> loader-specific extension (as is used by DRI2, for instance).
> 
> The driver uses the loader 'getBuffers' interface to allocate color buffers.
> 
> The loader uses the createNewScreen2, createNewDrawable, createNewContext,
> getAPIMask and createContextAttribs APIS (mostly shared with DRI2).
> 
> This interface will work with the DRI3 loader, and should also work with GBM
> and other loaders so that drivers need not be customized for each new loader
> interface, as long as they provide this image interface.
> 
> Signed-off-by: Keith Packard 
> ---
>  include/GL/internal/dri_interface.h   | 112 +
>  src/mesa/drivers/dri/common/dri_util.c| 113 +
>  src/mesa/drivers/dri/common/dri_util.h|   6 ++
>  src/mesa/drivers/dri/i915/intel_context.c | 111 -
>  src/mesa/drivers/dri/i915/intel_mipmap_tree.c |  33 
>  src/mesa/drivers/dri/i915/intel_mipmap_tree.h |   8 ++
>  src/mesa/drivers/dri/i915/intel_screen.c  |   1 +
>  src/mesa/drivers/dri/i965/brw_context.c   | 114 
> --
>  src/mesa/drivers/dri/i965/brw_context.h   |  16 ++--
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c |  61 ++
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |   8 ++
>  src/mesa/drivers/dri/i965/intel_screen.c  |   5 +-
>  12 files changed, 568 insertions(+), 20 deletions(-)
> 
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index 907aeca..8fc1fa6 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -86,6 +86,10 @@ typedef struct __DRIdri2LoaderExtensionRec 
> __DRIdri2LoaderExtension;
>  typedef struct __DRI2flushExtensionRec   __DRI2flushExtension;
>  typedef struct __DRI2throttleExtensionRec__DRI2throttleExtension;
>  
> +
> +typedef struct __DRIimageLoaderExtensionRec __DRIimageLoaderExtension;
> +typedef struct __DRIimageDriverExtensionRec __DRIimageDriverExtension;
> +
>  /*@}*/
>  
>  
> @@ -1288,4 +1292,112 @@ typedef struct __DRIDriverVtableExtensionRec {
>  const struct __DriverAPIRec *vtable;
>  } __DRIDriverVtableExtension;
>  
> +/**
> + * Image Loader extension. Drivers use this to allocate color buffers
> + */
> +
> +#define __DRI_DRIVER_EXTENSIONS "__driDriverExtensions"
> +
> +enum __DRIimageBufferMask {
> +   __DRI_IMAGE_BUFFER_BACK = (1 << 0),
> +   __DRI_IMAGE_BUFFER_FRONT = (1 << 1)
> +};
> +
> +struct __DRIimageList {
> +   __DRIimage *back;
> +   __DRIimage *front;
> +};
> +
> +#define __DRI_IMAGE_LOADER "DRI_IMAGE_LOADER"
> +#define __DRI_IMAGE_LOADER_VERSION 1
> +
> +struct __DRIimageLoaderExtensionRec {
> +__DRIextension base;
> +
> +   /**
> +* Allocate color buffers.
> +*
> +* \param driDrawable
> +* \param width  Width of allocated buffers
> +* \param height Height of allocated buffers
> +* \param format one of __DRI_IMAGE_FORMAT_*
> +* \param stamp  Address of variable to be updated when
> +*   getBuffers must be called again
> +* \param loaderPrivate  The loaderPrivate for driDrawable
> +* \param buffer_maskSet of buffers to allocate
> +* \param buffersReturned buffers
> +*/
> +   int (*getBuffers)(__DRIdrawable *driDrawable,
> + int *width, int *height,

We can drop width and height now and just get it from either of the
returned images.  Format is a function of the __DRIconfig and doesn't
change, so we could make that something you can query from the config
in the interest of further reducing the number of arguments.

I'll give this a try with the GBM and Wayland EGL backends now.

Kristian

> + unsigned int format,
> + uint32_t *stamp,
> + void *loaderPrivate,
> + uint32_t buffer_mask,
> + struct __DRIimageList *buffers);
> +
> +/**
> + * Flush pending front-buffer rendering
> + *
> + * Any rendering that has been performed to the
> + * fake front will be flushed to the front
> + *
> + * \param driDrawableDrawable whose front-buffer is to be flushed
> + * \param loaderPrivate  Loader's private data that was previously passed
> + *   into __DRIdri2ExtensionRec::createNewDrawable
> + */
> +void (*flushFrontBuffer)(__DRIdrawable *driDrawable, void 
> *loaderPrivate);
> +};
> +
> +/**
> + * DRI extension.
> + */
> +
> +//struct gl_context;
> +//struct dd_function_table;
> +
> +typedef __DRIscreen *
> +(*__DRIcreateNewScreen2)(int screen, int fd,
> + const __DRIextension 

[PATCH 6/8] dri/i915,dri/i965: Use driGLFormatToImageFormat and driImageFormatToGLFormat

[Kristian Høgsberg]

On Mon, Nov 04, 2013 at 06:23:26PM -0800, Keith Packard wrote:
> Remove private versions of these functions

Reviewed-by: Kristian H?gsberg 

> Signed-off-by: Keith Packard 
> ---
>  src/mesa/drivers/dri/i915/intel_screen.c | 53 ++-
>  src/mesa/drivers/dri/i965/intel_screen.c | 63 
> ++--
>  2 files changed, 8 insertions(+), 108 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
> b/src/mesa/drivers/dri/i915/intel_screen.c
> index 085e894..12113c7 100644
> --- a/src/mesa/drivers/dri/i915/intel_screen.c
> +++ b/src/mesa/drivers/dri/i915/intel_screen.c
> @@ -244,32 +244,8 @@ intel_allocate_image(int dri_format, void *loaderPrivate)
>  image->dri_format = dri_format;
>  image->offset = 0;
>  
> -switch (dri_format) {
> -case __DRI_IMAGE_FORMAT_RGB565:
> -   image->format = MESA_FORMAT_RGB565;
> -   break;
> -case __DRI_IMAGE_FORMAT_XRGB:
> -   image->format = MESA_FORMAT_XRGB;
> -   break;
> -case __DRI_IMAGE_FORMAT_ARGB:
> -   image->format = MESA_FORMAT_ARGB;
> -   break;
> -case __DRI_IMAGE_FORMAT_ABGR:
> -   image->format = MESA_FORMAT_RGBA_REV;
> -   break;
> -case __DRI_IMAGE_FORMAT_XBGR:
> -   image->format = MESA_FORMAT_RGBX_REV;
> -   break;
> -case __DRI_IMAGE_FORMAT_R8:
> -   image->format = MESA_FORMAT_R8;
> -   break;
> -case __DRI_IMAGE_FORMAT_GR88:
> -   image->format = MESA_FORMAT_GR88;
> -   break;
> -case __DRI_IMAGE_FORMAT_NONE:
> -   image->format = MESA_FORMAT_NONE;
> -   break;
> -default:
> +image->format = driImageFormatToGLFormat(dri_format);
> +if (image->format == 0) {
> free(image);
> return NULL;
>  }
> @@ -318,27 +294,6 @@ intel_setup_image_from_dimensions(__DRIimage *image)
> image->tile_y = 0;
>  }
>  
> -static inline uint32_t
> -intel_dri_format(GLuint format)
> -{
> -   switch (format) {
> -   case MESA_FORMAT_RGB565:
> -  return __DRI_IMAGE_FORMAT_RGB565;
> -   case MESA_FORMAT_XRGB:
> -  return __DRI_IMAGE_FORMAT_XRGB;
> -   case MESA_FORMAT_ARGB:
> -  return __DRI_IMAGE_FORMAT_ARGB;
> -   case MESA_FORMAT_RGBA_REV:
> -  return __DRI_IMAGE_FORMAT_ABGR;
> -   case MESA_FORMAT_R8:
> -  return __DRI_IMAGE_FORMAT_R8;
> -   case MESA_FORMAT_RG88:
> -  return __DRI_IMAGE_FORMAT_GR88;
> -   }
> -
> -   return MESA_FORMAT_NONE;
> -}
> -
>  static __DRIimage *
>  intel_create_image_from_name(__DRIscreen *screen,
>int width, int height, int format,
> @@ -396,7 +351,7 @@ intel_create_image_from_renderbuffer(__DRIcontext 
> *context,
> image->data = loaderPrivate;
> intel_region_reference(>region, irb->mt->region);
> intel_setup_image_from_dimensions(image);
> -   image->dri_format = intel_dri_format(image->format);
> +   image->dri_format = driGLFormatToImageFormat(image->format);
>  
> rb->NeedsFinishRenderTexture = true;
> return image;
> @@ -450,7 +405,7 @@ intel_create_image_from_texture(__DRIcontext *context, 
> int target,
> image->format = obj->Image[face][level]->TexFormat;
> image->data = loaderPrivate;
> intel_setup_image_from_mipmap_tree(intel, image, iobj->mt, level, 
> zoffset);
> -   image->dri_format = intel_dri_format(image->format);
> +   image->dri_format = driGLFormatToImageFormat(image->format);
> if (image->dri_format == MESA_FORMAT_NONE) {
>*error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
>free(image);
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index b89b1a5..f9339c1 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -298,38 +298,8 @@ intel_allocate_image(int dri_format, void *loaderPrivate)
>  image->dri_format = dri_format;
>  image->offset = 0;
>  
> -switch (dri_format) {
> -case __DRI_IMAGE_FORMAT_RGB565:
> -   image->format = MESA_FORMAT_RGB565;
> -   break;
> -case __DRI_IMAGE_FORMAT_XRGB:
> -   image->format = MESA_FORMAT_XRGB;
> -   break;
> -case __DRI_IMAGE_FORMAT_ARGB2101010:
> -   image->format = MESA_FORMAT_ARGB2101010;
> -   break;
> -case __DRI_IMAGE_FORMAT_XRGB2101010:
> -   image->format = MESA_FORMAT_XRGB2101010_UNORM;
> -   break;
> -case __DRI_IMAGE_FORMAT_ARGB:
> -   image->format = MESA_FORMAT_ARGB;
> -   break;
> -case __DRI_IMAGE_FORMAT_ABGR:
> -   image->format = MESA_FORMAT_RGBA_REV;
> -   break;
> -case __DRI_IMAGE_FORMAT_XBGR:
> -   image->format = MESA_FORMAT_RGBX_REV;
> -   break;
> -case __DRI_IMAGE_FORMAT_R8:
> -   image->format = MESA_FORMAT_R8;
> -   break;
> -case __DRI_IMAGE_FORMAT_GR88:
> -   image->format = MESA_FORMAT_GR88;
> -   break;
> -case __DRI_IMAGE_FORMAT_NONE:
> -   

[PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_*

[Kristian Høgsberg]

On Mon, Nov 04, 2013 at 06:23:25PM -0800, Keith Packard wrote:
> The __DRI_IMAGE_FORMAT codes are used by the image extension, drivers need to
> be able to translate between them. Instead of duplicating this translation in
> each driver, create a shared version.

I'll take the bait... before the i915/i965 split, this code was only
needed in this one place.  All other drivers are gallium drivers which
need to convert to galliums enum pipe_format instead of the gl_format
enum.  Anyway, the code certainly looks more at home in dri_util.c.

Reviewed-by: Kristian H?gsberg 

> Signed-off-by: Keith Packard 
> ---
>  src/mesa/drivers/dri/common/dri_util.c | 62 
> ++
>  src/mesa/drivers/dri/common/dri_util.h |  6 
>  2 files changed, 68 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/common/dri_util.c 
> b/src/mesa/drivers/dri/common/dri_util.c
> index 95c8b41..76c8ae5 100644
> --- a/src/mesa/drivers/dri/common/dri_util.c
> +++ b/src/mesa/drivers/dri/common/dri_util.c
> @@ -792,3 +792,65 @@ driUpdateFramebufferSize(struct gl_context *ctx, const 
> __DRIdrawable *dPriv)
>assert(fb->Height == dPriv->h);
> }
>  }
> +
> +uint32_t
> +driGLFormatToImageFormat(gl_format format)
> +{
> +   switch (format) {
> +   case MESA_FORMAT_RGB565:
> +  return __DRI_IMAGE_FORMAT_RGB565;
> +   case MESA_FORMAT_XRGB:
> +  return __DRI_IMAGE_FORMAT_XRGB;
> +   case MESA_FORMAT_ARGB2101010:
> +  return __DRI_IMAGE_FORMAT_ARGB2101010;
> +   case MESA_FORMAT_XRGB2101010_UNORM:
> +  return __DRI_IMAGE_FORMAT_XRGB2101010;
> +   case MESA_FORMAT_ARGB:
> +  return __DRI_IMAGE_FORMAT_ARGB;
> +   case MESA_FORMAT_RGBA_REV:
> +  return __DRI_IMAGE_FORMAT_ABGR;
> +   case MESA_FORMAT_RGBX_REV:
> +  return __DRI_IMAGE_FORMAT_XBGR;
> +   case MESA_FORMAT_R8:
> +  return __DRI_IMAGE_FORMAT_R8;
> +   case MESA_FORMAT_GR88:
> +  return __DRI_IMAGE_FORMAT_GR88;
> +   case MESA_FORMAT_NONE:
> +  return __DRI_IMAGE_FORMAT_NONE;
> +   case MESA_FORMAT_SARGB8:
> +  return __DRI_IMAGE_FORMAT_SARGB8;
> +   default:
> +  return 0;
> +   }
> +}
> +
> +gl_format
> +driImageFormatToGLFormat(uint32_t image_format)
> +{
> +   switch (image_format) {
> +   case __DRI_IMAGE_FORMAT_RGB565:
> +  return MESA_FORMAT_RGB565;
> +   case __DRI_IMAGE_FORMAT_XRGB:
> +  return MESA_FORMAT_XRGB;
> +   case __DRI_IMAGE_FORMAT_ARGB2101010:
> +  return MESA_FORMAT_ARGB2101010;
> +   case __DRI_IMAGE_FORMAT_XRGB2101010:
> +  return MESA_FORMAT_XRGB2101010_UNORM;
> +   case __DRI_IMAGE_FORMAT_ARGB:
> +  return MESA_FORMAT_ARGB;
> +   case __DRI_IMAGE_FORMAT_ABGR:
> +  return MESA_FORMAT_RGBA_REV;
> +   case __DRI_IMAGE_FORMAT_XBGR:
> +  return MESA_FORMAT_RGBX_REV;
> +   case __DRI_IMAGE_FORMAT_R8:
> +  return MESA_FORMAT_R8;
> +   case __DRI_IMAGE_FORMAT_GR88:
> +  return MESA_FORMAT_GR88;
> +   case __DRI_IMAGE_FORMAT_SARGB8:
> +  return MESA_FORMAT_SARGB8;
> +   case __DRI_IMAGE_FORMAT_NONE:
> +  return MESA_FORMAT_NONE;
> +   default:
> +  return MESA_FORMAT_NONE;
> +   }
> +}
> diff --git a/src/mesa/drivers/dri/common/dri_util.h 
> b/src/mesa/drivers/dri/common/dri_util.h
> index 5b56061..fd40769 100644
> --- a/src/mesa/drivers/dri/common/dri_util.h
> +++ b/src/mesa/drivers/dri/common/dri_util.h
> @@ -271,6 +271,12 @@ struct __DRIdrawableRec {
>  } dri2;
>  };
>  
> +extern uint32_t
> +driGLFormatToImageFormat(gl_format format);
> +
> +extern gl_format
> +driImageFormatToGLFormat(uint32_t image_format);
> +
>  extern void
>  dri2InvalidateDrawable(__DRIdrawable *drawable);
>  
> -- 
> 1.8.4.2
> 

[PATCH 3/8] dri/intel: Add explicit size parameter to intel_region_alloc_for_fd

[Kristian Høgsberg]

On Mon, Nov 04, 2013 at 06:23:23PM -0800, Keith Packard wrote:
> Instead of assuming that the size will be height * pitch, have the caller pass
> in the size explicitly.
> 
> Signed-off-by: Keith Packard 
> ---
>  src/mesa/drivers/dri/i915/intel_regions.c | 4 ++--
>  src/mesa/drivers/dri/i915/intel_regions.h | 2 +-
>  src/mesa/drivers/dri/i915/intel_screen.c  | 2 +-
>  src/mesa/drivers/dri/i965/intel_regions.c | 4 ++--
>  src/mesa/drivers/dri/i965/intel_regions.h | 1 +
>  src/mesa/drivers/dri/i965/intel_screen.c  | 2 +-
>  6 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i915/intel_regions.c 
> b/src/mesa/drivers/dri/i915/intel_regions.c
> index 44f7030..9f5b89e 100644
> --- a/src/mesa/drivers/dri/i915/intel_regions.c
> +++ b/src/mesa/drivers/dri/i915/intel_regions.c
> @@ -209,6 +209,7 @@ struct intel_region *
>  intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> +  GLuint size,
>int fd, const char *name)
>  {
> struct intel_region *region;
> @@ -216,8 +217,7 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
> int ret;
> uint32_t bit_6_swizzle, tiling;
>  
> -   buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr,
> -   fd, height * pitch);
> +   buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr, fd, size);

The 3.12 kernel let's you get the bo size from lseek on the dma_buf
fd.  I added libdrm support for getting the size that, and if that
works, it overrides the user provided size:

  
http://cgit.freedesktop.org/mesa/drm/commit/?id=9c52c3dc4763336884277d8005eac7e6efb77600

3.12 is the first kernel where dma_buf fd passing works reliably
anyway and the first kernel with render-nodes, so it's not worth the
trouble to try to make this work for older kernels.

Regardless, this patchs looks good.

Reviewed-by: Kristian H?gsberg 

> if (buffer == NULL)
>return NULL;
> ret = drm_intel_bo_get_tiling(buffer, , _6_swizzle);
> diff --git a/src/mesa/drivers/dri/i915/intel_regions.h 
> b/src/mesa/drivers/dri/i915/intel_regions.h
> index 5c612a9..6bc4a42 100644
> --- a/src/mesa/drivers/dri/i915/intel_regions.h
> +++ b/src/mesa/drivers/dri/i915/intel_regions.h
> @@ -91,7 +91,7 @@ struct intel_region *
>  intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> -  int fd, const char *name);
> +  GLuint size, int fd, const char *name);
>  
>  bool
>  intel_region_flink(struct intel_region *region, uint32_t *name);
> diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
> b/src/mesa/drivers/dri/i915/intel_screen.c
> index 3f54752..085e894 100644
> --- a/src/mesa/drivers/dri/i915/intel_screen.c
> +++ b/src/mesa/drivers/dri/i915/intel_screen.c
> @@ -653,7 +653,7 @@ intel_create_image_from_fds(__DRIscreen *screen,
>return NULL;
>  
> image->region = intel_region_alloc_for_fd(intelScreen,
> - 1, width, height,
> + 1, width, height, height * 
> strides[0],
>   strides[0], fds[0], "image");
> if (image->region == NULL) {
>free(image);
> diff --git a/src/mesa/drivers/dri/i965/intel_regions.c 
> b/src/mesa/drivers/dri/i965/intel_regions.c
> index a6b80fd..3920f4f 100644
> --- a/src/mesa/drivers/dri/i965/intel_regions.c
> +++ b/src/mesa/drivers/dri/i965/intel_regions.c
> @@ -209,6 +209,7 @@ struct intel_region *
>  intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> +  GLuint size,
>int fd, const char *name)
>  {
> struct intel_region *region;
> @@ -216,8 +217,7 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
> int ret;
> uint32_t bit_6_swizzle, tiling;
>  
> -   buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr,
> -   fd, height * pitch);
> +   buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr, fd, size);
> if (buffer == NULL)
>return NULL;
> ret = drm_intel_bo_get_tiling(buffer, , _6_swizzle);
> diff --git a/src/mesa/drivers/dri/i965/intel_regions.h 
> b/src/mesa/drivers/dri/i965/intel_regions.h
> index f08a113..05dfef3 100644
> --- a/src/mesa/drivers/dri/i965/intel_regions.h
> +++ b/src/mesa/drivers/dri/i965/intel_regions.h
> @@ -92,6 +92,7 @@ struct intel_region *
>  intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> +  

[Mesa-dev] [PATCH 0/8] Add DRIimage-based DRI3/Present loader

[Kristian Høgsberg]

On Tue, Nov 05, 2013 at 12:04:32PM -0800, Eric Anholt wrote:
> Keith Packard  writes:
> 
> > Keith Packard  writes:
> >
> >> This sequence first adds a a couple of new DRIimage extensions to the
> >> dri/common, dri/i915 and dri/i965 directories which define a
> >> loader-independent API for managing window system operations.
> >>
> >> The last patch adds a new DRI3000 loader using those new interfaces.
> >
> > I've figured out that I can also re-use dri2CreateNewScreen2 for the
> > image driver bits, as long as I change that function to also look up the
> > image loader. That means there are *no* new dri_util functions needed.
> >
> > To recap, the changes needed to support using the DRIimageExtension
> > interfaces for allocating buffers from the driver in the loader are:
> >
> > DRIimageDriverExtension
> >
> > A proper subset of DRIdri2DriverExtension, which uses
> > the same five functions involved in creating new objects:
> >
> >/* Common DRI functions, shared with DRI2 */
> >__DRIcreateNewScreen2createNewScreen2;
> >__DRIcreateNewDrawable   createNewDrawable;
> >__DRIcreateNewContextcreateNewContext;
> >__DRIcreateContextAttribscreateContextAttribs;
> >__DRIgetAPIMask  getAPIMask;
> 
> It seems like we could just stick these things in __DRI_CORE as opposed
> to having another new extension to look up.  The downside I see there is
> bugs in the server, which have patches at xserver-driinterface-versions
> of my tree.  (Unfortunately, I'm having a hard time building the server
> currently, so no testing yet).  Having a new extension whose name has
> nothing to do with the functions in it seems really weird.

It may make more sense to just extend the existing interfaces, but
when we discussed DRIimageDriverExtension, the idea was that we could
phase out DRIdri2Extension.  I think that still makes sense but
introducing more extensions doesn't make this interface better.

The way this was done originally was that we have DRIcoreExtension
which provided DRI1 support.  The DRIdri2Extension extension replaces
some of the core functions (it has a createNewScreen that doesn't take
a sarea handle, for example...) and allows a loader to implement DRI2,
but you have to use both extensions.  DRIswrastExtension works in a
similar for swrast.

The idea was to share the core functionality, but it's obviously messy
to have to mix two extensions to get things working.  If we're
introducing a new extension, I'd suggest we move the functions from
DRIcoreExtension that we still use into this new extension and make it
completely replace DRIcoreExtension and DRIdri2Extension.  The
functions from the core extension we still use are:

void (*destroyScreen)(__DRIscreen *screen);

const __DRIextension **(*getExtensions)(__DRIscreen *screen);

int (*getConfigAttrib)(const __DRIconfig *config,
   unsigned int attrib,
   unsigned int *value);

int (*indexConfigAttrib)(const __DRIconfig *config, int index,
 unsigned int *attrib, unsigned int *value);

void (*destroyDrawable)(__DRIdrawable *drawable);

int (*copyContext)(__DRIcontext *dest,
   __DRIcontext *src,
   unsigned long mask);

void (*destroyContext)(__DRIcontext *context);

int (*bindContext)(__DRIcontext *ctx,
   __DRIdrawable *pdraw,
   __DRIdrawable *pread);

int (*unbindContext)(__DRIcontext *ctx);

and if we add those to DRIimageDriverExtension the loader only needs
to look for that and the DRIimage extension.  Of course, the
implementation is already in dri_util.c, we just need to set the
function pointers to the DRIcoreExtension functions we share.

Kristian

[PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver

[Kristian Høgsberg]

I sent a reply to the sourceforge addresses in the original emails,
but I didn't see it show up in the archives.  Trying again with the
freedesktop addresses.

On Thu, Oct 31, 2013 at 04:13:15PM -0700, Keith Packard wrote:
> This hooks DRI3 support into the GLX layer, the DRI common layer and the Intel
> driver.
> 
> Signed-off-by: Keith Packard 
> ---
>  configure.ac  |   10 +-
>  include/GL/internal/dri_interface.h   |  158 +++
>  src/glx/Makefile.am   |2 +
>  src/glx/dri3_common.c |  146 +++
>  src/glx/dri3_glx.c| 1539 
> +
>  src/glx/dri3_priv.h   |  128 ++
>  src/glx/glxclient.h   |2 +
>  src/glx/glxext.c  |6 +-
>  src/mesa/drivers/dri/common/dri_util.c|  163 ++-
>  src/mesa/drivers/dri/common/dri_util.h|   23 +
>  src/mesa/drivers/dri/i915/intel_context.c |  109 +-
>  src/mesa/drivers/dri/i915/intel_mipmap_tree.c |   33 +
>  src/mesa/drivers/dri/i915/intel_mipmap_tree.h |8 +
>  src/mesa/drivers/dri/i965/brw_context.c   |  110 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c |   61 +
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |8 +
>  src/mesa/drivers/dri/i965/intel_screen.c  |  107 +-
>  17 files changed, 2594 insertions(+), 19 deletions(-)
>  create mode 100644 src/glx/dri3_common.c
>  create mode 100644 src/glx/dri3_glx.c
>  create mode 100644 src/glx/dri3_priv.h
> 
> diff --git a/configure.ac b/configure.ac
> index f94c9b9..b6158d9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -38,6 +38,8 @@ LIBDRM_NVVIEUX_REQUIRED=2.4.33
>  LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
>  LIBDRM_FREEDRENO_REQUIRED=2.4.39
>  DRI2PROTO_REQUIRED=2.6
> +DRI3PROTO_REQUIRED=1.0
> +LIBUDEV_REQUIRED=151
>  GLPROTO_REQUIRED=1.4.14
>  LIBDRM_XORG_REQUIRED=2.4.24
>  LIBKMS_XORG_REQUIRED=1.0.0
> @@ -820,10 +822,12 @@ xyesno)
>  fi
>  PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
>  GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
> +PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED])
> +PKG_CHECK_MODULES([LIBUDEV], [libudev >= $LIBUDEV_REQUIRED])
>  fi
>  
>  # find the DRI deps for libGL
> -dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2 
> >= 1.8"
> +dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2 
> >= 1.8 xcb-dri3 xcb-sync xshmfence"
>  
>  # add xf86vidmode if available
>  PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, 
> HAVE_XF86VIDMODE=no)
> @@ -833,8 +837,8 @@ xyesno)
>  
>  PKG_CHECK_MODULES([DRIGL], [$dri_modules])
>  GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV $dri_modules"
> -X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
> -GL_LIB_DEPS="$DRIGL_LIBS"
> +X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS"
> +GL_LIB_DEPS="$DRIGL_LIBS $LIBUDEV_LIBS"
>  
>  # need DRM libs, $PTHREAD_LIBS, etc.
>  GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index 48993b9..b06ad8d 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -86,6 +86,11 @@ typedef struct __DRIdri2LoaderExtensionRec 
> __DRIdri2LoaderExtension;
>  typedef struct __DRI2flushExtensionRec   __DRI2flushExtension;
>  typedef struct __DRI2throttleExtensionRec__DRI2throttleExtension;
>  
> +
> +typedef struct __DRIdri3BufferRec   __DRIdri3Buffer;
> +typedef struct __DRIdri3ExtensionRec__DRIdri3Extension;
> +typedef struct __DRIdri3LoaderExtensionRec  __DRIdri3LoaderExtension;
> +
>  /*@}*/
>  
>  
> @@ -966,6 +971,159 @@ struct __DRIdri2ExtensionRec {
>  
>  
>  /**
> + * DRI3 Loader extension.
> + */
> +
> +#define __DRI3_DRIVER_EXTENSIONS "__dri3DriverExtensions"
> +
> +enum __DRI3bufferType {
> +   __DRI3_BUFFER_BACK = 0,
> +   __DRI3_BUFFER_FRONT = 1
> +};
> +
> +struct __DRIdri3BufferRec {
> +   unsigned int size;
> +   unsigned int pitch;
> +   unsigned int cpp;
> +   unsigned int flags;
> +   unsigned int width, height;
> +   enum __DRI3bufferType buffer_type;
> +   uint32_t pixmap;
> +   uint32_t sync_fence;
> +   int32_t *shm_fence;
> +   void *driverPrivate;
> +};

My main concern with this patch is that I'd like to use __DRIimage for
the color buffers instead of this new __DRIdri3Buffer.  __DRIimage is
an opaque structure which we introduced for EGLImage support.  It
essentially wraps an intel_region, so it's similar to __DRI3buffer,
except it's all opaque.  __DRIimage is essentially *the* color buffer
abstraction in the DRI driver interface now and we're already using it
for color buffers in GBM and Wayland.

The intel version of __DRIimage is defined in intel_regions.h.  It's

[PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver

[Kristian Høgsberg]

On Thu, Oct 31, 2013 at 04:13:15PM -0700, Keith Packard wrote:
> This hooks DRI3 support into the GLX layer, the DRI common layer and the Intel
> driver.
> 
> Signed-off-by: Keith Packard 
> ---
>  configure.ac  |   10 +-
>  include/GL/internal/dri_interface.h   |  158 +++
>  src/glx/Makefile.am   |2 +
>  src/glx/dri3_common.c |  146 +++
>  src/glx/dri3_glx.c| 1539 
> +
>  src/glx/dri3_priv.h   |  128 ++
>  src/glx/glxclient.h   |2 +
>  src/glx/glxext.c  |6 +-
>  src/mesa/drivers/dri/common/dri_util.c|  163 ++-
>  src/mesa/drivers/dri/common/dri_util.h|   23 +
>  src/mesa/drivers/dri/i915/intel_context.c |  109 +-
>  src/mesa/drivers/dri/i915/intel_mipmap_tree.c |   33 +
>  src/mesa/drivers/dri/i915/intel_mipmap_tree.h |8 +
>  src/mesa/drivers/dri/i965/brw_context.c   |  110 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c |   61 +
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |8 +
>  src/mesa/drivers/dri/i965/intel_screen.c  |  107 +-
>  17 files changed, 2594 insertions(+), 19 deletions(-)
>  create mode 100644 src/glx/dri3_common.c
>  create mode 100644 src/glx/dri3_glx.c
>  create mode 100644 src/glx/dri3_priv.h
> 
> diff --git a/configure.ac b/configure.ac
> index f94c9b9..b6158d9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -38,6 +38,8 @@ LIBDRM_NVVIEUX_REQUIRED=2.4.33
>  LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
>  LIBDRM_FREEDRENO_REQUIRED=2.4.39
>  DRI2PROTO_REQUIRED=2.6
> +DRI3PROTO_REQUIRED=1.0
> +LIBUDEV_REQUIRED=151
>  GLPROTO_REQUIRED=1.4.14
>  LIBDRM_XORG_REQUIRED=2.4.24
>  LIBKMS_XORG_REQUIRED=1.0.0
> @@ -820,10 +822,12 @@ xyesno)
>  fi
>  PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
>  GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
> +PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED])
> +PKG_CHECK_MODULES([LIBUDEV], [libudev >= $LIBUDEV_REQUIRED])
>  fi
>  
>  # find the DRI deps for libGL
> -dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2 
> >= 1.8"
> +dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2 
> >= 1.8 xcb-dri3 xcb-sync xshmfence"
>  
>  # add xf86vidmode if available
>  PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, 
> HAVE_XF86VIDMODE=no)
> @@ -833,8 +837,8 @@ xyesno)
>  
>  PKG_CHECK_MODULES([DRIGL], [$dri_modules])
>  GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV $dri_modules"
> -X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
> -GL_LIB_DEPS="$DRIGL_LIBS"
> +X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS"
> +GL_LIB_DEPS="$DRIGL_LIBS $LIBUDEV_LIBS"
>  
>  # need DRM libs, $PTHREAD_LIBS, etc.
>  GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index 48993b9..b06ad8d 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -86,6 +86,11 @@ typedef struct __DRIdri2LoaderExtensionRec 
> __DRIdri2LoaderExtension;
>  typedef struct __DRI2flushExtensionRec   __DRI2flushExtension;
>  typedef struct __DRI2throttleExtensionRec__DRI2throttleExtension;
>  
> +
> +typedef struct __DRIdri3BufferRec   __DRIdri3Buffer;
> +typedef struct __DRIdri3ExtensionRec__DRIdri3Extension;
> +typedef struct __DRIdri3LoaderExtensionRec  __DRIdri3LoaderExtension;
> +
>  /*@}*/
>  
>  
> @@ -966,6 +971,159 @@ struct __DRIdri2ExtensionRec {
>  
>  
>  /**
> + * DRI3 Loader extension.
> + */
> +
> +#define __DRI3_DRIVER_EXTENSIONS "__dri3DriverExtensions"
> +
> +enum __DRI3bufferType {
> +   __DRI3_BUFFER_BACK = 0,
> +   __DRI3_BUFFER_FRONT = 1
> +};
> +
> +struct __DRIdri3BufferRec {
> +   unsigned int size;
> +   unsigned int pitch;
> +   unsigned int cpp;
> +   unsigned int flags;
> +   unsigned int width, height;
> +   enum __DRI3bufferType buffer_type;
> +   uint32_t pixmap;
> +   uint32_t sync_fence;
> +   int32_t *shm_fence;
> +   void *driverPrivate;
> +};

My main concern with this patch is that I'd like to use __DRIimage for
the color buffers instead of this new __DRIdri3Buffer.  __DRIimage is
an opaque structure which we introduced for EGLImage support.  It
essentially wraps an intel_region, so it's similar to __DRI3buffer,
except it's all opaque.  __DRIimage is essentially *the* color buffer
abstraction in the DRI driver interface now and we're already using it
for color buffers in GBM and Wayland.  Using __DRIimage will make
those backends and this patch simpler.

The intel version of __DRIimage is defined in intel_regions.h.  It's
more complicated than __DRIdri3Buffer since it supports planar
buffers, but at the end of the 

[PATCH 4/6] dri/intel: Add intel_fd_for_region

[Kristian Høgsberg]

On Thu, Oct 31, 2013 at 04:13:14PM -0700, Keith Packard wrote:
> Returns a prime file descriptor for the specified region.
> 
> Signed-off-by: Keith Packard 
> ---
>  src/mesa/drivers/dri/i915/intel_regions.c | 13 +
>  src/mesa/drivers/dri/i915/intel_regions.h |  4 
>  src/mesa/drivers/dri/i965/intel_regions.c | 13 +
>  src/mesa/drivers/dri/i965/intel_regions.h |  4 
>  4 files changed, 34 insertions(+)

Makes sense.  We should use that in intel_query_image() instead of
calling drm_intel_bo_gem_export_to_prime() directly on
image->region->bo.

Reviewed-by: Kristian H?gsberg 

> diff --git a/src/mesa/drivers/dri/i915/intel_regions.c 
> b/src/mesa/drivers/dri/i915/intel_regions.c
> index 9f5b89e..bac997d 100644
> --- a/src/mesa/drivers/dri/i915/intel_regions.c
> +++ b/src/mesa/drivers/dri/i915/intel_regions.c
> @@ -238,6 +238,19 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
> return region;
>  }
>  
> +int
> +intel_fd_for_region(struct intel_screen *screen,
> +struct intel_region *region)
> +{
> +   int  fd;
> +   int  ret;
> +
> +   ret = drm_intel_bo_gem_export_to_prime(region->bo, );
> +   if (ret < 0)
> +  return ret;
> +   return fd;
> +}
> +
>  void
>  intel_region_reference(struct intel_region **dst, struct intel_region *src)
>  {
> diff --git a/src/mesa/drivers/dri/i915/intel_regions.h 
> b/src/mesa/drivers/dri/i915/intel_regions.h
> index 6bc4a42..84c013a 100644
> --- a/src/mesa/drivers/dri/i915/intel_regions.h
> +++ b/src/mesa/drivers/dri/i915/intel_regions.h
> @@ -93,6 +93,10 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint width, GLuint height, GLuint pitch,
>GLuint size, int fd, const char *name);
>  
> +int
> +intel_fd_for_region(struct intel_screen *screen,
> +struct intel_region *region);
> +
>  bool
>  intel_region_flink(struct intel_region *region, uint32_t *name);
>  
> diff --git a/src/mesa/drivers/dri/i965/intel_regions.c 
> b/src/mesa/drivers/dri/i965/intel_regions.c
> index 3920f4f..2e70326 100644
> --- a/src/mesa/drivers/dri/i965/intel_regions.c
> +++ b/src/mesa/drivers/dri/i965/intel_regions.c
> @@ -238,6 +238,19 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
> return region;
>  }
>  
> +int
> +intel_fd_for_region(struct intel_screen *screen,
> +struct intel_region *region)
> +{
> +   int  fd;
> +   int  ret;
> +
> +   ret = drm_intel_bo_gem_export_to_prime(region->bo, );
> +   if (ret < 0)
> +  return ret;
> +   return fd;
> +}
> +
>  void
>  intel_region_reference(struct intel_region **dst, struct intel_region *src)
>  {
> diff --git a/src/mesa/drivers/dri/i965/intel_regions.h 
> b/src/mesa/drivers/dri/i965/intel_regions.h
> index 05dfef3..f471b94 100644
> --- a/src/mesa/drivers/dri/i965/intel_regions.h
> +++ b/src/mesa/drivers/dri/i965/intel_regions.h
> @@ -95,6 +95,10 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint size,
>int fd, const char *name);
>  
> +int
> +intel_fd_for_region(struct intel_screen *screen,
> +struct intel_region *region);
> +
>  bool
>  intel_region_flink(struct intel_region *region, uint32_t *name);
>  
> -- 
> 1.8.4.2
> 
> 
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951=/4140/ostg.clktrk
> --
> ___
> Dri-devel mailing list
> Dri-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/6] dri/intel: Split out DRI2 buffer update code to separate function

[Kristian Høgsberg]

On Thu, Oct 31, 2013 at 04:13:12PM -0700, Keith Packard wrote:
> Make an easy place to splice in a DRI3 version of this function
> 
> Signed-off-by: Keith Packard 
> ---
>  src/mesa/drivers/dri/i915/intel_context.c | 90 
> +--
>  src/mesa/drivers/dri/i965/brw_context.c   | 22 ++--
>  2 files changed, 68 insertions(+), 44 deletions(-)

Reviewed-by: Kristian H?gsberg 

> diff --git a/src/mesa/drivers/dri/i915/intel_context.c 
> b/src/mesa/drivers/dri/i915/intel_context.c
> index 2748514..1798bc7 100644
> --- a/src/mesa/drivers/dri/i915/intel_context.c
> +++ b/src/mesa/drivers/dri/i915/intel_context.c
> @@ -133,15 +133,58 @@ intel_process_dri2_buffer(struct intel_context *intel,
> struct intel_renderbuffer *rb,
> const char *buffer_name);
>  
> -void
> -intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
> +static void
> +intel_update_dri2_buffers(struct intel_context *intel, __DRIdrawable 
> *drawable)
>  {
> -   struct gl_framebuffer *fb = drawable->driverPrivate;
> -   struct intel_renderbuffer *rb;
> -   struct intel_context *intel = context->driverPrivate;
> __DRIbuffer *buffers = NULL;
> int i, count;
> const char *region_name;
> +   struct intel_renderbuffer *rb;
> +   struct gl_framebuffer *fb = drawable->driverPrivate;
> +
> +   intel_query_dri2_buffers(intel, drawable, , );
> +
> +   if (buffers == NULL)
> +  return;
> +
> +   for (i = 0; i < count; i++) {
> +  switch (buffers[i].attachment) {
> +  case __DRI_BUFFER_FRONT_LEFT:
> + rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> + region_name = "dri2 front buffer";
> + break;
> +
> +  case __DRI_BUFFER_FAKE_FRONT_LEFT:
> + rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> + region_name = "dri2 fake front buffer";
> + break;
> +
> +  case __DRI_BUFFER_BACK_LEFT:
> + rb = intel_get_renderbuffer(fb, BUFFER_BACK_LEFT);
> + region_name = "dri2 back buffer";
> + break;
> +
> +  case __DRI_BUFFER_DEPTH:
> +  case __DRI_BUFFER_HIZ:
> +  case __DRI_BUFFER_DEPTH_STENCIL:
> +  case __DRI_BUFFER_STENCIL:
> +  case __DRI_BUFFER_ACCUM:
> +  default:
> + fprintf(stderr,
> + "unhandled buffer attach event, attachment type %d\n",
> + buffers[i].attachment);
> + return;
> +  }
> +
> +  intel_process_dri2_buffer(intel, drawable, [i], rb, 
> region_name);
> +   }
> +}
> +
> +void
> +intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
> +{
> +   struct intel_context *intel = context->driverPrivate;
> +   __DRIscreen *screen = intel->intelScreen->driScrnPriv;
>  
> /* Set this up front, so that in case our buffers get invalidated
>  * while we're getting new buffers, we don't clobber the stamp and
> @@ -151,42 +194,7 @@ intel_update_renderbuffers(__DRIcontext *context, 
> __DRIdrawable *drawable)
> if (unlikely(INTEL_DEBUG & DEBUG_DRI))
>fprintf(stderr, "enter %s, drawable %p\n", __func__, drawable);
>  
> -   intel_query_dri2_buffers(intel, drawable, , );
> -
> -   if (buffers == NULL)
> -  return;
> -
> -   for (i = 0; i < count; i++) {
> -   switch (buffers[i].attachment) {
> -   case __DRI_BUFFER_FRONT_LEFT:
> -rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> -region_name = "dri2 front buffer";
> -break;
> -
> -   case __DRI_BUFFER_FAKE_FRONT_LEFT:
> -rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> -region_name = "dri2 fake front buffer";
> -break;
> -
> -   case __DRI_BUFFER_BACK_LEFT:
> -rb = intel_get_renderbuffer(fb, BUFFER_BACK_LEFT);
> -region_name = "dri2 back buffer";
> -break;
> -
> -   case __DRI_BUFFER_DEPTH:
> -   case __DRI_BUFFER_HIZ:
> -   case __DRI_BUFFER_DEPTH_STENCIL:
> -   case __DRI_BUFFER_STENCIL:
> -   case __DRI_BUFFER_ACCUM:
> -   default:
> -fprintf(stderr,
> -"unhandled buffer attach event, attachment type %d\n",
> -buffers[i].attachment);
> -return;
> -   }
> -
> -   intel_process_dri2_buffer(intel, drawable, [i], rb, 
> region_name);
> -   }
> +   intel_update_dri2_buffers(intel, drawable);
>  
> driUpdateFramebufferSize(>ctx, drawable);
>  }
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 38147e9..c213b31 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -929,12 +929,11 @@ intel_process_dri2_buffer(struct brw_context *brw,
>struct intel_renderbuffer *rb,
>const char *buffer_name);
>  
> -void
> -intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
> +static void
> +intel_update_dri2_buffers(struct brw_context *brw, 

[PATCH 1/6] drivers/dri/common: A few dri2 functions are not actually DRI2 specific

[Kristian Høgsberg]

On Thu, Oct 31, 2013 at 04:13:11PM -0700, Keith Packard wrote:
> This just renames them so that they can be used with the DRI3 extension
> without causing too much confusion.
> 
> Signed-off-by: Keith Packard 
> ---
>  src/mesa/drivers/dri/common/dri_util.c | 50 
> +-
>  1 file changed, 25 insertions(+), 25 deletions(-)

Reviewed-by: Kristian H?gsberg 

> diff --git a/src/mesa/drivers/dri/common/dri_util.c 
> b/src/mesa/drivers/dri/common/dri_util.c
> index c28b0fc..539fb4b 100644
> --- a/src/mesa/drivers/dri/common/dri_util.c
> +++ b/src/mesa/drivers/dri/common/dri_util.c
> @@ -291,13 +291,13 @@ validate_context_version(__DRIscreen *screen,
>  /*@{*/
>  
>  static __DRIcontext *
> -dri2CreateContextAttribs(__DRIscreen *screen, int api,
> -  const __DRIconfig *config,
> -  __DRIcontext *shared,
> -  unsigned num_attribs,
> -  const uint32_t *attribs,
> -  unsigned *error,
> -  void *data)
> +driCreateContextAttribs(__DRIscreen *screen, int api,
> +const __DRIconfig *config,
> +__DRIcontext *shared,
> +unsigned num_attribs,
> +const uint32_t *attribs,
> +unsigned *error,
> +void *data)
>  {
>  __DRIcontext *context;
>  const struct gl_config *modes = (config != NULL) ? >modes : NULL;
> @@ -442,22 +442,22 @@ dri2CreateContextAttribs(__DRIscreen *screen, int api,
>  }
>  
>  static __DRIcontext *
> -dri2CreateNewContextForAPI(__DRIscreen *screen, int api,
> -const __DRIconfig *config,
> -__DRIcontext *shared, void *data)
> +driCreateNewContextForAPI(__DRIscreen *screen, int api,
> +  const __DRIconfig *config,
> +  __DRIcontext *shared, void *data)
>  {
>  unsigned error;
>  
> -return dri2CreateContextAttribs(screen, api, config, shared, 0, NULL,
> - , data);
> +return driCreateContextAttribs(screen, api, config, shared, 0, NULL,
> +   , data);
>  }
>  
>  static __DRIcontext *
> -dri2CreateNewContext(__DRIscreen *screen, const __DRIconfig *config,
> -   __DRIcontext *shared, void *data)
> +driCreateNewContext(__DRIscreen *screen, const __DRIconfig *config,
> +__DRIcontext *shared, void *data)
>  {
> -return dri2CreateNewContextForAPI(screen, __DRI_API_OPENGL,
> -   config, shared, data);
> +return driCreateNewContextForAPI(screen, __DRI_API_OPENGL,
> + config, shared, data);
>  }
>  
>  /**
> @@ -609,9 +609,9 @@ static void dri_put_drawable(__DRIdrawable *pdp)
>  }
>  
>  static __DRIdrawable *
> -dri2CreateNewDrawable(__DRIscreen *screen,
> -   const __DRIconfig *config,
> -   void *data)
> +driCreateNewDrawable(__DRIscreen *screen,
> + const __DRIconfig *config,
> + void *data)
>  {
>  __DRIdrawable *pdraw;
>  
> @@ -698,7 +698,7 @@ dri2ConfigQueryf(__DRIscreen *screen, const char *var, 
> GLfloat *val)
>  }
>  
>  static unsigned int
> -dri2GetAPIMask(__DRIscreen *screen)
> +driGetAPIMask(__DRIscreen *screen)
>  {
>  return screen->api_mask;
>  }
> @@ -741,13 +741,13 @@ const __DRIdri2Extension driDRI2Extension = {
>  .base = { __DRI_DRI2, 4 },
>  
>  .createNewScreen= dri2CreateNewScreen,
> -.createNewDrawable  = dri2CreateNewDrawable,
> -.createNewContext   = dri2CreateNewContext,
> -.getAPIMask = dri2GetAPIMask,
> -.createNewContextForAPI = dri2CreateNewContextForAPI,
> +.createNewDrawable  = driCreateNewDrawable,
> +.createNewContext   = driCreateNewContext,
> +.getAPIMask = driGetAPIMask,
> +.createNewContextForAPI = driCreateNewContextForAPI,
>  .allocateBuffer = dri2AllocateBuffer,
>  .releaseBuffer  = dri2ReleaseBuffer,
> -.createContextAttribs   = dri2CreateContextAttribs,
> +.createContextAttribs   = driCreateContextAttribs
>  .createNewScreen2   = dri2CreateNewScreen2,
>  };
>  
> -- 
> 1.8.4.2
> 
> 
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951=/4140/ostg.clktrk
> --
> ___
> Dri-devel mailing list
> Dri-devel at lists.sourceforge.net
> 

[PATCH] intel: Set bo size from lseek if kernel supports it

[Kristian Høgsberg]

The various create and open functions set the buffer size, but
drm_intel_bo_gem_create_from_prime() is an exception.  In the 3.12 kernel
we can now use lseek on the prime fd to determine the size of the bo.
Use that and override the userprovided size.  If the kernel doesn't
support this, we get an error and fall back to the user provided size.

Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
 intel/intel_bufmgr_gem.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index f98f7a7..278f5c8 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2452,7 +2452,17 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr 
*bufmgr, int prime_fd, int s
if (!bo_gem)
return NULL;
 
-   bo_gem-bo.size = size;
+   /* Determine size of bo.  The fd-to-handle ioctl really should
+* return the size, but it doesn't.  If we have kernel 3.12 or
+* later, we can lseek on the prime fd to get the size.  Older
+* kernels will just fail, in which case we fall back to the
+* provided (estimated or guess size). */
+   ret = lseek(prime_fd, 0, SEEK_END);
+   if (ret != -1)
+   bo_gem-bo.size = ret;
+   else
+   bo_gem-bo.size = size;
+
bo_gem-bo.handle = handle;
bo_gem-bo.bufmgr = bufmgr;
 
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 5/6] drm/i915: Support render nodes

[Kristian Høgsberg]

On Fri, Aug 23, 2013 at 4:29 AM, Chris Wilson  
wrote:
> On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
>> From: Kristian H?gsberg 
>>
>> Enable support for drm render nodes for i915 by flagging the ioctls that
>> are safe and just needed for rendering.
>>
>> Cc: Daniel Vetter 
>> Signed-off-by: Kristian H?gsberg 
>> Signed-off-by: David Herrmann 
>> ---
>>  drivers/gpu/drm/i915/i915_dma.c | 36 ++--
>>  drivers/gpu/drm/i915/i915_drv.c |  3 ++-
>>  2 files changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c 
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index 0adfe40..ecf5ecd 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -1840,7 +1840,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>>   DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
>>   DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
>>   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
>> - DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
>> + DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
>> DRM_AUTH|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>>   DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
>>   DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
>> @@ -1853,34 +1853,34 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>>   DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
>> DRM_AUTH|DRM_UNLOCKED),
> execbuffer also
>
>> - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
>> DRM_AUTH|DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
>> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
>> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
>> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
>> DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
>> DRM_UNLOCKED),
> set/get caching
>
>> - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
>> DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, 

Re: [PATCH v2 5/6] drm/i915: Support render nodes

[Kristian Høgsberg]

On Fri, Aug 23, 2013 at 4:29 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
 From: Kristian Høgsberg k...@bitplanet.net

 Enable support for drm render nodes for i915 by flagging the ioctls that
 are safe and just needed for rendering.

 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Signed-off-by: Kristian Høgsberg k...@bitplanet.net
 Signed-off-by: David Herrmann dh.herrm...@gmail.com
 ---
  drivers/gpu/drm/i915/i915_dma.c | 36 ++--
  drivers/gpu/drm/i915/i915_drv.c |  3 ++-
  2 files changed, 20 insertions(+), 19 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_dma.c 
 b/drivers/gpu/drm/i915/i915_dma.c
 index 0adfe40..ecf5ecd 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -1840,7 +1840,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
   DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
   DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
 - DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
 + DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
 DRM_AUTH|DRM_RENDER_ALLOW),
   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
   DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
   DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
 @@ -1853,34 +1853,34 @@ const struct drm_ioctl_desc i915_ioctls[] = {
   DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
   DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
 DRM_AUTH|DRM_UNLOCKED),
 execbuffer also

 - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
 DRM_AUTH|DRM_UNLOCKED),
 + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
 DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
   DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
 DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
   DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
 DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
 DRM_AUTH|DRM_UNLOCKED),
 + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
 DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
   DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
 DRM_UNLOCKED),
   DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
 DRM_UNLOCKED),
 set/get caching

 - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
 DRM_AUTH|DRM_UNLOCKED),
 + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
 DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
   DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
   DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
 DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
 DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
 DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
 DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
 DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
 DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
 DRM_UNLOCKED),
 - DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
 DRM_UNLOCKED),
 + DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
 + DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
 + DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
 + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
 + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
 + DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
 + DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
 + DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
 + DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
 + DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
   DRM_IOCTL_DEF_DRV

[RFC 1/4] time: export getnstime_raw_and_real for DRM

[Kristian Høgsberg]

On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak  wrote:
> Needed by the upcoming DRM raw monotonic timestamp support.

I just had a quick look at driver/input/evdev.c, since evdev devices
did a similar change recently to allow evdev timestamp from the
monotonic clock.  They're using a different time API:

time_mono = ktime_get();
time_real = ktime_sub(time_mono, ktime_get_monotonic_offset());

and

event->time = ktime_to_timeval(client->clkid == CLOCK_MONOTONIC ?
mono : real);

I'm not really up-to-date on kernel time APIs, but I wonder if that
may be better?  At least, I suspect we wouldn't need changes outside
drm if we use this API.

Kristian


> Signed-off-by: Imre Deak 
> ---
>  kernel/time/timekeeping.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index d3b91e7..073d262 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -365,7 +365,7 @@ void ktime_get_ts(struct timespec *ts)
>  }
>  EXPORT_SYMBOL_GPL(ktime_get_ts);
>
> -#ifdef CONFIG_NTP_PPS
> +#if defined(CONFIG_NTP_PPS) || defined(CONFIG_DRM) || 
> defined(CONFIG_DRM_MODULE)
>
>  /**
>   * getnstime_raw_and_real - get day and raw monotonic time in timespec format
> --
> 1.7.9.5
>

[PATCH 2/3] drm: Add support for render nodes

[Kristian Høgsberg]

This patch introduces a new kind of drm device node: the render node.
A render node exposes a safe subset of the legacy drm device ioctls and can
only be used for rendering.  The legacy node supports modesetting, DRI1
and global buffer sharing, while the render node only supports rendering
and limited buffer sharing.  A render node can either export a buffer using
the gem flink mechanism, or it can import and export buffers using the
prime fd passing mechanism.

A render node is not associated with any drm master and does not require
the legacy authentication step.  Render nodes can be used without
a master, potentially in headless setups such as video-transcoding or
GPGPU work.

Signed-off-by: Kristian H?gsberg 
---
 drivers/gpu/drm/drm_drv.c  |   13 +++--
 drivers/gpu/drm/drm_fops.c |9 ++---
 drivers/gpu/drm/drm_pci.c  |9 +
 include/drm/drmP.h |3 +++
 4 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9238de4..2876e17 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -131,14 +131,14 @@ static struct drm_ioctl_desc drm_ioctls[] = {

DRM_IOCTL_DEF(DRM_IOCTL_UPDATE_DRAW, drm_noop, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),

-   DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, DRM_UNLOCKED | 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, 
DRM_AUTH|DRM_UNLOCKED | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, 
DRM_AUTH|DRM_UNLOCKED),

DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),

-   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),

DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
@@ -427,9 +427,10 @@ long drm_ioctl(struct file *filp,
DRM_DEBUG("no function\n");
retcode = -EINVAL;
} else if (((ioctl->flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN)) 
||
-  ((ioctl->flags & DRM_AUTH) && !file_priv->authenticated) ||
+  ((ioctl->flags & DRM_AUTH) && (file_priv->minor->type != 
DRM_MINOR_RENDER) && !file_priv->authenticated) ||
   ((ioctl->flags & DRM_MASTER) && !file_priv->is_master) ||
-  (!(ioctl->flags & DRM_CONTROL_ALLOW) && 
(file_priv->minor->type == DRM_MINOR_CONTROL))) {
+  (!(ioctl->flags & DRM_CONTROL_ALLOW) && 
(file_priv->minor->type == DRM_MINOR_CONTROL)) ||
+  (!(ioctl->flags & DRM_RENDER_ALLOW) && 
(file_priv->minor->type == DRM_MINOR_RENDER))) {
retcode = -EACCES;
} else {
if (cmd & (IOC_IN | IOC_OUT)) {
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 5062eec..bee4244 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -279,7 +279,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,

/* if there is no current master make this fd it */
mutex_lock(>struct_mutex);
-   if (!priv->minor->master) {
+   if (!priv->minor->master && priv->minor->type != DRM_MINOR_RENDER) {
/* create a new master */
priv->minor->master = drm_master_create(priv->minor);
if (!priv->minor->master) {
@@ -318,10 +318,12 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
}
}
mutex_unlock(>struct_mutex);
-   } else {
+   } else if (priv->minor->type != DRM_MINOR_RENDER) {
/* get a reference to the master */
priv->master = drm_master_get(priv->minor->master);
mutex_unlock(>struct_mutex);
+   } else {
+   mutex_unlock(>struct_mutex);
}

mutex_lock(>struct_mutex);
@@ -513,7 +515,8 @@ int drm_release(struct inode *inode, struct file *filp)
iput(container_of(dev->dev_mapping, struct inode, i_data));

/* drop the reference held my the file priv */
-   drm_master_put(_priv->master);
+   if (file_priv->master)
+   drm_master_put(_priv->master);
file_priv->is_master = 0;
list_del(_priv->lhead);
   

[PATCH 1/3] drm: Fix DRM_MINOR limits for control and render nodes

[Kristian Høgsberg]

We got the minor number base right, but limit is too big and causes the
minor numer ranges for the control and render nodes to overlap.

Signed-off-by: Kristian H?gsberg 
---
 drivers/gpu/drm/drm_stub.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 21bcd4a..d6d5160 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -107,10 +107,10 @@ static int drm_minor_get_id(struct drm_device *dev, int 
type)

if (type == DRM_MINOR_CONTROL) {
 base += 64;
-limit = base + 127;
+limit = base + 64;
 } else if (type == DRM_MINOR_RENDER) {
 base += 128;
-limit = base + 255;
+limit = base + 64;
 }

 again:
-- 
1.7.10.2

[PATCH 0/3] [RFC] DRM Render Nodes

[Kristian Høgsberg]

Here's the patch to implement render nodes as discussed in the "DRM2"
talk at XDC:

  http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2

The core problem is that DRM security is compromised in the face of
VT switching and multiple DRM masters.  Any local user can access all
shared buffers from within any X server on the system, even when that
user doesn't have access to any of those X servers.

The fix for this is to use dmabuf/prime and fd passing for buffer sharing.
That infrastructure is already in place and we need to start using that in
user space.  Once we're passing buffers between display servers and clients
in a point-to-point fashion, we no longer need to authenticate clients.  We
just need to make sure they can only render and import/export buffers to
fds.  That's what this patch does, by creating a new type of drm device
node.  Accessing this node doesn't require authentication (and as such
can be used without a master, ie headless), but will only expose the safe,
modern (DRI2ish) rendering ioctls.

Once userspace is sharing buffers through fd passing, the legacy card0 node
can be locked down by unix permissions, for example in a drm-master group,
so that only setgid binaries (X, weston, other KMS apps) can access it.

Kristian


See also:

http://wiki.x.org/wiki/Events/XDC2012/Proceedings#Graphics_stack_security

https://lwn.net/Articles/517375/

[PATCH 0/3] [RFC] DRM Render Nodes

[Kristian Høgsberg]

Here's the patch to implement render nodes as discussed in the DRM2
talk at XDC:

  http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2

The core problem is that DRM security is compromised in the face of
VT switching and multiple DRM masters.  Any local user can access all
shared buffers from within any X server on the system, even when that
user doesn't have access to any of those X servers.

The fix for this is to use dmabuf/prime and fd passing for buffer sharing.
That infrastructure is already in place and we need to start using that in
user space.  Once we're passing buffers between display servers and clients
in a point-to-point fashion, we no longer need to authenticate clients.  We
just need to make sure they can only render and import/export buffers to
fds.  That's what this patch does, by creating a new type of drm device
node.  Accessing this node doesn't require authentication (and as such
can be used without a master, ie headless), but will only expose the safe,
modern (DRI2ish) rendering ioctls.

Once userspace is sharing buffers through fd passing, the legacy card0 node
can be locked down by unix permissions, for example in a drm-master group,
so that only setgid binaries (X, weston, other KMS apps) can access it.

Kristian


See also:

http://wiki.x.org/wiki/Events/XDC2012/Proceedings#Graphics_stack_security

https://lwn.net/Articles/517375/

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm: Fix DRM_MINOR limits for control and render nodes

[Kristian Høgsberg]

We got the minor number base right, but limit is too big and causes the
minor numer ranges for the control and render nodes to overlap.

Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
 drivers/gpu/drm/drm_stub.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 21bcd4a..d6d5160 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -107,10 +107,10 @@ static int drm_minor_get_id(struct drm_device *dev, int 
type)
 
if (type == DRM_MINOR_CONTROL) {
 base += 64;
-limit = base + 127;
+limit = base + 64;
 } else if (type == DRM_MINOR_RENDER) {
 base += 128;
-limit = base + 255;
+limit = base + 64;
 }
 
 again:
-- 
1.7.10.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Sync the mode flags for the stereo 3D formats

[Kristian Høgsberg]

On Wed, Sep 12, 2012 at 06:47:56PM +0100, Damien Lespiau wrote:
 From: Damien Lespiau damien.lesp...@intel.com
 
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  include/drm/drm_mode.h | 35 +--
  xf86drmMode.h  | 35 +--
  2 files changed, 42 insertions(+), 28 deletions(-)
 
 diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
 index 62ba997..1ab936c 100644
 --- a/include/drm/drm_mode.h
 +++ b/include/drm/drm_mode.h
 @@ -42,20 +42,27 @@
  
  /* Video mode flags */
  /* bit compatible with the xorg definitions. */
 -#define DRM_MODE_FLAG_PHSYNC (10)
 -#define DRM_MODE_FLAG_NHSYNC (11)
 -#define DRM_MODE_FLAG_PVSYNC (12)
 -#define DRM_MODE_FLAG_NVSYNC (13)
 -#define DRM_MODE_FLAG_INTERLACE  (14)
 -#define DRM_MODE_FLAG_DBLSCAN(15)
 -#define DRM_MODE_FLAG_CSYNC  (16)
 -#define DRM_MODE_FLAG_PCSYNC (17)
 -#define DRM_MODE_FLAG_NCSYNC (18)
 -#define DRM_MODE_FLAG_HSKEW  (19) /* hskew provided */
 -#define DRM_MODE_FLAG_BCAST  (110)
 -#define DRM_MODE_FLAG_PIXMUX (111)
 -#define DRM_MODE_FLAG_DBLCLK (112)
 -#define DRM_MODE_FLAG_CLKDIV2(113)
 +#define DRM_MODE_FLAG_PHSYNC (10)
 +#define DRM_MODE_FLAG_NHSYNC (11)
 +#define DRM_MODE_FLAG_PVSYNC (12)
 +#define DRM_MODE_FLAG_NVSYNC (13)
 +#define DRM_MODE_FLAG_INTERLACE  (14)
 +#define DRM_MODE_FLAG_DBLSCAN(15)
 +#define DRM_MODE_FLAG_CSYNC  (16)
 +#define DRM_MODE_FLAG_PCSYNC (17)
 +#define DRM_MODE_FLAG_NCSYNC (18)
 +#define DRM_MODE_FLAG_HSKEW  (19) /* hskew provided */
 +#define DRM_MODE_FLAG_BCAST  (110)
 +#define DRM_MODE_FLAG_PIXMUX (111)
 +#define DRM_MODE_FLAG_DBLCLK (112)
 +#define DRM_MODE_FLAG_CLKDIV2(113)
 +#define DRM_MODE_FLAG_3D_TOP_BOTTOM  (114)
 +#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF   (115)
 +#define DRM_MODE_FLAG_3D_FRAME_PACKING   (116)
 +
 +#define DRM_MODE_FLAG_3D_MASK(DRM_MODE_FLAG_3D_TOP_BOTTOM |  
 \
 +  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF |   \
 +  DRM_MODE_FLAG_3D_FRAME_PACKING)

This is really an enum, right?  Should we just use two bits?

  
  /* DPMS flags */
  /* bit compatible with the xorg definitions. */
 diff --git a/xf86drmMode.h b/xf86drmMode.h
 index 8e40034..f88522e 100644
 --- a/xf86drmMode.h
 +++ b/xf86drmMode.h
 @@ -81,20 +81,27 @@ extern C {
  
  /* Video mode flags */
  /* bit compatible with the xorg definitions. */
 -#define DRM_MODE_FLAG_PHSYNC(10)
 -#define DRM_MODE_FLAG_NHSYNC(11)
 -#define DRM_MODE_FLAG_PVSYNC(12)
 -#define DRM_MODE_FLAG_NVSYNC(13)
 -#define DRM_MODE_FLAG_INTERLACE (14)
 -#define DRM_MODE_FLAG_DBLSCAN   (15)
 -#define DRM_MODE_FLAG_CSYNC (16)
 -#define DRM_MODE_FLAG_PCSYNC(17)
 -#define DRM_MODE_FLAG_NCSYNC(18)
 -#define DRM_MODE_FLAG_HSKEW (19) /* hskew provided */
 -#define DRM_MODE_FLAG_BCAST (110)
 -#define DRM_MODE_FLAG_PIXMUX(111)
 -#define DRM_MODE_FLAG_DBLCLK(112)
 -#define DRM_MODE_FLAG_CLKDIV2   (113)
 +#define DRM_MODE_FLAG_PHSYNC (10)
 +#define DRM_MODE_FLAG_NHSYNC (11)
 +#define DRM_MODE_FLAG_PVSYNC (12)
 +#define DRM_MODE_FLAG_NVSYNC (13)
 +#define DRM_MODE_FLAG_INTERLACE  (14)
 +#define DRM_MODE_FLAG_DBLSCAN(15)
 +#define DRM_MODE_FLAG_CSYNC  (16)
 +#define DRM_MODE_FLAG_PCSYNC (17)
 +#define DRM_MODE_FLAG_NCSYNC (18)
 +#define DRM_MODE_FLAG_HSKEW  (19) /* hskew provided */
 +#define DRM_MODE_FLAG_BCAST  (110)
 +#define DRM_MODE_FLAG_PIXMUX (111)
 +#define DRM_MODE_FLAG_DBLCLK (112)
 +#define DRM_MODE_FLAG_CLKDIV2(113)
 +#define DRM_MODE_FLAG_3D_TOP_BOTTOM  (114)
 +#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF   (115)
 +#define DRM_MODE_FLAG_3D_FRAME_PACKING   (116)
 +
 +#define DRM_MODE_FLAG_3D_MASK(DRM_MODE_FLAG_3D_TOP_BOTTOM |  
 \
 +  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF |   \
 +  DRM_MODE_FLAG_3D_FRAME_PACKING)
  
  /* DPMS flags */
  /* bit compatible with the xorg definitions. */
 -- 
 1.7.11.4
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] tests/testdisplay: Test the stereo 3D modes

[Kristian Høgsberg]

On Wed, Sep 12, 2012 at 06:48:19PM +0100, Damien Lespiau wrote:
 From: Damien Lespiau damien.lesp...@intel.com
 
 Now that modes have flags to describe which 3d formats the sink
 supports, it's time to test them.
 
 The new test cycles through the supported 3D formats and paint 3D
 stereoscopic images taken from publicly available samples:
   http://www.quantumdata.com/apps/3D/sample_BMP.asp
 
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  tests/1080FP.png| Bin 0 - 2291944 bytes
  tests/1080TB.png| Bin 0 - 1137594 bytes
  tests/720FP.png | Bin 0 - 1088754 bytes
  tests/720TB.png | Bin 0 - 555755 bytes
  tests/testdisplay.c | 216 
 +++-
  5 files changed, 213 insertions(+), 3 deletions(-)
  create mode 100644 tests/1080FP.png
  create mode 100644 tests/1080TB.png
  create mode 100644 tests/720FP.png
  create mode 100644 tests/720TB.png
 
 diff --git a/tests/1080FP.png b/tests/1080FP.png

snip stereoscopic base64

 literal 0
 HcmV?d1
 
 diff --git a/tests/testdisplay.c b/tests/testdisplay.c
 index c52bb2f..77d1503 100644
 --- a/tests/testdisplay.c
 +++ b/tests/testdisplay.c
 @@ -52,6 +52,7 @@
  #include errno.h
  #include math.h
  #include stdint.h
 +#include strings.h
  #include unistd.h
  #include sys/poll.h
  #include sys/time.h
 @@ -68,7 +69,7 @@
  drmModeRes *resources;
  int drm_fd, modes;
  int dump_info = 0, test_all_modes =0, test_preferred_mode = 0, force_mode = 
 0,
 - test_plane, enable_tiling;
 + test_plane, test_3d_modes, enable_tiling;
  int sleep_between_modes = 5;
  uint32_t depth = 24, stride, bpp;
  int qr_code = 0;
 @@ -153,6 +154,11 @@ struct connector {
   drmModeConnector *connector;
   int crtc;
   int pipe;
 +
 + /* stereo 3d */
 + int s3d_format;
 + uint32_t s3d_property_id;
 + char s3d_image[32];
  };
  
  static void dump_connectors_fd(int drmfd)
 @@ -554,6 +560,193 @@ set_mode(struct connector *c)
   drmModeFreeConnector(c-connector);
  }
  
 +static void
 +paint_3d_image(cairo_t *cr, int l_width, int l_height, void *priv)
 +{
 + struct connector *c = priv;
 + cairo_surface_t *image;
 +
 + image = cairo_image_surface_create_from_png(c-s3d_image);
 +
 + cairo_set_source_surface(cr, image, 0, 0);
 + cairo_paint(cr);
 +
 + cairo_surface_destroy(image);
 +}
 +
 +static void adjust_3d_timings(drmModeModeInfo *mode, unsigned int format)
 +{
 + uint16_t vdisplay, vactive_space;
 +
 + /* just set the 3D format we are setting (this is not used by the
 +  * kernel, it's just for kmstest_dump_mode()) */
 + mode-flags = ~DRM_MODE_FLAG_3D_MASK;
 + mode-flags |= format;
 +
 + switch (format) {
 + case DRM_MODE_FLAG_3D_TOP_BOTTOM:
 + case DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF:
 + return;
 + case DRM_MODE_FLAG_3D_FRAME_PACKING:
 + vactive_space = mode-vtotal - mode-vdisplay;
 + vdisplay = mode-vdisplay;
 +
 + mode-vdisplay += vdisplay + vactive_space;
 + mode-vsync_start += vdisplay + vactive_space;
 + mode-vsync_end += vdisplay + vactive_space;
 + mode-vtotal += vdisplay + vactive_space;
 + mode-clock = (mode-vtotal * mode-htotal * mode-vrefresh) /
 +   1000;
 + return;
 + default:
 + assert(0);
 + }
 +}
 +
 +static const char *s3d_format_str(unsigned int format)
 +{
 + switch(format) {
 + case DRM_MODE_FLAG_3D_TOP_BOTTOM:
 + return TB;
 + case DRM_MODE_FLAG_3D_FRAME_PACKING:
 + return FP;
 + }
 +
 + return Unknown format;
 +}
 +
 +static void do_set_3d_format(struct connector *c, unsigned int format)
 +{
 + uint32_t fb_id;
 + struct kmstest_fb fb_info;
 +
 + snprintf(c-s3d_image, sizeof(c-s3d_image), %d%s.png,
 +  c-mode.vdisplay, s3d_format_str(format));
 +
 + adjust_3d_timings(c-mode, format);
 + width = c-mode.hdisplay;
 + height = c-mode.vdisplay;
 +
 + fb_id = kmstest_create_fb(drm_fd, width, height, bpp, depth,
 +   enable_tiling, fb_info,
 +   paint_3d_image, c);
 +
 + fb_ptr = gem_mmap(drm_fd, fb_info.gem_handle,
 +   fb_info.size, PROT_READ | PROT_WRITE);
 + assert(fb_ptr);
 +
 + gem_close(drm_fd, fb_info.gem_handle);
 +
 + kmstest_dump_mode(c-mode);
 +
 + if (drmModeConnectorSetProperty(drm_fd,
 + c-id,
 + c-s3d_property_id,
 + format)) {
 + fprintf(stderr, failed to set \select 3D mode\ 
 + property to %d: %s\n, 1, strerror(errno));
 + }

I agree with Chris that this would be better done as part of the mode.
We can do it in a way that doesn't break backwards compatibility by
having an please actually use the 3d mode bits in the mode 

Re: [RFC 0/9] nuclear pageflip

[Kristian Høgsberg]

On Fri, Sep 14, 2012 at 5:14 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Wed, 12 Sep 2012 21:58:31 +0300
 Ville Syrjälä ville.syrj...@linux.intel.com wrote:

 On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote:
  On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä
  ville.syrj...@linux.intel.com wrote:
   On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote:
   But I think we could still do this w/ one ioctl per crtc for 
   atomic-pageflip.
  
   We could, if we want to sacrifice the synced multi display case. I just
   think it might be a real use case at some point. IVI feels like the most
   likely short term cadidate to me, but perhaps someone would finally
   introduce some new style phone/tablet thingy. I have seen
   concepts/prototypes of such multi display gadgets in the past, but the
   industry apparently got a bit stuck on the rectangular slab with
   touchscreen on one side design.
 
  I could be wrong, but I think IVI the screens would normally be too
  far apart to matter?

 I was thinking of something like a display on the dash that normally
 sits low with only a small sliver visible, and extends upwards when
 you fire up a movie player for example. Internally it could be made
 up of two displays for power savings purposes.

  Anyways, it is really only a problem if you can't do two ioctl()s
  within one vblank period. If it actually turns out to be a real
  problem,

 Well exactly that's the problem this whole atomic pageflip stuff is
 trying to tackle, no? ;)

  we could always add later an ioctl that takes an array of
  'struct drm_mode_crtc_atomic_page_flip's.  I'm not sure if this is
  really useful or not.. but maybe I'm thinking too much about how
  weston does it's rendering of different output's independently.

 I'm just now thinking of surfaceflinger's way of doing things, with
 its prepare and commit phases. If you need to issue two ioctls to handle
 cloned displays, then you can end up in a somewhat funky situation.

 Let's say you have a video overlay in use (one each display naturally),
 and you increase the downscaling factor enough so that you now have
 enough memory bandwith to support only one overlay. With independent
 check ioctls for each display, you never have the full device state
 available in the kernel, so each check succeeds during the prepare
 phase. So you decide that you can keep using the video overlays.

 You then proceed to commit the state, but after the first display has
 been commited you get an error when trying to commit the second one.
 What can you do now? The only option is to keep displaying the old
 frame on the other displays for some time longer, and then on the
 next frame you can switch to GPU composition. But on the next frame you
 perhaps no longer need to use GPU composition, but since you can't
 verify that in the prepare phase, you have no other option but to use
 GPU composition.

 So when you run into a configuration that can be supported only
 partially, you get animation stalls on some displays due to skipped
 frames, and you always have to fall back to GPU composition for the
 next frame.

 If on the other hand you would check the whole state in one ioctl,
 you'd get the error in the first prepare phase, and could fall back
 to GPU composition immediately.

 Am I too much of a perfectionst in considering such things? I don't
 think so, but perhaps other people disagree.

 I don't think there's any harm in having multiple ioctls for different
 things.

 I was initially hoping the nuclear page flip would be very simple.
 Intended for simply updating buffers of several planes associated with
 a single display.  That makes the inner loop of something like Wayland
 or SF simple, but obviously doesn't cover every case (in fact I had
 avoided dealing with moving planes initially).

 Rob's patchset goes further than that, but obviously not as far as you
 propose.

 OTOH, keeping things really simple and not very featureful means there
 are fewer points of failure, which is what I think callers would expect
 from a flip API...

 So where does that leave us?  I'd propose we have a very simple,
 stripped down, single crtc flip ioctl, along with a big atomic mode set
 ioctl, and then perhaps a fancier multi-crtc flip ioctl.

I think (hope) the consensus coming out of this thread is something
along these lines:

 - We use properties for specifying what to change to be future
compatible with new crtc features, but also to allow exposing
hw-specific properties and tie them into the atomicity of the
pageflip.  The KMS overlays are a lowest-common denominator for all
the various overlay types out there and it should be possible to write
a piece of chipset specific compositor code to use features that can't
be expressed through KMS overlays.

 - We have two types of properties: dynamic and non-dynamic ones.
Dynamic properties can always be changed in the next frame (fb bos, hw
cursor position, overlay position, for example), 

[PATCH] intel: Mark bo's exported to prime as not reusable

[Kristian Høgsberg]

On Fri, Sep 14, 2012 at 5:03 PM, Chris Wilson  
wrote:
> On Fri, 14 Sep 2012 17:01:18 -0400, Kristian H?gsberg  
> wrote:
>> On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson  
>> wrote:
>> > On Fri, 14 Sep 2012 16:37:53 -0400, Kristian H?gsberg > > bitplanet.net> wrote:
>> >> It's the same situation as flink and we need take the same pre-cautions.
>> >> ---
>> >>  intel/intel_bufmgr_gem.c |8 +++-
>> >>  1 file changed, 7 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
>> >> index 3bcc849..92c0444 100644
>> >> --- a/intel/intel_bufmgr_gem.c
>> >> +++ b/intel/intel_bufmgr_gem.c
>> >> @@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, 
>> >> int *prime_fd)
>> >>  {
>> >>   drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) 
>> >> bo->bufmgr;
>> >>   drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
>> >> + int ret;
>> >>
>> >> - return drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle, 
>> >> DRM_CLOEXEC, prime_fd);
>> >> + ret = drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
>> >> +  DRM_CLOEXEC, prime_fd);
>> >> + if (ret == 0)
>> >> + bo_gem->reusable = false;
>> >
>> > Now that you mention it...
>> > To be consistent with libdrm_intel, we should return -errno on error; so
>> > rephrasing this as
>> >   if (ret)
>> > return -errno;
>> >
>> >   bo_gem->reusable = false;
>> >   return 0;
>> >
>> > would work better.
>>
>> Argh, yes, I copy and pasted that from drm_intel_gem_bo_flink() but
>> edited it away later...  with that change, can I add your reviewed-by
>> and commit?
>
> Yes,
>
> Reviewed-by: Chris Wilson 
> -Chris

Thanks, pushed.  Btw, before this patch,
drm_intel_bo_gem_export_to_prime() was actually just returning the
drmPrimeHandleToFD() return value directly, not -errno on error.

Kristian

[RFC 0/9] nuclear pageflip

[Kristian Høgsberg]

On Fri, Sep 14, 2012 at 5:14 PM, Jesse Barnes  
wrote:
> On Wed, 12 Sep 2012 21:58:31 +0300
> Ville Syrj?l?  wrote:
>
>> On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote:
>> > On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrj?l?
>> >  wrote:
>> > > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote:
>> > >> But I think we could still do this w/ one ioctl per crtc for 
>> > >> atomic-pageflip.
>> > >
>> > > We could, if we want to sacrifice the synced multi display case. I just
>> > > think it might be a real use case at some point. IVI feels like the most
>> > > likely short term cadidate to me, but perhaps someone would finally
>> > > introduce some new style phone/tablet thingy. I have seen
>> > > concepts/prototypes of such multi display gadgets in the past, but the
>> > > industry apparently got a bit stuck on the rectangular slab with
>> > > touchscreen on one side design.
>> >
>> > I could be wrong, but I think IVI the screens would normally be too
>> > far apart to matter?
>>
>> I was thinking of something like a display on the dash that normally
>> sits low with only a small sliver visible, and extends upwards when
>> you fire up a movie player for example. Internally it could be made
>> up of two displays for power savings purposes.
>>
>> > Anyways, it is really only a problem if you can't do two ioctl()s
>> > within one vblank period. If it actually turns out to be a real
>> > problem,
>>
>> Well exactly that's the problem this whole atomic pageflip stuff is
>> trying to tackle, no? ;)
>>
>> > we could always add later an ioctl that takes an array of
>> > 'struct drm_mode_crtc_atomic_page_flip's.  I'm not sure if this is
>> > really useful or not.. but maybe I'm thinking too much about how
>> > weston does it's rendering of different output's independently.
>>
>> I'm just now thinking of surfaceflinger's way of doing things, with
>> its prepare and commit phases. If you need to issue two ioctls to handle
>> cloned displays, then you can end up in a somewhat funky situation.
>>
>> Let's say you have a video overlay in use (one each display naturally),
>> and you increase the downscaling factor enough so that you now have
>> enough memory bandwith to support only one overlay. With independent
>> check ioctls for each display, you never have the full device state
>> available in the kernel, so each check succeeds during the prepare
>> phase. So you decide that you can keep using the video overlays.
>>
>> You then proceed to commit the state, but after the first display has
>> been commited you get an error when trying to commit the second one.
>> What can you do now? The only option is to keep displaying the old
>> frame on the other displays for some time longer, and then on the
>> next frame you can switch to GPU composition. But on the next frame you
>> perhaps no longer need to use GPU composition, but since you can't
>> verify that in the prepare phase, you have no other option but to use
>> GPU composition.
>>
>> So when you run into a configuration that can be supported only
>> partially, you get animation stalls on some displays due to skipped
>> frames, and you always have to fall back to GPU composition for the
>> next frame.
>>
>> If on the other hand you would check the whole state in one ioctl,
>> you'd get the error in the first prepare phase, and could fall back
>> to GPU composition immediately.
>>
>> Am I too much of a perfectionst in considering such things? I don't
>> think so, but perhaps other people disagree.
>
> I don't think there's any harm in having multiple ioctls for different
> things.
>
> I was initially hoping the nuclear page flip would be very simple.
> Intended for simply updating buffers of several planes associated with
> a single display.  That makes the inner loop of something like Wayland
> or SF simple, but obviously doesn't cover every case (in fact I had
> avoided dealing with moving planes initially).
>
> Rob's patchset goes further than that, but obviously not as far as you
> propose.
>
> OTOH, keeping things really simple and not very featureful means there
> are fewer points of failure, which is what I think callers would expect
> from a flip API...
>
> So where does that leave us?  I'd propose we have a very simple,
> stripped down, single crtc flip ioctl, along with a big atomic mode set
> ioctl, and then perhaps a fancier multi-crtc flip ioctl.

I think (hope) the consensus coming out of this thread is something
along these lines:

 - We use properties for specifying what to change to be future
compatible with new crtc features, but also to allow exposing
hw-specific properties and tie them into the atomicity of the
pageflip.  The KMS overlays are a lowest-common denominator for all
the various overlay types out there and it should be possible to write
a piece of chipset specific compositor code to use features that can't
be expressed through KMS overlays.

 - We have two types of properties: dynamic and non-dynamic ones.
Dynamic 

[PATCH] intel: Mark bo's exported to prime as not reusable

[Kristian Høgsberg]

On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson  
wrote:
> On Fri, 14 Sep 2012 16:37:53 -0400, Kristian H?gsberg  
> wrote:
>> It's the same situation as flink and we need take the same pre-cautions.
>> ---
>>  intel/intel_bufmgr_gem.c |8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
>> index 3bcc849..92c0444 100644
>> --- a/intel/intel_bufmgr_gem.c
>> +++ b/intel/intel_bufmgr_gem.c
>> @@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, 
>> int *prime_fd)
>>  {
>>   drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
>>   drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
>> + int ret;
>>
>> - return drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle, 
>> DRM_CLOEXEC, prime_fd);
>> + ret = drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
>> +  DRM_CLOEXEC, prime_fd);
>> + if (ret == 0)
>> + bo_gem->reusable = false;
>
> Now that you mention it...
> To be consistent with libdrm_intel, we should return -errno on error; so
> rephrasing this as
>   if (ret)
> return -errno;
>
>   bo_gem->reusable = false;
>   return 0;
>
> would work better.

Argh, yes, I copy and pasted that from drm_intel_gem_bo_flink() but
edited it away later...  with that change, can I add your reviewed-by
and commit?

Kristian

[PATCH] intel: Mark bo's exported to prime as not reusable

[Kristian Høgsberg]

It's the same situation as flink and we need take the same pre-cautions.
---
 intel/intel_bufmgr_gem.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 3bcc849..92c0444 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int 
*prime_fd)
 {
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+   int ret;

-   return drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle, 
DRM_CLOEXEC, prime_fd);
+   ret = drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
+DRM_CLOEXEC, prime_fd);
+   if (ret == 0)
+   bo_gem->reusable = false;
+
+   return ret;
 }

 static int
-- 
1.7.10.2

[PATCH 2/2] tests/testdisplay: Test the stereo 3D modes

[Kristian Høgsberg]

On Wed, Sep 12, 2012 at 06:48:19PM +0100, Damien Lespiau wrote:
> From: Damien Lespiau 
> 
> Now that modes have flags to describe which 3d formats the sink
> supports, it's time to test them.
> 
> The new test cycles through the supported 3D formats and paint 3D
> stereoscopic images taken from publicly available samples:
>   http://www.quantumdata.com/apps/3D/sample_BMP.asp
> 
> Signed-off-by: Damien Lespiau 
> ---
>  tests/1080FP.png| Bin 0 -> 2291944 bytes
>  tests/1080TB.png| Bin 0 -> 1137594 bytes
>  tests/720FP.png | Bin 0 -> 1088754 bytes
>  tests/720TB.png | Bin 0 -> 555755 bytes
>  tests/testdisplay.c | 216 
> +++-
>  5 files changed, 213 insertions(+), 3 deletions(-)
>  create mode 100644 tests/1080FP.png
>  create mode 100644 tests/1080TB.png
>  create mode 100644 tests/720FP.png
>  create mode 100644 tests/720TB.png
> 
> diff --git a/tests/1080FP.png b/tests/1080FP.png



> literal 0
> HcmV?d1
> 
> diff --git a/tests/testdisplay.c b/tests/testdisplay.c
> index c52bb2f..77d1503 100644
> --- a/tests/testdisplay.c
> +++ b/tests/testdisplay.c
> @@ -52,6 +52,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -68,7 +69,7 @@
>  drmModeRes *resources;
>  int drm_fd, modes;
>  int dump_info = 0, test_all_modes =0, test_preferred_mode = 0, force_mode = 
> 0,
> - test_plane, enable_tiling;
> + test_plane, test_3d_modes, enable_tiling;
>  int sleep_between_modes = 5;
>  uint32_t depth = 24, stride, bpp;
>  int qr_code = 0;
> @@ -153,6 +154,11 @@ struct connector {
>   drmModeConnector *connector;
>   int crtc;
>   int pipe;
> +
> + /* stereo 3d */
> + int s3d_format;
> + uint32_t s3d_property_id;
> + char s3d_image[32];
>  };
>  
>  static void dump_connectors_fd(int drmfd)
> @@ -554,6 +560,193 @@ set_mode(struct connector *c)
>   drmModeFreeConnector(c->connector);
>  }
>  
> +static void
> +paint_3d_image(cairo_t *cr, int l_width, int l_height, void *priv)
> +{
> + struct connector *c = priv;
> + cairo_surface_t *image;
> +
> + image = cairo_image_surface_create_from_png(c->s3d_image);
> +
> + cairo_set_source_surface(cr, image, 0, 0);
> + cairo_paint(cr);
> +
> + cairo_surface_destroy(image);
> +}
> +
> +static void adjust_3d_timings(drmModeModeInfo *mode, unsigned int format)
> +{
> + uint16_t vdisplay, vactive_space;
> +
> + /* just set the 3D format we are setting (this is not used by the
> +  * kernel, it's just for kmstest_dump_mode()) */
> + mode->flags &= ~DRM_MODE_FLAG_3D_MASK;
> + mode->flags |= format;
> +
> + switch (format) {
> + case DRM_MODE_FLAG_3D_TOP_BOTTOM:
> + case DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF:
> + return;
> + case DRM_MODE_FLAG_3D_FRAME_PACKING:
> + vactive_space = mode->vtotal - mode->vdisplay;
> + vdisplay = mode->vdisplay;
> +
> + mode->vdisplay += vdisplay + vactive_space;
> + mode->vsync_start += vdisplay + vactive_space;
> + mode->vsync_end += vdisplay + vactive_space;
> + mode->vtotal += vdisplay + vactive_space;
> + mode->clock = (mode->vtotal * mode->htotal * mode->vrefresh) /
> +   1000;
> + return;
> + default:
> + assert(0);
> + }
> +}
> +
> +static const char *s3d_format_str(unsigned int format)
> +{
> + switch(format) {
> + case DRM_MODE_FLAG_3D_TOP_BOTTOM:
> + return "TB";
> + case DRM_MODE_FLAG_3D_FRAME_PACKING:
> + return "FP";
> + }
> +
> + return "Unknown format";
> +}
> +
> +static void do_set_3d_format(struct connector *c, unsigned int format)
> +{
> + uint32_t fb_id;
> + struct kmstest_fb fb_info;
> +
> + snprintf(c->s3d_image, sizeof(c->s3d_image), "%d%s.png",
> +  c->mode.vdisplay, s3d_format_str(format));
> +
> + adjust_3d_timings(>mode, format);
> + width = c->mode.hdisplay;
> + height = c->mode.vdisplay;
> +
> + fb_id = kmstest_create_fb(drm_fd, width, height, bpp, depth,
> +   enable_tiling, _info,
> +   paint_3d_image, c);
> +
> + fb_ptr = gem_mmap(drm_fd, fb_info.gem_handle,
> +   fb_info.size, PROT_READ | PROT_WRITE);
> + assert(fb_ptr);
> +
> + gem_close(drm_fd, fb_info.gem_handle);
> +
> + kmstest_dump_mode(>mode);
> +
> + if (drmModeConnectorSetProperty(drm_fd,
> + c->id,
> + c->s3d_property_id,
> + format)) {
> + fprintf(stderr, "failed to set \"select 3D mode\" "
> + "property to %d: %s\n", 1, strerror(errno));
> + }

I agree with Chris that this would be better done as part of the mode.
We can do it in a way that doesn't break backwards compatibility by

[PATCH] Sync the mode flags for the stereo 3D formats

[Kristian Høgsberg]

On Wed, Sep 12, 2012 at 06:47:56PM +0100, Damien Lespiau wrote:
> From: Damien Lespiau 
> 
> Signed-off-by: Damien Lespiau 
> ---
>  include/drm/drm_mode.h | 35 +--
>  xf86drmMode.h  | 35 +--
>  2 files changed, 42 insertions(+), 28 deletions(-)
> 
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index 62ba997..1ab936c 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -42,20 +42,27 @@
>  
>  /* Video mode flags */
>  /* bit compatible with the xorg definitions. */
> -#define DRM_MODE_FLAG_PHSYNC (1<<0)
> -#define DRM_MODE_FLAG_NHSYNC (1<<1)
> -#define DRM_MODE_FLAG_PVSYNC (1<<2)
> -#define DRM_MODE_FLAG_NVSYNC (1<<3)
> -#define DRM_MODE_FLAG_INTERLACE  (1<<4)
> -#define DRM_MODE_FLAG_DBLSCAN(1<<5)
> -#define DRM_MODE_FLAG_CSYNC  (1<<6)
> -#define DRM_MODE_FLAG_PCSYNC (1<<7)
> -#define DRM_MODE_FLAG_NCSYNC (1<<8)
> -#define DRM_MODE_FLAG_HSKEW  (1<<9) /* hskew provided */
> -#define DRM_MODE_FLAG_BCAST  (1<<10)
> -#define DRM_MODE_FLAG_PIXMUX (1<<11)
> -#define DRM_MODE_FLAG_DBLCLK (1<<12)
> -#define DRM_MODE_FLAG_CLKDIV2(1<<13)
> +#define DRM_MODE_FLAG_PHSYNC (1<<0)
> +#define DRM_MODE_FLAG_NHSYNC (1<<1)
> +#define DRM_MODE_FLAG_PVSYNC (1<<2)
> +#define DRM_MODE_FLAG_NVSYNC (1<<3)
> +#define DRM_MODE_FLAG_INTERLACE  (1<<4)
> +#define DRM_MODE_FLAG_DBLSCAN(1<<5)
> +#define DRM_MODE_FLAG_CSYNC  (1<<6)
> +#define DRM_MODE_FLAG_PCSYNC (1<<7)
> +#define DRM_MODE_FLAG_NCSYNC (1<<8)
> +#define DRM_MODE_FLAG_HSKEW  (1<<9) /* hskew provided */
> +#define DRM_MODE_FLAG_BCAST  (1<<10)
> +#define DRM_MODE_FLAG_PIXMUX (1<<11)
> +#define DRM_MODE_FLAG_DBLCLK (1<<12)
> +#define DRM_MODE_FLAG_CLKDIV2(1<<13)
> +#define DRM_MODE_FLAG_3D_TOP_BOTTOM  (1<<14)
> +#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF   (1<<15)
> +#define DRM_MODE_FLAG_3D_FRAME_PACKING   (1<<16)
> +
> +#define DRM_MODE_FLAG_3D_MASK(DRM_MODE_FLAG_3D_TOP_BOTTOM |  
> \
> +  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF |   \
> +  DRM_MODE_FLAG_3D_FRAME_PACKING)

This is really an enum, right?  Should we just use two bits?

>  
>  /* DPMS flags */
>  /* bit compatible with the xorg definitions. */
> diff --git a/xf86drmMode.h b/xf86drmMode.h
> index 8e40034..f88522e 100644
> --- a/xf86drmMode.h
> +++ b/xf86drmMode.h
> @@ -81,20 +81,27 @@ extern "C" {
>  
>  /* Video mode flags */
>  /* bit compatible with the xorg definitions. */
> -#define DRM_MODE_FLAG_PHSYNC(1<<0)
> -#define DRM_MODE_FLAG_NHSYNC(1<<1)
> -#define DRM_MODE_FLAG_PVSYNC(1<<2)
> -#define DRM_MODE_FLAG_NVSYNC(1<<3)
> -#define DRM_MODE_FLAG_INTERLACE (1<<4)
> -#define DRM_MODE_FLAG_DBLSCAN   (1<<5)
> -#define DRM_MODE_FLAG_CSYNC (1<<6)
> -#define DRM_MODE_FLAG_PCSYNC(1<<7)
> -#define DRM_MODE_FLAG_NCSYNC(1<<8)
> -#define DRM_MODE_FLAG_HSKEW (1<<9) /* hskew provided */
> -#define DRM_MODE_FLAG_BCAST (1<<10)
> -#define DRM_MODE_FLAG_PIXMUX(1<<11)
> -#define DRM_MODE_FLAG_DBLCLK(1<<12)
> -#define DRM_MODE_FLAG_CLKDIV2   (1<<13)
> +#define DRM_MODE_FLAG_PHSYNC (1<<0)
> +#define DRM_MODE_FLAG_NHSYNC (1<<1)
> +#define DRM_MODE_FLAG_PVSYNC (1<<2)
> +#define DRM_MODE_FLAG_NVSYNC (1<<3)
> +#define DRM_MODE_FLAG_INTERLACE  (1<<4)
> +#define DRM_MODE_FLAG_DBLSCAN(1<<5)
> +#define DRM_MODE_FLAG_CSYNC  (1<<6)
> +#define DRM_MODE_FLAG_PCSYNC (1<<7)
> +#define DRM_MODE_FLAG_NCSYNC (1<<8)
> +#define DRM_MODE_FLAG_HSKEW  (1<<9) /* hskew provided */
> +#define DRM_MODE_FLAG_BCAST  (1<<10)
> +#define DRM_MODE_FLAG_PIXMUX (1<<11)
> +#define DRM_MODE_FLAG_DBLCLK (1<<12)
> +#define DRM_MODE_FLAG_CLKDIV2(1<<13)
> +#define DRM_MODE_FLAG_3D_TOP_BOTTOM  (1<<14)
> +#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF   (1<<15)
> +#define DRM_MODE_FLAG_3D_FRAME_PACKING   (1<<16)
> +
> +#define DRM_MODE_FLAG_3D_MASK(DRM_MODE_FLAG_3D_TOP_BOTTOM |  
> \
> +  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF |   \
> +  DRM_MODE_FLAG_3D_FRAME_PACKING)
>  
>  /* DPMS flags */
>  /* bit compatible with the xorg definitions. */
> -- 
> 1.7.11.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] intel: Mark bo's exported to prime as not reusable

[Kristian Høgsberg]

It's the same situation as flink and we need take the same pre-cautions.
---
 intel/intel_bufmgr_gem.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 3bcc849..92c0444 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int 
*prime_fd)
 {
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo-bufmgr;
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+   int ret;
 
-   return drmPrimeHandleToFD(bufmgr_gem-fd, bo_gem-gem_handle, 
DRM_CLOEXEC, prime_fd);
+   ret = drmPrimeHandleToFD(bufmgr_gem-fd, bo_gem-gem_handle,
+DRM_CLOEXEC, prime_fd);
+   if (ret == 0)
+   bo_gem-reusable = false;
+
+   return ret;
 }
 
 static int
-- 
1.7.10.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] intel: Mark bo's exported to prime as not reusable

[Kristian Høgsberg]

On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, 14 Sep 2012 16:37:53 -0400, Kristian Høgsberg k...@bitplanet.net 
 wrote:
 It's the same situation as flink and we need take the same pre-cautions.
 ---
  intel/intel_bufmgr_gem.c |8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

 diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
 index 3bcc849..92c0444 100644
 --- a/intel/intel_bufmgr_gem.c
 +++ b/intel/intel_bufmgr_gem.c
 @@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, 
 int *prime_fd)
  {
   drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo-bufmgr;
   drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
 + int ret;

 - return drmPrimeHandleToFD(bufmgr_gem-fd, bo_gem-gem_handle, 
 DRM_CLOEXEC, prime_fd);
 + ret = drmPrimeHandleToFD(bufmgr_gem-fd, bo_gem-gem_handle,
 +  DRM_CLOEXEC, prime_fd);
 + if (ret == 0)
 + bo_gem-reusable = false;

 Now that you mention it...
 To be consistent with libdrm_intel, we should return -errno on error; so
 rephrasing this as
   if (ret)
 return -errno;

   bo_gem-reusable = false;
   return 0;

 would work better.

Argh, yes, I copy and pasted that from drm_intel_gem_bo_flink() but
edited it away later...  with that change, can I add your reviewed-by
and commit?

Kristian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] intel: Mark bo's exported to prime as not reusable

[Kristian Høgsberg]

On Fri, Sep 14, 2012 at 5:03 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, 14 Sep 2012 17:01:18 -0400, Kristian Høgsberg k...@bitplanet.net 
 wrote:
 On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Fri, 14 Sep 2012 16:37:53 -0400, Kristian Høgsberg k...@bitplanet.net 
  wrote:
  It's the same situation as flink and we need take the same pre-cautions.
  ---
   intel/intel_bufmgr_gem.c |8 +++-
   1 file changed, 7 insertions(+), 1 deletion(-)
 
  diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
  index 3bcc849..92c0444 100644
  --- a/intel/intel_bufmgr_gem.c
  +++ b/intel/intel_bufmgr_gem.c
  @@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, 
  int *prime_fd)
   {
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) 
  bo-bufmgr;
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
  + int ret;
 
  - return drmPrimeHandleToFD(bufmgr_gem-fd, bo_gem-gem_handle, 
  DRM_CLOEXEC, prime_fd);
  + ret = drmPrimeHandleToFD(bufmgr_gem-fd, bo_gem-gem_handle,
  +  DRM_CLOEXEC, prime_fd);
  + if (ret == 0)
  + bo_gem-reusable = false;
 
  Now that you mention it...
  To be consistent with libdrm_intel, we should return -errno on error; so
  rephrasing this as
if (ret)
  return -errno;
 
bo_gem-reusable = false;
return 0;
 
  would work better.

 Argh, yes, I copy and pasted that from drm_intel_gem_bo_flink() but
 edited it away later...  with that change, can I add your reviewed-by
 and commit?

 Yes,

 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
 -Chris

Thanks, pushed.  Btw, before this patch,
drm_intel_bo_gem_export_to_prime() was actually just returning the
drmPrimeHandleToFD() return value directly, not -errno on error.

Kristian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dri2proto: Fix documented opcodes

[Kristian Høgsberg]

On Wed, May 2, 2012 at 3:03 PM, Chad Versace
 wrote:
> Fix the documented opcodes in dri2proto.txt to be consistent with the
> actual opcode values in dri2proto.h and in xcb/proto:src/dri2.xml. (It
> looks like the opcodes were incorrect due to copy-paste errors).

Looks correct to me.

Kristian

> CC: Kristian H?gsberg 
> Signed-off-by: Chad Versace 
> ---
> ?dri2proto.txt | ? 18 +-
> ?1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/dri2proto.txt b/dri2proto.txt
> index df763c7..7bde067 100644
> --- a/dri2proto.txt
> +++ b/dri2proto.txt
> @@ -658,7 +658,7 @@ A.2 Protocol Requests
> ?
> ? ? DRI2GetBuffers
> ? ? ? ?1 ? ? ? CARD8 ? ? ? ? ? ? ? ? ? major opcode
> - ? ? ? 1 ? ? ? 3 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> + ? ? ? 1 ? ? ? 5 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> ? ? ? ?2 ? ? ? 3 ? ? ? ? ? ? ? ? ? ? ? length
> ? ? ? ?4 ? ? ? DRAWABLE ? ? ? ? ? ? ? ?drawable
> ? ? ? ?4 ? ? ? n ? ? ? ? ? ? ? ? ? ? ? number of attachments
> @@ -678,7 +678,7 @@ A.2 Protocol Requests
> ?
> ? ? DRI2CopyRegion
> ? ? ? ?1 ? ? ? CARD8 ? ? ? ? ? ? ? ? ? major opcode
> - ? ? ? 1 ? ? ? 4 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> + ? ? ? 1 ? ? ? 6 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> ? ? ? ?2 ? ? ? 3 ? ? ? ? ? ? ? ? ? ? ? length
> ? ? ? ?4 ? ? ? DRAWABLE ? ? ? ? ? ? ? ?drawable
> ? ? ? ?4 ? ? ? REGION ? ? ? ? ? ? ? ? ?region
> @@ -695,7 +695,7 @@ A.2 Protocol Requests
> ?
> ? ? DRI2GetBuffersWithFormat
> ? ? ? ?1 ? ? ? CARD8 ? ? ? ? ? ? ? ? ? major opcode
> - ? ? ? 1 ? ? ? 3 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> + ? ? ? 1 ? ? ? 7 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> ? ? ? ?2 ? ? ? 3 ? ? ? ? ? ? ? ? ? ? ? length
> ? ? ? ?4 ? ? ? DRAWABLE ? ? ? ? ? ? ? ?drawable
> ? ? ? ?4 ? ? ? n ? ? ? ? ? ? ? ? ? ? ? number of attachments
> @@ -715,7 +715,7 @@ A.2 Protocol Requests
> ?
> ? ? DRI2SwapBuffers
> ? ? ? ?1 ? ? ? CARD8 ? ? ? ? ? ? ? ? ? major opcode
> - ? ? ? 1 ? ? ? 7 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> + ? ? ? 1 ? ? ? 8 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> ? ? ? ?2 ? ? ? 8 ? ? ? ? ? ? ? ? ? ? ? length
> ? ? ? ?4 ? ? ? DRAWABLE ? ? ? ? ? ? ? ?drawable
> ? ? ? ?
> @@ -736,7 +736,7 @@ A.2 Protocol Requests
> ?
> ? ? DRI2SwapBuffers
> ? ? ? ?1 ? ? ? CARD8 ? ? ? ? ? ? ? ? ? major opcode
> - ? ? ? 1 ? ? ? 7 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> + ? ? ? 1 ? ? ? 8 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> ? ? ? ?2 ? ? ? 8 ? ? ? ? ? ? ? ? ? ? ? length
> ? ? ? ?4 ? ? ? DRAWABLE ? ? ? ? ? ? ? ?drawable
> ? ? ? ?4 ? ? ? CARD32 ? ? ? ? ? ? ? ? ?target_msc_hi
> @@ -758,7 +758,7 @@ A.2 Protocol Requests
> ?
> ? ? DRI2GetMSC
> ? ? ? ?1 ? ? ? CARD8 ? ? ? ? ? ? ? ? ? major opcode
> - ? ? ? 1 ? ? ? 7 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> + ? ? ? 1 ? ? ? 9 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> ? ? ? ?2 ? ? ? 8 ? ? ? ? ? ? ? ? ? ? ? length
> ? ? ? ?4 ? ? ? DRAWABLE ? ? ? ? ? ? ? ?drawable
> ? ? ? ?
> @@ -777,7 +777,7 @@ A.2 Protocol Requests
> ?
> ? ? DRI2WaitMSC
> ? ? ? ?1 ? ? ? CARD8 ? ? ? ? ? ? ? ? ? major opcode
> - ? ? ? 1 ? ? ? 7 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> + ? ? ? 1 ? ? ? 10 ? ? ? ? ? ? ? ? ? ? ?DRI2 opcode
> ? ? ? ?2 ? ? ? 8 ? ? ? ? ? ? ? ? ? ? ? length
> ? ? ? ?4 ? ? ? DRAWABLE ? ? ? ? ? ? ? ?drawable
> ? ? ? ?4 ? ? ? CARD32 ? ? ? ? ? ? ? ? ?target_msc_hi
> @@ -802,7 +802,7 @@ A.2 Protocol Requests
> ?
> ? ? DRI2WaitSBC
> ? ? ? ?1 ? ? ? CARD8 ? ? ? ? ? ? ? ? ? major opcode
> - ? ? ? 1 ? ? ? 7 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> + ? ? ? 1 ? ? ? 11 ? ? ? ? ? ? ? ? ? ? ?DRI2 opcode
> ? ? ? ?2 ? ? ? 8 ? ? ? ? ? ? ? ? ? ? ? length
> ? ? ? ?4 ? ? ? DRAWABLE ? ? ? ? ? ? ? ?drawable
> ? ? ? ?4 ? ? ? CARD32 ? ? ? ? ? ? ? ? ?swap_hi
> @@ -823,7 +823,7 @@ A.2 Protocol Requests
> ?
> ? ? DRI2SwapInterval
> ? ? ? ?1 ? ? ? CARD8 ? ? ? ? ? ? ? ? ? major opcode
> - ? ? ? 1 ? ? ? 7 ? ? ? ? ? ? ? ? ? ? ? DRI2 opcode
> + ? ? ? 1 ? ? ? 12 ? ? ? ? ? ? ? ? ? ? ?DRI2 opcode
> ? ? ? ?2 ? ? ? 8 ? ? ? ? ? ? ? ? ? ? ? length
> ? ? ? ?4 ? ? ? DRAWABLE ? ? ? ? ? ? ? ?drawable
> ? ? ? ?4 ? ? ? CARD32 ? ? ? ? ? ? ? ? ?interval
> --
> 1.7.10
>

Re: [PATCH] dri2proto: Fix documented opcodes

[Kristian Høgsberg]

On Wed, May 2, 2012 at 3:03 PM, Chad Versace
chad.vers...@linux.intel.com wrote:
 Fix the documented opcodes in dri2proto.txt to be consistent with the
 actual opcode values in dri2proto.h and in xcb/proto:src/dri2.xml. (It
 looks like the opcodes were incorrect due to copy-paste errors).

Looks correct to me.

Kristian

 CC: Kristian Høgsberg k...@bitplanet.net
 Signed-off-by: Chad Versace chad.vers...@linux.intel.com
 ---
  dri2proto.txt |   18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

 diff --git a/dri2proto.txt b/dri2proto.txt
 index df763c7..7bde067 100644
 --- a/dri2proto.txt
 +++ b/dri2proto.txt
 @@ -658,7 +658,7 @@ A.2 Protocol Requests
  ┌───
     DRI2GetBuffers
        1       CARD8                   major opcode
 -       1       3                       DRI2 opcode
 +       1       5                       DRI2 opcode
        2       3                       length
        4       DRAWABLE                drawable
        4       n                       number of attachments
 @@ -678,7 +678,7 @@ A.2 Protocol Requests
  ┌───
     DRI2CopyRegion
        1       CARD8                   major opcode
 -       1       4                       DRI2 opcode
 +       1       6                       DRI2 opcode
        2       3                       length
        4       DRAWABLE                drawable
        4       REGION                  region
 @@ -695,7 +695,7 @@ A.2 Protocol Requests
  ┌───
     DRI2GetBuffersWithFormat
        1       CARD8                   major opcode
 -       1       3                       DRI2 opcode
 +       1       7                       DRI2 opcode
        2       3                       length
        4       DRAWABLE                drawable
        4       n                       number of attachments
 @@ -715,7 +715,7 @@ A.2 Protocol Requests
  ┌───
     DRI2SwapBuffers
        1       CARD8                   major opcode
 -       1       7                       DRI2 opcode
 +       1       8                       DRI2 opcode
        2       8                       length
        4       DRAWABLE                drawable
       ▶
 @@ -736,7 +736,7 @@ A.2 Protocol Requests
  ┌───
     DRI2SwapBuffers
        1       CARD8                   major opcode
 -       1       7                       DRI2 opcode
 +       1       8                       DRI2 opcode
        2       8                       length
        4       DRAWABLE                drawable
        4       CARD32                  target_msc_hi
 @@ -758,7 +758,7 @@ A.2 Protocol Requests
  ┌───
     DRI2GetMSC
        1       CARD8                   major opcode
 -       1       7                       DRI2 opcode
 +       1       9                       DRI2 opcode
        2       8                       length
        4       DRAWABLE                drawable
       ▶
 @@ -777,7 +777,7 @@ A.2 Protocol Requests
  ┌───
     DRI2WaitMSC
        1       CARD8                   major opcode
 -       1       7                       DRI2 opcode
 +       1       10                      DRI2 opcode
        2       8                       length
        4       DRAWABLE                drawable
        4       CARD32                  target_msc_hi
 @@ -802,7 +802,7 @@ A.2 Protocol Requests
  ┌───
     DRI2WaitSBC
        1       CARD8                   major opcode
 -       1       7                       DRI2 opcode
 +       1       11                      DRI2 opcode
        2       8                       length
        4       DRAWABLE                drawable
        4       CARD32                  swap_hi
 @@ -823,7 +823,7 @@ A.2 Protocol Requests
  ┌───
     DRI2SwapInterval
        1       CARD8                   major opcode
 -       1       7                       DRI2 opcode
 +       1       12                      DRI2 opcode
        2       8                       length
        4       DRAWABLE                drawable
        4       CARD32                  interval
 --
 1.7.10

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v2] Revive the work on render-nodes branch

[Kristian Høgsberg]

On Fri, Apr 20, 2012 at 6:20 AM, Dave Airlie  wrote:
> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
>  wrote:
>> The following set of patches is the reword of the series
>> sent two weeks ago [2] that will revive the drm-render-nodes [1]
>> branch. Details of the original series are described in [2].
>
> Thanks for looking at this,
>
> So one thing about adding render nodes, is it gives us the chance to
> maybe change the userspace API we expose to be more secure and have
> less cruft in it.
>
> Now I'm weary of a major API redesign as this could bog things now and
> we'd never make forward progress, but I'd like to at least consider it
> before adding new device nodes and locking us into the old APIs.
>
> The areas suggested before:
>
> 1) GEM, drop flink/open ioctls - these make security hard, since once
> you share a buffer any GEM opener can get access to it. Solutions to
> this proposed before are flink_to and maybe using PRIME/dma-buf.

Yup, and I retract my flink_to proposal.  Passing the buffer as an fd
has a few benefits over the flink_to idea: 1) we don't have to
establish an id/handle that represents the other process.  We could
use the process ID or the drm magic, but either way we'd need an
initial handshake to pass that id across before we can share buffer.
Not a deal breaker, just awkward.  2) Passing buffers as fds keeps the
buffer alive "in flight".  This allows the sender to send the buffer
and immediately destroy it, if it needs to.

Another thing I'd change for render nodes is to not require
authentication.  We can still protect access to render nodes to local
sessions using file system permissions (ie, you won't be able to ssh
in and start a GPGPU jobs).  Being able to use the drm device doesn't
give you access to the xserver frontbuffer like it did in the DRI1
days.  You can only render to your own buffers and send or receive
buffer handles over sockets.  If we restrict the ioctls to just GEM
and PRIME, I don't think authentication protects anything we couldn't
just use file system permission for instead.

> 2) master/device ownership. We might be able to drop the first opener
> is magically master, and require openers to ask for it somehow.

If we add render nodes that clients are expected to use, we can
restrict access to the legacy drm device node, such that only X can
open it.  That way it wouldn't matter too much whether we keep the
auto-master behavior or not.  I would like to see the root requirement
dropped from the drop and set master ioctls so that you could put X,
weston etc in a group that allows them to open /dev/dri/card0 and not
need root to perform vt switching duties.  Even today there's no need
for the root requirements, certainly drop master is harmless and
setmaster can just be restricted to drm fds that were previously
masters and only when there's no current master.

> 3) drop the old map ioctls from this interface, irq by busid, drop the AGP.

Yup, or another way to put it: what todays mesa needs, minus flink_to,
open, get_magic (this is the only libdrm call in the glx dri and
egl_dri2 loaders btw) , auth_magic, but with the PRIME ioctls added.

> I'm not talking about changing ioctl operation, more about introducing
> new ioctls and not allowing the old ones on the new nodes.

Yup, agree.

thanks,
Kristian

Re: [RFC v2] Revive the work on render-nodes branch

[Kristian Høgsberg]

On Fri, Apr 20, 2012 at 6:20 AM, Dave Airlie airl...@gmail.com wrote:
 On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
 ihad...@research.bell-labs.com wrote:
 The following set of patches is the reword of the series
 sent two weeks ago [2] that will revive the drm-render-nodes [1]
 branch. Details of the original series are described in [2].

 Thanks for looking at this,

 So one thing about adding render nodes, is it gives us the chance to
 maybe change the userspace API we expose to be more secure and have
 less cruft in it.

 Now I'm weary of a major API redesign as this could bog things now and
 we'd never make forward progress, but I'd like to at least consider it
 before adding new device nodes and locking us into the old APIs.

 The areas suggested before:

 1) GEM, drop flink/open ioctls - these make security hard, since once
 you share a buffer any GEM opener can get access to it. Solutions to
 this proposed before are flink_to and maybe using PRIME/dma-buf.

Yup, and I retract my flink_to proposal.  Passing the buffer as an fd
has a few benefits over the flink_to idea: 1) we don't have to
establish an id/handle that represents the other process.  We could
use the process ID or the drm magic, but either way we'd need an
initial handshake to pass that id across before we can share buffer.
Not a deal breaker, just awkward.  2) Passing buffers as fds keeps the
buffer alive in flight.  This allows the sender to send the buffer
and immediately destroy it, if it needs to.

Another thing I'd change for render nodes is to not require
authentication.  We can still protect access to render nodes to local
sessions using file system permissions (ie, you won't be able to ssh
in and start a GPGPU jobs).  Being able to use the drm device doesn't
give you access to the xserver frontbuffer like it did in the DRI1
days.  You can only render to your own buffers and send or receive
buffer handles over sockets.  If we restrict the ioctls to just GEM
and PRIME, I don't think authentication protects anything we couldn't
just use file system permission for instead.

 2) master/device ownership. We might be able to drop the first opener
 is magically master, and require openers to ask for it somehow.

If we add render nodes that clients are expected to use, we can
restrict access to the legacy drm device node, such that only X can
open it.  That way it wouldn't matter too much whether we keep the
auto-master behavior or not.  I would like to see the root requirement
dropped from the drop and set master ioctls so that you could put X,
weston etc in a group that allows them to open /dev/dri/card0 and not
need root to perform vt switching duties.  Even today there's no need
for the root requirements, certainly drop master is harmless and
setmaster can just be restricted to drm fds that were previously
masters and only when there's no current master.

 3) drop the old map ioctls from this interface, irq by busid, drop the AGP.

Yup, or another way to put it: what todays mesa needs, minus flink_to,
open, get_magic (this is the only libdrm call in the glx dri and
egl_dri2 loaders btw) , auth_magic, but with the PRIME ioctls added.

 I'm not talking about changing ioctl operation, more about introducing
 new ioctls and not allowing the old ones on the new nodes.

Yup, agree.

thanks,
Kristian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH] drm: Add plane event

[Kristian Høgsberg]

On Wed, Apr 18, 2012 at 10:36 AM, Daniel Vetter  wrote:
> On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrj?l? wrote:
>> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> > On 04/18/2012 02:25 PM, Rob Clark wrote:
>> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim> > > samsung.com> ?wrote:
>> > >> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
>> > >>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
>> >  DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
>> >  for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
>> >  provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
>> >  can change the framebuffer of plane but user can't know completion of
>> >  changing the framebuffer of plane via event. If DRM_MODE_PLANE_EVENT 
>> >  is
>> >  added, we can also do pageflip of a plane.
>> > 
>> >  Signed-off-by: Joonyoung Shim
>> >  Signed-off-by: Kyungmin Park
>> > >>> If I understand the current kms api correctly, set_plane is akin to
>> > >>> set_base and should not generate an asynchronous flip completion event.
>> > >>> To
>> > >>> do that we need a new pageflip ioctl which changes a complete set of 
>> > >>> fb +
>> > >>> planes + any crtc attributes that might be in an atomic fashion. At 
>> > >>> which
>> > >>> point we can just reuse the existing page flip event mechanism.
>> > >>
>> > >> It seems better way to add new pageflip ioctl for plane. I will try it.
>> > > fwiw, an atomic mode set which can update crtc and zero or more plane
>> > > layers is, I think, the way to go. ?Jesse Barnes had an RFC for this,
>> > > although IIRC it was only the API and not the implementation. ?And
>> > > combination w/ the plane/crtc properties patchset to allow setting
>> > > properties as part of the update might not be a bad thing either.
>> > >
>> > > BR,
>> > > -R
>> >
>> > Before planes and rotation properties modeset was atomic (single ioctl).
>> > Would it not be possible to define atomic modeset for planes and
>> > properties like this?
>> >
>> > SETPROPERTY and SETPLANE (maybe more) should not be commited when set,
>> > only on SETCRTC ioctl like before planes. All properties and plane
>> > changes before SETCRTC should be considered staged settings for the next
>> > SETCRTC.
>> > If this would break API backwards compatibility, maybe a new "standard"
>> > boolean property called EnableAtomicMode could be used to trigger this
>> > mode in the drivers. If a driver doesn't support it, things will just
>> > work as currently with modeset not being atomic across planes.
>> > Maybe this could be implemented in the generic parts of KMS, but it
>> > could be tried out first inside a driver.
>>
>> Multi ioctl solution can have some issues since you can't hold any
>> locks around the whole operation. Also there could be issues if the
>> process performing the operation dies or hangs in mid operation.
>> Error handling can also be difficult since the intermediate steps
>> may violate some constraints in the system.
>>
>> Also SETCRTC itself is a per-CRTC operation, but we actually want
>> per-device atomic operations instead.
>>
>> So I think a single ioctl solution is a better idea. I'm currently
>> pondering on what the API would look like. Ideally I would like to
>> go with the "everything is a property" approach, and I'd like to get
>> rid of some of the other limitations in the current API at the same
>> time.
>
> Last time around I've discussed with people we've ended up with 2 new
> ioctls:
>
> - atomic modeset, to configure the output state on more than one crtc at
> ?the same time. This is useful to get pll assignement, memory bandwidth
> ?constrains and similar stuff right. This ioctl is synchronous. A
> ?testmode can be used to inquire the driver whether the proposed mode
> ?actually works. This could be used for gui interfaces to automatically
> ?grey out unsupportable configurations, e.g. if you have 3 crtc but on 2
> ?pll and 2 modes need to have the same pixelclocks to drive all 3 crtcs.
>
> - an atomic pageflip. This one would be like the current pageflip ioclt,
> ?i.e. run asynchronously and deliver a drm event upont completion. The
> ?idea is that compositors can use this to make flicker-free compositition
> ?with drm planes possible. I think we want drivers to be able to indicate
> ?which crtc properties they can switch with this ioctl, e.g. I expect
> ?some yuv->rbg color space properties might not work. All the changes
> ?should be applied on the same vblank, obviously.
>
> But Jesse and Kristian have been more active in this discussion, cc'ed
> them.

Yeah, that sums it up pretty well.  The atomic modeset allows KMS to
allocate resources (bandwidth, connectors, encoders etc) across all
crtcs may take a while to complete.  The nuclear pageflip only affects
one crtc at a time, but ideally should let us change all properties
that don't affect bandwidth or timing 

Re: [RFC PATCH] drm: Add plane event

[Kristian Høgsberg]

On Wed, Apr 18, 2012 at 10:36 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrjälä wrote:
 On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
  On 04/18/2012 02:25 PM, Rob Clark wrote:
   On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shimjy0922.s...@samsung.com 
    wrote:
   On 04/18/2012 05:46 PM, Daniel Vetter wrote:
   On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
   DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
   for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
   provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
   can change the framebuffer of plane but user can't know completion of
   changing the framebuffer of plane via event. If DRM_MODE_PLANE_EVENT 
   is
   added, we can also do pageflip of a plane.
  
   Signed-off-by: Joonyoung Shimjy0922.s...@samsung.com
   Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
   If I understand the current kms api correctly, set_plane is akin to
   set_base and should not generate an asynchronous flip completion event.
   To
   do that we need a new pageflip ioctl which changes a complete set of 
   fb +
   planes + any crtc attributes that might be in an atomic fashion. At 
   which
   point we can just reuse the existing page flip event mechanism.
  
   It seems better way to add new pageflip ioctl for plane. I will try it.
   fwiw, an atomic mode set which can update crtc and zero or more plane
   layers is, I think, the way to go.  Jesse Barnes had an RFC for this,
   although IIRC it was only the API and not the implementation.  And
   combination w/ the plane/crtc properties patchset to allow setting
   properties as part of the update might not be a bad thing either.
  
   BR,
   -R
 
  Before planes and rotation properties modeset was atomic (single ioctl).
  Would it not be possible to define atomic modeset for planes and
  properties like this?
 
  SETPROPERTY and SETPLANE (maybe more) should not be commited when set,
  only on SETCRTC ioctl like before planes. All properties and plane
  changes before SETCRTC should be considered staged settings for the next
  SETCRTC.
  If this would break API backwards compatibility, maybe a new standard
  boolean property called EnableAtomicMode could be used to trigger this
  mode in the drivers. If a driver doesn't support it, things will just
  work as currently with modeset not being atomic across planes.
  Maybe this could be implemented in the generic parts of KMS, but it
  could be tried out first inside a driver.

 Multi ioctl solution can have some issues since you can't hold any
 locks around the whole operation. Also there could be issues if the
 process performing the operation dies or hangs in mid operation.
 Error handling can also be difficult since the intermediate steps
 may violate some constraints in the system.

 Also SETCRTC itself is a per-CRTC operation, but we actually want
 per-device atomic operations instead.

 So I think a single ioctl solution is a better idea. I'm currently
 pondering on what the API would look like. Ideally I would like to
 go with the everything is a property approach, and I'd like to get
 rid of some of the other limitations in the current API at the same
 time.

 Last time around I've discussed with people we've ended up with 2 new
 ioctls:

 - atomic modeset, to configure the output state on more than one crtc at
  the same time. This is useful to get pll assignement, memory bandwidth
  constrains and similar stuff right. This ioctl is synchronous. A
  testmode can be used to inquire the driver whether the proposed mode
  actually works. This could be used for gui interfaces to automatically
  grey out unsupportable configurations, e.g. if you have 3 crtc but on 2
  pll and 2 modes need to have the same pixelclocks to drive all 3 crtcs.

 - an atomic pageflip. This one would be like the current pageflip ioclt,
  i.e. run asynchronously and deliver a drm event upont completion. The
  idea is that compositors can use this to make flicker-free compositition
  with drm planes possible. I think we want drivers to be able to indicate
  which crtc properties they can switch with this ioctl, e.g. I expect
  some yuv-rbg color space properties might not work. All the changes
  should be applied on the same vblank, obviously.

 But Jesse and Kristian have been more active in this discussion, cc'ed
 them.

Yeah, that sums it up pretty well.  The atomic modeset allows KMS to
allocate resources (bandwidth, connectors, encoders etc) across all
crtcs may take a while to complete.  The nuclear pageflip only affects
one crtc at a time, but ideally should let us change all properties
that don't affect bandwidth or timing parameters: fb/overlay/sprite/hw
cursor base addresses, overlay/sprite/hw cursor position, scaling
properties.

One thing that's not clear to me is how we would enable a sprite
without going through the atomic modeset 

[PATCH 1/7] drm: base prime support

[Kristian Høgsberg]

On Wed, Feb 22, 2012 at 2:29 PM, Ben Widawsky  wrote:
> From: Dave Airlie 
>
> ---
> ?drivers/gpu/drm/Makefile ? ?| ? ?2 +-
> ?drivers/gpu/drm/drm_drv.c ? | ? ?3 +
> ?drivers/gpu/drm/drm_gem.c ? | ? ?3 +-
> ?drivers/gpu/drm/drm_prime.c | ?126 
> +++
> ?include/drm/drm.h ? ? ? ? ? | ? 10 +++-
> ?include/drm/drmP.h ? ? ? ? ?| ? 35 
> ?6 files changed, 176 insertions(+), 3 deletions(-)
> ?create mode 100644 drivers/gpu/drm/drm_prime.c
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 0cde1b8..202f650 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -12,7 +12,7 @@ drm-y ? ? ? := ? ? ? ?drm_auth.o drm_buffer.o drm_bufs.o 
> drm_cache.o \
> ? ? ? ? ? ? ? ?drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
> ? ? ? ? ? ? ? ?drm_crtc.o drm_modes.o drm_edid.o \
> ? ? ? ? ? ? ? ?drm_info.o drm_debugfs.o drm_encoder_slave.o \
> - ? ? ? ? ? ? ? drm_trace_points.o drm_global.o drm_usb.o
> + ? ? ? ? ? ? ? drm_trace_points.o drm_global.o drm_usb.o drm_prime.o
>
> ?drm-$(CONFIG_COMPAT) += drm_ioc32.o
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index ebf7d3f..786b134 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -135,6 +135,9 @@ static struct drm_ioctl_desc drm_ioctls[] = {
> ? ? ? ?DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> ? ? ? ?DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
>
> + ? ? ? DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
> drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
> + ? ? ? DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
> drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
> +
> ? ? ? ?DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> ? ? ? ?DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> ? ? ? ?DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index f8625e2..e19a958 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -145,6 +145,7 @@ int drm_gem_object_init(struct drm_device *dev,
> ? ? ? ?kref_init(>refcount);
> ? ? ? ?atomic_set(>handle_count, 0);
> ? ? ? ?obj->size = size;
> + ? ? ? obj->prime_fd = -1;
>
> ? ? ? ?return 0;
> ?}
> @@ -166,7 +167,7 @@ int drm_gem_private_object_init(struct drm_device *dev,
> ? ? ? ?kref_init(>refcount);
> ? ? ? ?atomic_set(>handle_count, 0);
> ? ? ? ?obj->size = size;
> -
> + ? ? ? obj->prime_fd = -1;
> ? ? ? ?return 0;
> ?}
> ?EXPORT_SYMBOL(drm_gem_private_object_init);
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> new file mode 100644
> index 000..11f142f
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -0,0 +1,126 @@
> +#include 
> +#include 
> +#include "drmP.h"
> +
> +struct drm_prime_member {
> + ? ? ? struct list_head entry;
> + ? ? ? struct dma_buf *dma_buf;
> + ? ? ? uint32_t handle;
> +};
> +
> +int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct drm_file *file_priv)
> +{
> + ? ? ? struct drm_prime_handle *args = data;
> +
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_PRIME))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> + ? ? ? return dev->driver->prime_handle_to_fd(dev, file_priv, args->handle, 
> >fd);

We need a way to pass flags to this so we can pass DRM_PRIME_CLOEXEC
(or whatever, but not O_CLOEXEC) to create the fd in close-on-exec
mode, and it needs to be available in the libdrm API.  See man
epoll_create1 for an example where we had to add a new brown-bag
syscall to allow this.

> +}
> +
> +int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct drm_file *file_priv)
> +{
> + ? ? ? struct drm_prime_handle *args = data;
> +
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_PRIME))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> + ? ? ? return dev->driver->prime_fd_to_handle(dev, file_priv, args->fd, 
> >handle);
> +}
> +
> +struct sg_table *drm_prime_pages_to_sg(struct page **pages, int nr_pages)
> +{
> + ? ? ? struct sg_table *sg = NULL;
> + ? ? ? struct scatterlist *iter;
> + ? ? ? int i;
> + ? ? ? int ret;
> +
> + ? ? ? sg = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
> + ? ? ? if (!sg)
> + ? ? ? ? ? ? ? goto out;
> +
> + ? ? ? ret = sg_alloc_table(sg, nr_pages, GFP_KERNEL);
> + ? ? ? if (ret)
> + ? ? ? ? ? ? ? goto out;
> +
> + ? ? ? for_each_sg(sg->sgl, iter, nr_pages, i)
> + ? ? ? ? ? ? ? sg_set_page(iter, pages[i], PAGE_SIZE, 0);
> +
> + ? ? ? return sg;
> +out:
> + ? ? ? kfree(sg);
> + ? ? ? return NULL;
> +}
> +EXPORT_SYMBOL(drm_prime_pages_to_sg);
> +
> +/* helper function to cleanup a GEM/prime object */
> +void drm_prime_gem_destroy(struct drm_gem_object *obj, 

Re: [PATCH 1/7] drm: base prime support

[Kristian Høgsberg]

On Wed, Feb 22, 2012 at 2:29 PM, Ben Widawsky b...@bwidawsk.net wrote:
 From: Dave Airlie airl...@redhat.com

 ---
  drivers/gpu/drm/Makefile    |    2 +-
  drivers/gpu/drm/drm_drv.c   |    3 +
  drivers/gpu/drm/drm_gem.c   |    3 +-
  drivers/gpu/drm/drm_prime.c |  126 
 +++
  include/drm/drm.h           |   10 +++-
  include/drm/drmP.h          |   35 
  6 files changed, 176 insertions(+), 3 deletions(-)
  create mode 100644 drivers/gpu/drm/drm_prime.c

 diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
 index 0cde1b8..202f650 100644
 --- a/drivers/gpu/drm/Makefile
 +++ b/drivers/gpu/drm/Makefile
 @@ -12,7 +12,7 @@ drm-y       :=        drm_auth.o drm_buffer.o drm_bufs.o 
 drm_cache.o \
                drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
                drm_crtc.o drm_modes.o drm_edid.o \
                drm_info.o drm_debugfs.o drm_encoder_slave.o \
 -               drm_trace_points.o drm_global.o drm_usb.o
 +               drm_trace_points.o drm_global.o drm_usb.o drm_prime.o

  drm-$(CONFIG_COMPAT) += drm_ioc32.o

 diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
 index ebf7d3f..786b134 100644
 --- a/drivers/gpu/drm/drm_drv.c
 +++ b/drivers/gpu/drm/drm_drv.c
 @@ -135,6 +135,9 @@ static struct drm_ioctl_desc drm_ioctls[] = {
        DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, 
 DRM_AUTH|DRM_UNLOCKED),
        DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, 
 DRM_AUTH|DRM_UNLOCKED),

 +       DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
 drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
 +       DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
 drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
 +
        DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
 DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
        DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
 DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
        DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
 DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
 diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
 index f8625e2..e19a958 100644
 --- a/drivers/gpu/drm/drm_gem.c
 +++ b/drivers/gpu/drm/drm_gem.c
 @@ -145,6 +145,7 @@ int drm_gem_object_init(struct drm_device *dev,
        kref_init(obj-refcount);
        atomic_set(obj-handle_count, 0);
        obj-size = size;
 +       obj-prime_fd = -1;

        return 0;
  }
 @@ -166,7 +167,7 @@ int drm_gem_private_object_init(struct drm_device *dev,
        kref_init(obj-refcount);
        atomic_set(obj-handle_count, 0);
        obj-size = size;
 -
 +       obj-prime_fd = -1;
        return 0;
  }
  EXPORT_SYMBOL(drm_gem_private_object_init);
 diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
 new file mode 100644
 index 000..11f142f
 --- /dev/null
 +++ b/drivers/gpu/drm/drm_prime.c
 @@ -0,0 +1,126 @@
 +#include linux/export.h
 +#include linux/dma-buf.h
 +#include drmP.h
 +
 +struct drm_prime_member {
 +       struct list_head entry;
 +       struct dma_buf *dma_buf;
 +       uint32_t handle;
 +};
 +
 +int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
 +                                struct drm_file *file_priv)
 +{
 +       struct drm_prime_handle *args = data;
 +
 +       if (!drm_core_check_feature(dev, DRIVER_PRIME))
 +               return -EINVAL;
 +
 +       return dev-driver-prime_handle_to_fd(dev, file_priv, args-handle, 
 args-fd);

We need a way to pass flags to this so we can pass DRM_PRIME_CLOEXEC
(or whatever, but not O_CLOEXEC) to create the fd in close-on-exec
mode, and it needs to be available in the libdrm API.  See man
epoll_create1 for an example where we had to add a new brown-bag
syscall to allow this.

 +}
 +
 +int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
 +                                struct drm_file *file_priv)
 +{
 +       struct drm_prime_handle *args = data;
 +
 +       if (!drm_core_check_feature(dev, DRIVER_PRIME))
 +               return -EINVAL;
 +
 +       return dev-driver-prime_fd_to_handle(dev, file_priv, args-fd, 
 args-handle);
 +}
 +
 +struct sg_table *drm_prime_pages_to_sg(struct page **pages, int nr_pages)
 +{
 +       struct sg_table *sg = NULL;
 +       struct scatterlist *iter;
 +       int i;
 +       int ret;
 +
 +       sg = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
 +       if (!sg)
 +               goto out;
 +
 +       ret = sg_alloc_table(sg, nr_pages, GFP_KERNEL);
 +       if (ret)
 +               goto out;
 +
 +       for_each_sg(sg-sgl, iter, nr_pages, i)
 +               sg_set_page(iter, pages[i], PAGE_SIZE, 0);
 +
 +       return sg;
 +out:
 +       kfree(sg);
 +       return NULL;
 +}
 +EXPORT_SYMBOL(drm_prime_pages_to_sg);
 +
 +/* helper function to cleanup a GEM/prime object */
 +void drm_prime_gem_destroy(struct drm_gem_object *obj, struct sg_table *sg)
 +{
 +       struct dma_buf_attachment 

DRM KMS Modesetting

[Kristian Høgsberg]

2011/11/15 David Herrmann :
> 2011/11/15 Kristian H?gsberg :
>> On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes  
>> wrote:
>>> On Mon, 14 Nov 2011 21:47:09 +0100
>>> David Herrmann  wrote:
 > I had to modify the resolution the test was searching for
 > to 1920x1200 instead of 1024x600 since I tested on a DP attached
 > monitor, and fix the connector id, but other than that it seemed to
 > work fine.

 Thanks for testing. At least my code seems right now, but I still
 cannot get it to work on my machine. The output of modetest is:
 https://gist.github.com/1365083

 There is only one connected connector+encoder+mode so I don't know
 where the problem exactly is. Are there any debug options? Is it
 possible to query the EGLImage for width/height?
>>>
>>> Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
>>> width/stride correctly somewhere then. ?You'd have to walk through the
>>> gbm_dri2.c and egl_dri2.c code and see where the width is going off
>>> into the weeds.
>>
>> Could be, I know I've run Wayland on Pineview though, so that works at
>> least. ?David, did you try eglkms from mesa demos?
>>
>> http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c
>
> I tried it now. I get a black screen and in the left quarter there is
> one white triangle which fades to black. But again, the right 3/4 of
> the screen are black.
>
>> Kristian
>>
>
> I will try to debug my mesa package but this will probably take some
> time. If someone has an idea how to find the bug faster, just tell me
> ;)

It's all very odd.  The gbm allocation ends up in intel_create_image
in src/mesa/drivers/dri/intel/intel_screen.c, so you can try to
compare the stride, width and height there with what modetest uses.

Kristiain

DRM KMS Modesetting

[Kristian Høgsberg]

On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes  
wrote:
> On Mon, 14 Nov 2011 21:47:09 +0100
> David Herrmann  wrote:
>> > I had to modify the resolution the test was searching for
>> > to 1920x1200 instead of 1024x600 since I tested on a DP attached
>> > monitor, and fix the connector id, but other than that it seemed to
>> > work fine.
>>
>> Thanks for testing. At least my code seems right now, but I still
>> cannot get it to work on my machine. The output of modetest is:
>> https://gist.github.com/1365083
>>
>> There is only one connected connector+encoder+mode so I don't know
>> where the problem exactly is. Are there any debug options? Is it
>> possible to query the EGLImage for width/height?
>
> Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
> width/stride correctly somewhere then. ?You'd have to walk through the
> gbm_dri2.c and egl_dri2.c code and see where the width is going off
> into the weeds.

Could be, I know I've run Wayland on Pineview though, so that works at
least.  David, did you try eglkms from mesa demos?

http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c

Kristian

Re: DRM KMS Modesetting

[Kristian Høgsberg]

On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Mon, 14 Nov 2011 21:47:09 +0100
 David Herrmann dh.herrm...@googlemail.com wrote:
  I had to modify the resolution the test was searching for
  to 1920x1200 instead of 1024x600 since I tested on a DP attached
  monitor, and fix the connector id, but other than that it seemed to
  work fine.

 Thanks for testing. At least my code seems right now, but I still
 cannot get it to work on my machine. The output of modetest is:
 https://gist.github.com/1365083

 There is only one connected connector+encoder+mode so I don't know
 where the problem exactly is. Are there any debug options? Is it
 possible to query the EGLImage for width/height?

 Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
 width/stride correctly somewhere then.  You'd have to walk through the
 gbm_dri2.c and egl_dri2.c code and see where the width is going off
 into the weeds.

Could be, I know I've run Wayland on Pineview though, so that works at
least.  David, did you try eglkms from mesa demos?

http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c

Kristian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM KMS Modesetting

[Kristian Høgsberg]

2011/11/15 David Herrmann dh.herrm...@googlemail.com:
 2011/11/15 Kristian Høgsberg k...@bitplanet.net:
 On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbar...@virtuousgeek.org 
 wrote:
 On Mon, 14 Nov 2011 21:47:09 +0100
 David Herrmann dh.herrm...@googlemail.com wrote:
  I had to modify the resolution the test was searching for
  to 1920x1200 instead of 1024x600 since I tested on a DP attached
  monitor, and fix the connector id, but other than that it seemed to
  work fine.

 Thanks for testing. At least my code seems right now, but I still
 cannot get it to work on my machine. The output of modetest is:
 https://gist.github.com/1365083

 There is only one connected connector+encoder+mode so I don't know
 where the problem exactly is. Are there any debug options? Is it
 possible to query the EGLImage for width/height?

 Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
 width/stride correctly somewhere then.  You'd have to walk through the
 gbm_dri2.c and egl_dri2.c code and see where the width is going off
 into the weeds.

 Could be, I know I've run Wayland on Pineview though, so that works at
 least.  David, did you try eglkms from mesa demos?

 http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c

 I tried it now. I get a black screen and in the left quarter there is
 one white triangle which fades to black. But again, the right 3/4 of
 the screen are black.

 Kristian


 I will try to debug my mesa package but this will probably take some
 time. If someone has an idea how to find the bug faster, just tell me
 ;)

It's all very odd.  The gbm allocation ends up in intel_create_image
in src/mesa/drivers/dri/intel/intel_screen.c, so you can try to
compare the stride, width and height there with what modetest uses.

Kristiain
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/core: add ioctl to query device/driver capabilities

[Kristian Høgsberg]

On Sun, Feb 20, 2011 at 8:17 PM, Ben Skeggs  wrote:
> From: Ben Skeggs 
>
> We're coming to see a need to have a set of generic capability checks in
> the core DRM, in addition to the driver-specific ioctls that already
> exist.

Looks good to me, just one comment: I don't think we need the driver
callout.  We only need the drm get cap for generic drm features and
drm itself should know whether or not it has the support, typically by
looking at the driver_features flags.

Kristian

> This patch defines an ioctl to do as such, but does not yet define any
> capabilities.
>
> Signed-off-by: Ben Skeggs 
> ---
> ?drivers/gpu/drm/drm_drv.c ? | ? ?1 +
> ?drivers/gpu/drm/drm_ioctl.c | ? 13 +
> ?include/drm/drm.h ? ? ? ? ? | ? ?7 +++
> ?include/drm/drmP.h ? ? ? ? ?| ? ?9 +
> ?4 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 271835a..ad86135 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -67,6 +67,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
> ? ? ? ?DRM_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_getmap, 0),
> ? ? ? ?DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, 0),
> ? ? ? ?DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, 0),
> + ? ? ? DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap, 0),
> ? ? ? ?DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_MASTER),
>
> ? ? ? ?DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_setunique, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 47db4df..15a244b 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -365,6 +365,19 @@ int drm_getstats(struct drm_device *dev, void *data,
> ?}
>
> ?/**
> + * Get device/driver capabilities
> + */
> +int drm_getcap(struct drm_device *dev, void *data, struct drm_file 
> *file_priv)
> +{
> + ? ? ? struct drm_get_cap *req = data;
> +
> + ? ? ? req->value = 0;
> + ? ? ? if (dev->driver->get_cap)
> + ? ? ? ? ? ? ? req->value = (*dev->driver->get_cap)(dev, req->capability);
> + ? ? ? return 0;
> +}
> +
> +/**
> ?* Setversion ioctl.
> ?*
> ?* \param inode device inode.
> diff --git a/include/drm/drm.h b/include/drm/drm.h
> index e5f7061..7254f1a 100644
> --- a/include/drm/drm.h
> +++ b/include/drm/drm.h
> @@ -608,6 +608,12 @@ struct drm_gem_open {
> ? ? ? ?__u64 size;
> ?};
>
> +/** DRM_IOCTL_GET_CAP ioctl argument type */
> +struct drm_get_cap {
> + ? ? ? __u64 capability;
> + ? ? ? __u64 value;
> +};
> +
> ?#include "drm_mode.h"
>
> ?#define DRM_IOCTL_BASE ? ? ? ? ? ? ? ? 'd'
> @@ -628,6 +634,7 @@ struct drm_gem_open {
> ?#define DRM_IOCTL_GEM_CLOSE ? ? ? ? ? ?DRM_IOW (0x09, struct drm_gem_close)
> ?#define DRM_IOCTL_GEM_FLINK ? ? ? ? ? ?DRM_IOWR(0x0a, struct drm_gem_flink)
> ?#define DRM_IOCTL_GEM_OPEN ? ? ? ? ? ? DRM_IOWR(0x0b, struct drm_gem_open)
> +#define DRM_IOCTL_GET_CAP ? ? ? ? ? ? ?DRM_IOWR(0x0c, struct drm_get_cap)
>
> ?#define DRM_IOCTL_SET_UNIQUE ? ? ? ? ? DRM_IOW( 0x10, struct drm_unique)
> ?#define DRM_IOCTL_AUTH_MAGIC ? ? ? ? ? DRM_IOW( 0x11, struct drm_auth)
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index fe29aad..a3d5ce8 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -869,6 +869,13 @@ struct drm_driver {
> ? ? ? ?void (*debugfs_cleanup)(struct drm_minor *minor);
>
> ? ? ? ?/**
> + ? ? ? ?* Driver-specific routine to query capabilities of device/driver.
> + ? ? ? ?*
> + ? ? ? ?* If not present, core drm will assume a return value of 0.
> + ? ? ? ?*/
> + ? ? ? u64 (*get_cap)(struct drm_device *dev, u64 cap);
> +
> + ? ? ? /**
> ? ? ? ? * Driver-specific constructor for drm_gem_objects, to set up
> ? ? ? ? * obj->driver_private.
> ? ? ? ? *
> @@ -1264,6 +1271,8 @@ extern int drm_getclient(struct drm_device *dev, void 
> *data,
> ? ? ? ? ? ? ? ? ? ? ? ? struct drm_file *file_priv);
> ?extern int drm_getstats(struct drm_device *dev, void *data,
> ? ? ? ? ? ? ? ? ? ? ? ?struct drm_file *file_priv);
> +extern int drm_getcap(struct drm_device *dev, void *data,
> + ? ? ? ? ? ? ? ? ? ? struct drm_file *file_priv);
> ?extern int drm_setversion(struct drm_device *dev, void *data,
> ? ? ? ? ? ? ? ? ? ? ? ? ?struct drm_file *file_priv);
> ?extern int drm_noop(struct drm_device *dev, void *data,
> --
> 1.7.4
>
>

Re: [PATCH] drm/core: add ioctl to query device/driver capabilities

[Kristian Høgsberg]

On Sun, Feb 20, 2011 at 8:17 PM, Ben Skeggs skeg...@gmail.com wrote:
 From: Ben Skeggs bske...@redhat.com

 We're coming to see a need to have a set of generic capability checks in
 the core DRM, in addition to the driver-specific ioctls that already
 exist.

Looks good to me, just one comment: I don't think we need the driver
callout.  We only need the drm get cap for generic drm features and
drm itself should know whether or not it has the support, typically by
looking at the driver_features flags.

Kristian

 This patch defines an ioctl to do as such, but does not yet define any
 capabilities.

 Signed-off-by: Ben Skeggs bske...@redhat.com
 ---
  drivers/gpu/drm/drm_drv.c   |    1 +
  drivers/gpu/drm/drm_ioctl.c |   13 +
  include/drm/drm.h           |    7 +++
  include/drm/drmP.h          |    9 +
  4 files changed, 30 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
 index 271835a..ad86135 100644
 --- a/drivers/gpu/drm/drm_drv.c
 +++ b/drivers/gpu/drm/drm_drv.c
 @@ -67,6 +67,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
        DRM_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_getmap, 0),
        DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, 0),
        DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, 0),
 +       DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap, 0),
        DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_MASTER),

        DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_setunique, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
 index 47db4df..15a244b 100644
 --- a/drivers/gpu/drm/drm_ioctl.c
 +++ b/drivers/gpu/drm/drm_ioctl.c
 @@ -365,6 +365,19 @@ int drm_getstats(struct drm_device *dev, void *data,
  }

  /**
 + * Get device/driver capabilities
 + */
 +int drm_getcap(struct drm_device *dev, void *data, struct drm_file 
 *file_priv)
 +{
 +       struct drm_get_cap *req = data;
 +
 +       req-value = 0;
 +       if (dev-driver-get_cap)
 +               req-value = (*dev-driver-get_cap)(dev, req-capability);
 +       return 0;
 +}
 +
 +/**
  * Setversion ioctl.
  *
  * \param inode device inode.
 diff --git a/include/drm/drm.h b/include/drm/drm.h
 index e5f7061..7254f1a 100644
 --- a/include/drm/drm.h
 +++ b/include/drm/drm.h
 @@ -608,6 +608,12 @@ struct drm_gem_open {
        __u64 size;
  };

 +/** DRM_IOCTL_GET_CAP ioctl argument type */
 +struct drm_get_cap {
 +       __u64 capability;
 +       __u64 value;
 +};
 +
  #include drm_mode.h

  #define DRM_IOCTL_BASE                 'd'
 @@ -628,6 +634,7 @@ struct drm_gem_open {
  #define DRM_IOCTL_GEM_CLOSE            DRM_IOW (0x09, struct drm_gem_close)
  #define DRM_IOCTL_GEM_FLINK            DRM_IOWR(0x0a, struct drm_gem_flink)
  #define DRM_IOCTL_GEM_OPEN             DRM_IOWR(0x0b, struct drm_gem_open)
 +#define DRM_IOCTL_GET_CAP              DRM_IOWR(0x0c, struct drm_get_cap)

  #define DRM_IOCTL_SET_UNIQUE           DRM_IOW( 0x10, struct drm_unique)
  #define DRM_IOCTL_AUTH_MAGIC           DRM_IOW( 0x11, struct drm_auth)
 diff --git a/include/drm/drmP.h b/include/drm/drmP.h
 index fe29aad..a3d5ce8 100644
 --- a/include/drm/drmP.h
 +++ b/include/drm/drmP.h
 @@ -869,6 +869,13 @@ struct drm_driver {
        void (*debugfs_cleanup)(struct drm_minor *minor);

        /**
 +        * Driver-specific routine to query capabilities of device/driver.
 +        *
 +        * If not present, core drm will assume a return value of 0.
 +        */
 +       u64 (*get_cap)(struct drm_device *dev, u64 cap);
 +
 +       /**
         * Driver-specific constructor for drm_gem_objects, to set up
         * obj-driver_private.
         *
 @@ -1264,6 +1271,8 @@ extern int drm_getclient(struct drm_device *dev, void 
 *data,
                         struct drm_file *file_priv);
  extern int drm_getstats(struct drm_device *dev, void *data,
                        struct drm_file *file_priv);
 +extern int drm_getcap(struct drm_device *dev, void *data,
 +                     struct drm_file *file_priv);
  extern int drm_setversion(struct drm_device *dev, void *data,
                          struct drm_file *file_priv);
  extern int drm_noop(struct drm_device *dev, void *data,
 --
 1.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm: fix headers to include linux/types.h

[Kristian Høgsberg]

On Wed, Dec 1, 2010 at 11:54 AM, Julien Cristau  wrote:
> On Wed, Dec ?1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote:
>
>> For headers that get exported to userland and make use of u32 style
>> type names, it is advised to include linux/types.h.
>>
>> This fixes 5 headers_check warnings.
>>
> How many times does this need to be NAKed? ?These headers are shared
> with the BSDs, and they include drm.h which has the linux/types.h
> include on linux already.

I'll NAK it too, if that helps.

Kristian

Re: [PATCH 1/4] drm: fix headers to include linux/types.h

[Kristian Høgsberg]

On Wed, Dec 1, 2010 at 11:54 AM, Julien Cristau jcris...@debian.org wrote:
 On Wed, Dec  1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote:

 For headers that get exported to userland and make use of u32 style
 type names, it is advised to include linux/types.h.

 This fixes 5 headers_check warnings.

 How many times does this need to be NAKed?  These headers are shared
 with the BSDs, and they include drm.h which has the linux/types.h
 include on linux already.

I'll NAK it too, if that helps.

Kristian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/9] drivers/gpu/drm/drm_stub.c: Use printf extension %pV

[Kristian Høgsberg]

On Tue, Nov 9, 2010 at 7:35 PM, Joe Perches  wrote:
> Using %pV reduces the number of printk calls and
> eliminates any possible message interleaving from
> other printk calls.
>
> Signed-off-by: Joe Perches 
> ---
> ?drivers/gpu/drm/drm_stub.c | ? 14 +++---
> ?1 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index cdc89ee..e632527 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -57,13 +57,21 @@ void drm_ut_debug_printk(unsigned int request_level,
> ? ? ? ? ? ? ? ? ? ? ? ? const char *function_name,
> ? ? ? ? ? ? ? ? ? ? ? ? const char *format, ...)
> ?{
> + ? ? ? struct va_format vaf;
> ? ? ? ?va_list args;
>
> ? ? ? ?if (drm_debug & request_level) {
> - ? ? ? ? ? ? ? if (function_name)
> - ? ? ? ? ? ? ? ? ? ? ? printk(KERN_DEBUG "[%s:%s], ", prefix, function_name);
> ? ? ? ? ? ? ? ?va_start(args, format);
> - ? ? ? ? ? ? ? vprintk(format, args);
> +
> + ? ? ? ? ? ? ? vaf.fmt = format;
> + ? ? ? ? ? ? ? vaf.va = 
> +
> + ? ? ? ? ? ? ? if (function_name)
> + ? ? ? ? ? ? ? ? ? ? ? printk(KERN_DEBUG "[%s:%s], %pV",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?prefix, function_name, );
> + ? ? ? ? ? ? ? else
> + ? ? ? ? ? ? ? ? ? ? ? printk(KERN_DEBUG "%pV", );

Wouldn't it be easier and more convenient to just make the %pV format
specifier just expect a format string and the va_arg list?  Like this

  printk(KERN_DEBUG "%pV", format, );

I mean, the %pV is kernel specific and we can just change how it works.

Kristian

Re: [PATCH 1/9] drivers/gpu/drm/drm_stub.c: Use printf extension %pV

[Kristian Høgsberg]

On Tue, Nov 9, 2010 at 7:35 PM, Joe Perches j...@perches.com wrote:
 Using %pV reduces the number of printk calls and
 eliminates any possible message interleaving from
 other printk calls.

 Signed-off-by: Joe Perches j...@perches.com
 ---
  drivers/gpu/drm/drm_stub.c |   14 +++---
  1 files changed, 11 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
 index cdc89ee..e632527 100644
 --- a/drivers/gpu/drm/drm_stub.c
 +++ b/drivers/gpu/drm/drm_stub.c
 @@ -57,13 +57,21 @@ void drm_ut_debug_printk(unsigned int request_level,
                         const char *function_name,
                         const char *format, ...)
  {
 +       struct va_format vaf;
        va_list args;

        if (drm_debug  request_level) {
 -               if (function_name)
 -                       printk(KERN_DEBUG [%s:%s], , prefix, function_name);
                va_start(args, format);
 -               vprintk(format, args);
 +
 +               vaf.fmt = format;
 +               vaf.va = args;
 +
 +               if (function_name)
 +                       printk(KERN_DEBUG [%s:%s], %pV,
 +                              prefix, function_name, vaf);
 +               else
 +                       printk(KERN_DEBUG %pV, vaf);

Wouldn't it be easier and more convenient to just make the %pV format
specifier just expect a format string and the va_arg list?  Like this

  printk(KERN_DEBUG %pV, format, args);

I mean, the %pV is kernel specific and we can just change how it works.

Kristian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 14/14] drm: kill agp indirection mess

[Kristian Høgsberg]

On Mon, Aug 23, 2010 at 4:53 PM, Daniel Vetter  
wrote:
> There's no point in jumping through two indirections. So kill one
> and call the kernels agp functions directly.
>
> Signed-off-by: Daniel Vetter 
> ---
> ?drivers/gpu/drm/drm_agpsupport.c | ? 40 +++--
> ?drivers/gpu/drm/drm_memory.c ? ? | ? 12 ++
> ?include/drm/drmP.h ? ? ? ? ? ? ? | ? ?5 
> ?3 files changed, 7 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
> b/drivers/gpu/drm/drm_agpsupport.c
> index ba38e01..252fdb9 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -193,7 +193,7 @@ int drm_agp_enable_ioctl(struct drm_device *dev, void 
> *data,
> ?* \return zero on success or a negative number on failure.
> ?*
> ?* Verifies the AGP device is present and has been acquired, allocates the
> - * memory via alloc_agp() and creates a drm_agp_mem entry for it.
> + * memory via agp_allocate_memory() and creates a drm_agp_mem entry for it.
> ?*/
> ?int drm_agp_alloc(struct drm_device *dev, struct drm_agp_buffer *request)
> ?{
> @@ -211,7 +211,7 @@ int drm_agp_alloc(struct drm_device *dev, struct 
> drm_agp_buffer *request)
>
> ? ? ? ?pages = (request->size + PAGE_SIZE - 1) / PAGE_SIZE;
> ? ? ? ?type = (u32) request->type;
> - ? ? ? if (!(memory = drm_alloc_agp(dev, pages, type))) {
> + ? ? ? if (!(memory = agp_allocate_memory(dev->agp->bridge, pages, type))) {
> ? ? ? ? ? ? ? ?kfree(entry);
> ? ? ? ? ? ? ? ?return -ENOMEM;
> ? ? ? ?}
> @@ -423,38 +423,6 @@ struct drm_agp_head *drm_agp_init(struct drm_device *dev)
> ? ? ? ?return head;
> ?}
>
> -/** Calls agp_allocate_memory() */
> -DRM_AGP_MEM *drm_agp_allocate_memory(struct agp_bridge_data * bridge,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?size_t pages, u32 type)
> -{
> - ? ? ? return agp_allocate_memory(bridge, pages, type);
> -}
> -
> -/** Calls agp_free_memory() */
> -int drm_agp_free_memory(DRM_AGP_MEM * handle)
> -{
> - ? ? ? if (!handle)
> - ? ? ? ? ? ? ? return 0;
> - ? ? ? agp_free_memory(handle);
> - ? ? ? return 1;
> -}
> -
> -/** Calls agp_bind_memory() */
> -int drm_agp_bind_memory(DRM_AGP_MEM * handle, off_t start)
> -{
> - ? ? ? if (!handle)
> - ? ? ? ? ? ? ? return -EINVAL;
> - ? ? ? return agp_bind_memory(handle, start);
> -}
> -
> -/** Calls agp_unbind_memory() */
> -int drm_agp_unbind_memory(DRM_AGP_MEM * handle)
> -{
> - ? ? ? if (!handle)
> - ? ? ? ? ? ? ? return -EINVAL;
> - ? ? ? return agp_unbind_memory(handle);
> -}
> -
> ?/**
> ?* Binds a collection of pages into AGP memory at the given offset, returning
> ?* the AGP memory structure containing them.
> @@ -474,7 +442,7 @@ drm_agp_bind_pages(struct drm_device *dev,
>
> ? ? ? ?DRM_DEBUG("\n");
>
> - ? ? ? mem = drm_agp_allocate_memory(dev->agp->bridge, num_pages,
> + ? ? ? mem = agp_allocate_memory(dev->agp->bridge, num_pages,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?type);
> ? ? ? ?if (mem == NULL) {
> ? ? ? ? ? ? ? ?DRM_ERROR("Failed to allocate memory for %ld pages\n",
> @@ -487,7 +455,7 @@ drm_agp_bind_pages(struct drm_device *dev,
> ? ? ? ?mem->page_count = num_pages;
>
> ? ? ? ?mem->is_flushed = true;
> - ? ? ? ret = drm_agp_bind_memory(mem, gtt_offset / PAGE_SIZE);
> + ? ? ? ret = agp_bind_memory(mem, gtt_offset / PAGE_SIZE);
> ? ? ? ?if (ret != 0) {
> ? ? ? ? ? ? ? ?DRM_ERROR("Failed to bind AGP memory: %d\n", ret);
> ? ? ? ? ? ? ? ?agp_free_memory(mem);
> diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
> index 70ca27e..c9b8050 100644
> --- a/drivers/gpu/drm/drm_memory.c
> +++ b/drivers/gpu/drm/drm_memory.c
> @@ -99,29 +99,23 @@ static void *agp_remap(unsigned long offset, unsigned 
> long size,
> ? ? ? ?return addr;
> ?}
>
> -/** Wrapper around agp_allocate_memory() */
> -DRM_AGP_MEM *drm_alloc_agp(struct drm_device * dev, int pages, u32 type)
> -{
> - ? ? ? return drm_agp_allocate_memory(dev->agp->bridge, pages, type);
> -}
> -
> ?/** Wrapper around agp_free_memory() */
> ?void drm_free_agp(DRM_AGP_MEM * handle, int pages)
> ?{
> - ? ? ? drm_agp_free_memory(handle);
> + ? ? ? agp_free_memory(handle);
> ?}
> ?EXPORT_SYMBOL(drm_free_agp);
>
> ?/** Wrapper around agp_bind_memory() */
> ?int drm_bind_agp(DRM_AGP_MEM * handle, unsigned int start)
> ?{
> - ? ? ? return drm_agp_bind_memory(handle, start);
> + ? ? ? return agp_bind_memory(handle, start);
> ?}
>
> ?/** Wrapper around agp_unbind_memory() */
> ?int drm_unbind_agp(DRM_AGP_MEM * handle)
> ?{
> - ? ? ? return drm_agp_unbind_memory(handle);
> + ? ? ? return agp_unbind_memory(handle);
> ?}
> ?EXPORT_SYMBOL(drm_unbind_agp);

Any reason to keep these last three wrappers around?

Kristian