search for: drm_public

Displaying 11 results from an estimated 11 matches for "drm_public".

Did you mean: dll_public
2014 Jul 31
1
[libdrm PATCH 1/3] nouveau: Only export public functions.
...\ -I$(top_srcdir)/nouveau \ $(PTHREADSTUBS_CFLAGS) \ diff --git a/nouveau/bufctx.c b/nouveau/bufctx.c index 23d6f09..fdd3164 100644 --- a/nouveau/bufctx.c +++ b/nouveau/bufctx.c @@ -68,7 +68,7 @@ nouveau_bufctx(struct nouveau_bufctx *bctx) return (struct nouveau_bufctx_priv *)bctx; } -int +drm_public int nouveau_bufctx_new(struct nouveau_client *client, int bins, struct nouveau_bufctx **pbctx) { @@ -88,7 +88,7 @@ nouveau_bufctx_new(struct nouveau_client *client, int bins, return -ENOMEM; } -void +drm_public void nouveau_bufctx_del(struct nouveau_bufctx **pbctx) { struct nouveau...
2014 Jul 30
2
[PATCH libdrm] configure: Support symbol visibility when available
...idia.com> > > Checks whether or not the compiler supports the -fvisibility option. If > so it sets the VISIBILITY_CFLAGS variable which can be added to the per > directory AM_CFLAGS where appropriate. > > By default all symbols will be hidden via the VISIBILITY_CFLAGS. The > drm_public macro can be used to mark symbols that should be exported. hmm, maybe dumb question, I might possibly have missed some discussion on this, but if we merged this without a heap of patches to export libdrm and libdrm_foo syms, wouldn't everything be hidden? Maybe we should introduce drm_public...
2014 Jul 30
3
[PATCH] libdrm: hide all private symbols
On 30/07/14 11:16, Christian K?nig wrote: > [CCing Emil as well] > > Am 30.07.2014 um 11:38 schrieb Maarten Lankhorst: >> Using -export-symbols-regex all private symbols are hidden, resulting in the >> following changes: > > Wasn't "-export-symbols-regex" exactly that stuff we are trying to avoid in mesa? > IMHO we should try to pick up Thierry
2014 Jul 30
0
[PATCH libdrm] configure: Support symbol visibility when available
...t; Checks whether or not the compiler supports the -fvisibility option. If >> so it sets the VISIBILITY_CFLAGS variable which can be added to the per >> directory AM_CFLAGS where appropriate. >> >> By default all symbols will be hidden via the VISIBILITY_CFLAGS. The >> drm_public macro can be used to mark symbols that should be exported. > > hmm, maybe dumb question, I might possibly have missed some discussion > on this, but if we merged this without a heap of patches to export > libdrm and libdrm_foo syms, wouldn't everything be hidden? > > Maybe w...
2018 Oct 04
0
[ANNOUNCE] libdrm 2.4.95
...gitlab-ci builds of libdrm xf86drm: merge get_normal_pci_path() into get_real_pci_path() xf86drm: rename "real_path" to "pci_path" gitlab-ci: use templates to deduplicate the build commands headers/README: fix/add link to drm-next intel: add missing drm_public exports nouveau: add missing drm_public exports radeon: add missing drm_public exports omap: fix symbol annotations freedreno: add missing drm_public Ezequiel Garcia (1): tests/util: Add support for sun4i-drm driver Junwei Zhang (1): amdgpu: add error return va...
2014 Jul 30
0
[PATCH libdrm] configure: Support symbol visibility when available
...Thierry Reding <treding at nvidia.com> Checks whether or not the compiler supports the -fvisibility option. If so it sets the VISIBILITY_CFLAGS variable which can be added to the per directory AM_CFLAGS where appropriate. By default all symbols will be hidden via the VISIBILITY_CFLAGS. The drm_public macro can be used to mark symbols that should be exported. Signed-off-by: Thierry Reding <treding at nvidia.com> --- Changes in v3: - distribute libdrm.h Makefile.am | 1 + configure.ac | 20 ++++++++++++++++++++ libdrm.h | 34 ++++++++++++++++++++++++++++++++++ 3 files changed, 55 i...
2015 Feb 24
0
[PATCH 2/2] nouveau: Do not add most bo's to the global bo list.
...o) +{ + if (!nvbo->head.next) { + struct nouveau_device_priv *nvdev = nouveau_device(nvbo->base.device); + pthread_mutex_lock(&nvdev->lock); + if (!nvbo->head.next) + DRMLISTADD(&nvbo->head, &nvdev->bo_list); + pthread_mutex_unlock(&nvdev->lock); + } +} + drm_public int nouveau_bo_wrap(struct nouveau_device *dev, uint32_t handle, struct nouveau_bo **pbo) @@ -494,13 +499,17 @@ nouveau_bo_name_get(struct nouveau_bo *bo, uint32_t *name) struct nouveau_bo_priv *nvbo = nouveau_bo(bo); *name = nvbo->name; - if (!*name || *name == ~0U) { + if (!*name) {...
2015 May 07
0
[ANNOUNCE] libdrm 2.4.61
...nouveau: add symbols test libkms: annotate private symbols libkms: add symbols test exynos: add symbols test omap: add symbols test tegra: add symbols test drm: rename libdrm{,_macros}.h drm: remove no longer needed VISIBILITY_CFLAGS drm: remove drm_public macro configure: request/set the compiler in C99 mode drm: use c99 __func__ over __FUNCTION__ man: rework the Makefile.am android: set the HAVE_VISIBILITY define freedreno: link against CLOCK_LIB Greg Hackmann (1): Add missing <strings.h> includes Jan Ves...
2015 Feb 26
4
[PATCH v2 1/4] Add atomic_inc_return to atomics.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at ubuntu.com> --- xf86atomic.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xf86atomic.h b/xf86atomic.h index 8c4b696..17fb088 100644 --- a/xf86atomic.h +++ b/xf86atomic.h @@ -49,6 +49,7 @@ typedef struct { # define atomic_read(x) ((x)->atomic) # define atomic_set(x, val) ((x)->atomic = (val)) # define atomic_inc(x)
2014 Sep 26
14
[RFC] Explicit synchronization for Nouveau
Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes
2015 Feb 24
4
[PATCH 1/2] nouveau: make nouveau importing global buffers completely thread-safe, with tests
While I've closed off most races in a previous patch, a small race still existed where importing then unreffing cound cause an invalid bo. Add a test for this case. Racing sequence fixed: - thread 1 releases bo, refcount drops to zero, blocks on acquiring nvdev->lock. - thread 2 increases refcount to 1. - thread 2 decreases refcount to zero, blocks on acquiring nvdev->lock. At this