Re: [Mesa-dev] [PATCH] i915: Fix black buffers when importing prime fds
Could someone take a short look?
It should be possible to validate it by looking at the other similar code
paths:
i.e look at intel_from_planar and intel_create_image_from_renderbuffer and
intel_create_image_from_name
each of those contain this call...
On Wed, Aug 27, 2014 at 9:36 AM, Andreas Pokorny
andreas.poko...@canonical.com wrote:
Width and Height of the imported image was never initialized from the
imported bo.
Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com
---
src/mesa/drivers/dri/i915/intel_screen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 3aaa45f..00d8580 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -616,6 +616,8 @@ intel_create_image_from_fds(__DRIscreen *screen,
return NULL;
}
+ intel_setup_image_from_dimensions(image);
+
image-planar_format = f;
for (i = 0; i f-nplanes; i++) {
index = f-planes[i].buffer_index;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] egl/drm: expose KHR_image_pixmap extension
This changes enables EGL_KHR_image_pixmap in the egl drm platform, which is implemented there but has not been advertised yet. Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com --- src/egl/drivers/dri2/platform_drm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/egl/drivers/dri2/platform_drm.c b/src/egl/drivers/dri2/platform_drm.c index e272beb..a39f8ae 100644 --- a/src/egl/drivers/dri2/platform_drm.c +++ b/src/egl/drivers/dri2/platform_drm.c @@ -681,6 +681,7 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp) i + 1, EGL_WINDOW_BIT, attr_list, NULL); } + disp-Extensions.KHR_image_pixmap = EGL_TRUE; if (dri2_dpy-dri2) disp-Extensions.EXT_buffer_age = EGL_TRUE; -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i915: Fix black buffers when importing prime fds
Hi,
I have to apologize again for the wrong tag. This fix is also needed on
10.3.
regards
Andreas
On Wed, Aug 27, 2014 at 9:36 AM, Andreas Pokorny
andreas.poko...@canonical.com wrote:
Width and Height of the imported image was never initialized from the
imported bo.
Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com
---
src/mesa/drivers/dri/i915/intel_screen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 3aaa45f..00d8580 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -616,6 +616,8 @@ intel_create_image_from_fds(__DRIscreen *screen,
return NULL;
}
+ intel_setup_image_from_dimensions(image);
+
image-planar_format = f;
for (i = 0; i f-nplanes; i++) {
index = f-planes[i].buffer_index;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] kms-swrast: Support Prime fd handling
Hi,
Thanks for looking through that again.
On Thu, Aug 28, 2014 at 4:01 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 22/08/14 17:41, Andreas Pokorny wrote:
Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast screen.
Hi Andreas,
I'm hoping that Giovanni will take a look. After all kms-dri is his
creation.
From my POV the patch is good and should be safe to go in 10.3 on the point
that the driver/target was introduced with 10.3. There is a trivial
nit-pick
which I'll squash before committing later on this week.
Btw in the future can you please include Cc: branch number
mesa-stable...
[1] in the commit message - it will ease things a bit :)
Cheers,
Emil
[1] Marking a commit as a candidate for a stable branch
http://mesa3d.org/devinfo.html
Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com
---
[snip]
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index c9934bb..ba0660c 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
[snip]
@@ -231,17 +264,34 @@ kms_sw_displaytarget_from_handle(struct sw_winsys
*ws,
struct kms_sw_winsys *kms_sw = kms_sw_winsys(ws);
struct kms_sw_displaytarget *kms_sw_dt;
- assert(whandle-type == DRM_API_HANDLE_TYPE_KMS);
+ assert(whandle-type == DRM_API_HANDLE_TYPE_KMS ||
+ whandle-type == DRM_API_HANDLE_TYPE_FD);
- LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
- if (kms_sw_dt-handle == whandle-handle) {
+ switch(whandle-type) {
+ case DRM_API_HANDLE_TYPE_FD:
+ kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw,
whandle-handle);
+ if (kms_sw_dt) {
kms_sw_dt-ref_count++;
+ kms_sw_dt-width = templ-width0;
+ kms_sw_dt-height = templ-height0;
+ kms_sw_dt-stride = whandle-stride;
+ if (stride)
Any objections on dropping the above conditional before committing?
The if (stride)? - Oh I see the original code did not test for that.
No objections.
regards
Andreas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] kms-swrast: Support Prime fd handling
Hi, On Thu, Aug 28, 2014 at 6:09 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: On Thu, Aug 28, 2014 at 4:01 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 22/08/14 17:41, Andreas Pokorny wrote: Allows using prime fds as display target and from display target. Test for PRIME capability after initializing kms_swrast screen. Hi Andreas, I'm hoping that Giovanni will take a look. After all kms-dri is his creation. I'm not sure I'm the right person to look at this code. After all I'm not a mesa developer. From a cursory review, the patches look good to me, but what I'm not seeing are the necessary EGL changes to make use of prime fds with kms-swrast, eg. EGL_WL_bind_wayland_display is still not exposed, even though it could be implemented using prime fds. I have no clue on the current state of what wayland requires. There seem to be a lot of options now. I assumed the patch is one of the necessary pieces. Another thing is, you briefly mentioned the generic GEM ioctls. If drivers really can use the generic GEM_FLINK/GEM_OPEN ioctl to give a name to dumb buffers, then indeed the kms-swrast driver is capable of buffer sharing (I always assumed that a somehow real GEM was necessary, and that the simple one in qxl/cirrus/simpledrm was not enough). I'd like to see that implemented first, which would allow to remove a good amount of complexity and special casing in gallium and egl (and would allow using kms-swrast for faster sw wayland too). I was about to do that, then recent regressions in kvm utils and some low hanging fruits in i915 distracted me. .. so real soon now.. regards Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i915: Fix missing image size in imported dma_bufs
Hi, This one liner should apply on top of master and the two release branches. It fixes 'black windows' when importing prime fds on gpus using the i915 driver paths. regards Andreas Andreas Pokorny (1): i915: Fix black buffers when importing prime fds src/mesa/drivers/dri/i915/intel_screen.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i915: Fix black buffers when importing prime fds
Width and Height of the imported image was never initialized from the
imported bo.
Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com
---
src/mesa/drivers/dri/i915/intel_screen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 3aaa45f..00d8580 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -616,6 +616,8 @@ intel_create_image_from_fds(__DRIscreen *screen,
return NULL;
}
+ intel_setup_image_from_dimensions(image);
+
image-planar_format = f;
for (i = 0; i f-nplanes; i++) {
index = f-planes[i].buffer_index;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] kms-swrast: Support Prime fd handling
Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast screen.
Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com
---
src/gallium/state_trackers/dri/dri2.c | 8 +++
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 ---
2 files changed, 78 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index a63448d..82f8a47 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1333,6 +1333,7 @@ dri_kms_init_screen(__DRIscreen * sPriv)
const __DRIconfig **configs;
struct dri_screen *screen;
struct pipe_screen *pscreen = NULL;
+ uint64_t cap;
screen = CALLOC_STRUCT(dri_screen);
if (!screen)
@@ -1344,6 +1345,13 @@ dri_kms_init_screen(__DRIscreen * sPriv)
sPriv-driverPrivate = (void *)screen;
pscreen = kms_swrast_create_screen(screen-fd);
+
+ if (drmGetCap(sPriv-fd, DRM_CAP_PRIME, cap) == 0
+ (cap DRM_PRIME_CAP_IMPORT)) {
+ dri2ImageExtension.createImageFromFds = dri2_from_fds;
+ dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
+ }
+
sPriv-extensions = dri_screen_extensions;
/* dri_init_screen_helper checks pscreen for us */
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index c9934bb..286bd9c 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -38,6 +38,7 @@
#include sys/mman.h
#include unistd.h
#include dlfcn.h
+#include fcntl.h
#include xf86drm.h
#include pipe/p_compiler.h
@@ -210,6 +211,38 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
return kms_sw_dt-mapped;
}
+static struct kms_sw_displaytarget *
+kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd)
+{
+ uint32_t handle;
+ struct kms_sw_displaytarget * kms_sw_dt;
+ int ret;
+
+ ret = drmPrimeFDToHandle(kms_sw-fd, fd, handle);
+
+ if (ret)
+ return NULL;
+
+ kms_sw_dt = CALLOC_STRUCT(kms_sw_displaytarget);
+ if (!kms_sw_dt)
+ return NULL;
+
+ kms_sw_dt-ref_count = 1;
+ kms_sw_dt-handle = handle;
+ kms_sw_dt-size = lseek(fd, 0, SEEK_END);
+
+ if (kms_sw_dt-size == (off_t)-1) {
+ FREE(kms_sw_dt);
+ return NULL;
+ }
+
+ lseek(fd, 0, SEEK_SET);
+
+ list_add(kms_sw_dt-link, kms_sw-bo_list);
+
+ return kms_sw_dt;
+}
+
static void
kms_sw_displaytarget_unmap(struct sw_winsys *ws,
struct sw_displaytarget *dt)
@@ -231,17 +264,34 @@ kms_sw_displaytarget_from_handle(struct sw_winsys *ws,
struct kms_sw_winsys *kms_sw = kms_sw_winsys(ws);
struct kms_sw_displaytarget *kms_sw_dt;
- assert(whandle-type == DRM_API_HANDLE_TYPE_KMS);
+ assert(whandle-type == DRM_API_HANDLE_TYPE_KMS ||
+ whandle-type == DRM_API_HANDLE_TYPE_FD);
- LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
- if (kms_sw_dt-handle == whandle-handle) {
+ switch(whandle-type) {
+ case DRM_API_HANDLE_TYPE_FD:
+ kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw, whandle-handle);
+ if (kms_sw_dt) {
kms_sw_dt-ref_count++;
+ kms_sw_dt-width = templ-width0;
+ kms_sw_dt-height = templ-height0;
+ if (kms_sw_dt-height)
+kms_sw_dt-stride = kms_sw_dt-size/kms_sw_dt-height;
+ *stride = kms_sw_dt-stride;
+ }
+ return (struct sw_displaytarget *)kms_sw_dt;
+ case DRM_API_HANDLE_TYPE_KMS:
+ LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
+ if (kms_sw_dt-handle == whandle-handle) {
+kms_sw_dt-ref_count++;
- DEBUG(KMS-DEBUG: imported buffer %u (size %u)\n, kms_sw_dt-handle,
kms_sw_dt-size);
+DEBUG(KMS-DEBUG: imported buffer %u (size %u)\n,
kms_sw_dt-handle, kms_sw_dt-size);
- *stride = kms_sw_dt-stride;
- return (struct sw_displaytarget *)kms_sw_dt;
+*stride = kms_sw_dt-stride;
+return (struct sw_displaytarget *)kms_sw_dt;
+ }
}
+ default:
+ break;
}
assert(0);
@@ -253,16 +303,26 @@ kms_sw_displaytarget_get_handle(struct sw_winsys *winsys,
struct sw_displaytarget *dt,
struct winsys_handle *whandle)
{
+ struct kms_sw_winsys *kms_sw = kms_sw_winsys(winsys);
struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
- if (whandle-type == DRM_API_HANDLE_TYPE_KMS) {
+ switch(whandle-type) {
+ case DRM_API_HANDLE_TYPE_KMS:
whandle-handle = kms_sw_dt-handle;
whandle-stride = kms_sw_dt-stride;
- } else {
+ return TRUE;
+ case DRM_API_HANDLE_TYPE_FD:
+ if (!drmPrimeHandleToFD(kms_sw-fd, kms_sw_dt-handle,
+ DRM_CLOEXEC, whandle-handle)) {
+ whandle-stride = kms_sw_dt-stride
[Mesa-dev] [PATCH] kma-swrast: PRIME support v2
Hi, This adds support for dma_bufs throught fds to kms_swrast. Andreas Pokorny (1): kms-swrast: Support Prime fd handling src/gallium/state_trackers/dri/dri2.c | 8 +++ src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 --- 2 files changed, 78 insertions(+), 10 deletions(-) -- 2.1.0.rc1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] kms-swrast: Support Prime fd handling
Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast screen.
Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com
---
src/gallium/state_trackers/dri/dri2.c | 8 +++
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 ---
2 files changed, 78 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index a63448d..82f8a47 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1333,6 +1333,7 @@ dri_kms_init_screen(__DRIscreen * sPriv)
const __DRIconfig **configs;
struct dri_screen *screen;
struct pipe_screen *pscreen = NULL;
+ uint64_t cap;
screen = CALLOC_STRUCT(dri_screen);
if (!screen)
@@ -1344,6 +1345,13 @@ dri_kms_init_screen(__DRIscreen * sPriv)
sPriv-driverPrivate = (void *)screen;
pscreen = kms_swrast_create_screen(screen-fd);
+
+ if (drmGetCap(sPriv-fd, DRM_CAP_PRIME, cap) == 0
+ (cap DRM_PRIME_CAP_IMPORT)) {
+ dri2ImageExtension.createImageFromFds = dri2_from_fds;
+ dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
+ }
+
sPriv-extensions = dri_screen_extensions;
/* dri_init_screen_helper checks pscreen for us */
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index c9934bb..ba0660c 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -38,6 +38,7 @@
#include sys/mman.h
#include unistd.h
#include dlfcn.h
+#include fcntl.h
#include xf86drm.h
#include pipe/p_compiler.h
@@ -210,6 +211,38 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
return kms_sw_dt-mapped;
}
+static struct kms_sw_displaytarget *
+kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd)
+{
+ uint32_t handle = -1;
+ struct kms_sw_displaytarget * kms_sw_dt;
+ int ret;
+
+ ret = drmPrimeFDToHandle(kms_sw-fd, fd, handle);
+
+ if (ret)
+ return NULL;
+
+ kms_sw_dt = CALLOC_STRUCT(kms_sw_displaytarget);
+ if (!kms_sw_dt)
+ return NULL;
+
+ kms_sw_dt-ref_count = 1;
+ kms_sw_dt-handle = handle;
+ kms_sw_dt-size = lseek(fd, 0, SEEK_END);
+
+ if (kms_sw_dt-size == (off_t)-1) {
+ FREE(kms_sw_dt);
+ return NULL;
+ }
+
+ lseek(fd, 0, SEEK_SET);
+
+ list_add(kms_sw_dt-link, kms_sw-bo_list);
+
+ return kms_sw_dt;
+}
+
static void
kms_sw_displaytarget_unmap(struct sw_winsys *ws,
struct sw_displaytarget *dt)
@@ -231,17 +264,34 @@ kms_sw_displaytarget_from_handle(struct sw_winsys *ws,
struct kms_sw_winsys *kms_sw = kms_sw_winsys(ws);
struct kms_sw_displaytarget *kms_sw_dt;
- assert(whandle-type == DRM_API_HANDLE_TYPE_KMS);
+ assert(whandle-type == DRM_API_HANDLE_TYPE_KMS ||
+ whandle-type == DRM_API_HANDLE_TYPE_FD);
- LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
- if (kms_sw_dt-handle == whandle-handle) {
+ switch(whandle-type) {
+ case DRM_API_HANDLE_TYPE_FD:
+ kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw, whandle-handle);
+ if (kms_sw_dt) {
kms_sw_dt-ref_count++;
+ kms_sw_dt-width = templ-width0;
+ kms_sw_dt-height = templ-height0;
+ kms_sw_dt-stride = whandle-stride;
+ if (stride)
+*stride = kms_sw_dt-stride;
+ }
+ return (struct sw_displaytarget *)kms_sw_dt;
+ case DRM_API_HANDLE_TYPE_KMS:
+ LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
+ if (kms_sw_dt-handle == whandle-handle) {
+kms_sw_dt-ref_count++;
- DEBUG(KMS-DEBUG: imported buffer %u (size %u)\n, kms_sw_dt-handle,
kms_sw_dt-size);
+DEBUG(KMS-DEBUG: imported buffer %u (size %u)\n,
kms_sw_dt-handle, kms_sw_dt-size);
- *stride = kms_sw_dt-stride;
- return (struct sw_displaytarget *)kms_sw_dt;
+*stride = kms_sw_dt-stride;
+return (struct sw_displaytarget *)kms_sw_dt;
+ }
}
+ default:
+ break;
}
assert(0);
@@ -253,16 +303,26 @@ kms_sw_displaytarget_get_handle(struct sw_winsys *winsys,
struct sw_displaytarget *dt,
struct winsys_handle *whandle)
{
+ struct kms_sw_winsys *kms_sw = kms_sw_winsys(winsys);
struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
- if (whandle-type == DRM_API_HANDLE_TYPE_KMS) {
+ switch(whandle-type) {
+ case DRM_API_HANDLE_TYPE_KMS:
whandle-handle = kms_sw_dt-handle;
whandle-stride = kms_sw_dt-stride;
- } else {
+ return TRUE;
+ case DRM_API_HANDLE_TYPE_FD:
+ if (!drmPrimeHandleToFD(kms_sw-fd, kms_sw_dt-handle,
+ DRM_CLOEXEC, whandle-handle)) {
+ whandle-stride = kms_sw_dt-stride;
+ return TRUE
[Mesa-dev] [PATCH] kms-swrast: Support Prime fd handling v3
Hi, This should be the final version. Not sure why I even messed with guessing the stride value. regards Andreas Pokorny Andreas Pokorny (1): kms-swrast: Support Prime fd handling src/gallium/state_trackers/dri/dri2.c | 8 +++ src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 --- 2 files changed, 78 insertions(+), 10 deletions(-) -- 2.1.0.rc1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] kms-swrast: PRIME and missing defines
Hi Thank you for the review! I will send an updated version asap. On Wed, Aug 20, 2014 at 4:50 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Do you have any rough numbers about the benefit this brings us ? I doubt that there is a big timing impact between sharing named drm handles and prime fds, but yeah right now neither is supported. And we need that for mir and wayland. I believe dma_bufs are the nicest way to share buffers across processes., so I added them first and made sure they work on qxl. I still wanted to do a test run with wayland on qxl, so far I only verified that mir works. Additionally I think that we could get rid of the 'can_share_buffers' logic here and there, since the generic flink - ioctl comes with gem and is hence supported by the interesting 'software'-drm drivers like udl. But right now I was hunting down some graphical artifacts in swrast. regards Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] kms-swrast: Support Prime fd handling
Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast screen.
Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com
---
src/gallium/state_trackers/dri/dri2.c | 8 ++
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 91 +++
2 files changed, 86 insertions(+), 13 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index c466de7..e52bd71 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1327,6 +1327,7 @@ dri_kms_init_screen(__DRIscreen * sPriv)
const __DRIconfig **configs;
struct dri_screen *screen;
struct pipe_screen *pscreen = NULL;
+ uint64_t cap;
screen = CALLOC_STRUCT(dri_screen);
if (!screen)
@@ -1338,6 +1339,13 @@ dri_kms_init_screen(__DRIscreen * sPriv)
sPriv-driverPrivate = (void *)screen;
pscreen = kms_swrast_create_screen(screen-fd);
+
+ if (drmGetCap(sPriv-fd, DRM_CAP_PRIME, cap) == 0
+ (cap DRM_PRIME_CAP_IMPORT)) {
+ dri2ImageExtension.createImageFromFds = dri2_from_fds;
+ dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
+ }
+
sPriv-extensions = dri_screen_extensions;
/* dri_init_screen_helper checks pscreen for us */
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index c9934bb..7246ffc 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -38,6 +38,7 @@
#include sys/mman.h
#include unistd.h
#include dlfcn.h
+#include fcntl.h
#include xf86drm.h
#include pipe/p_compiler.h
@@ -210,6 +211,38 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
return kms_sw_dt-mapped;
}
+static struct kms_sw_displaytarget *
+kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd)
+{
+ uint32_t handle;
+ struct kms_sw_displaytarget * kms_sw_dt;
+ int ret;
+
+ ret = drmPrimeFDToHandle(kms_sw-fd, fd, handle);
+
+ if (ret)
+ return NULL;
+
+ kms_sw_dt = CALLOC_STRUCT(kms_sw_displaytarget);
+ if (!kms_sw_dt)
+ return NULL;
+
+ kms_sw_dt-ref_count = 1;
+ kms_sw_dt-handle = handle;
+ kms_sw_dt-size = lseek(fd, 0, SEEK_END);
+
+ if (kms_sw_dt-size == (off_t)-1) {
+ FREE(kms_sw_dt);
+ return NULL;
+ }
+
+ lseek(fd, 0, SEEK_SET);
+
+ list_add(kms_sw_dt-link, kms_sw-bo_list);
+
+ return kms_sw_dt;
+}
+
static void
kms_sw_displaytarget_unmap(struct sw_winsys *ws,
struct sw_displaytarget *dt)
@@ -231,17 +264,38 @@ kms_sw_displaytarget_from_handle(struct sw_winsys *ws,
struct kms_sw_winsys *kms_sw = kms_sw_winsys(ws);
struct kms_sw_displaytarget *kms_sw_dt;
- assert(whandle-type == DRM_API_HANDLE_TYPE_KMS);
-
- LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
- if (kms_sw_dt-handle == whandle-handle) {
- kms_sw_dt-ref_count++;
-
- DEBUG(KMS-DEBUG: imported buffer %u (size %u)\n, kms_sw_dt-handle,
kms_sw_dt-size);
-
- *stride = kms_sw_dt-stride;
+ assert(whandle-type == DRM_API_HANDLE_TYPE_KMS ||
+ whandle-type == DRM_API_HANDLE_TYPE_FD);
+
+ switch(whandle-type) {
+ case DRM_API_HANDLE_TYPE_FD:
+ {
+ kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw,
whandle-handle);
+ if (kms_sw_dt) {
+kms_sw_dt-ref_count++;
+kms_sw_dt-width = templ-width0;
+kms_sw_dt-height = templ-height0;
+if (kms_sw_dt-height)
+ kms_sw_dt-stride = kms_sw_dt-size/kms_sw_dt-height;
+*stride = kms_sw_dt-stride;
+ }
return (struct sw_displaytarget *)kms_sw_dt;
}
+ case DRM_API_HANDLE_TYPE_KMS:
+ {
+ LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
+if (kms_sw_dt-handle == whandle-handle) {
+ kms_sw_dt-ref_count++;
+
+ DEBUG(KMS-DEBUG: imported buffer %u (size %u)\n,
kms_sw_dt-handle, kms_sw_dt-size);
+
+ *stride = kms_sw_dt-stride;
+ return (struct sw_displaytarget *)kms_sw_dt;
+}
+ }
+ }
+ default:
+ break;
}
assert(0);
@@ -253,16 +307,27 @@ kms_sw_displaytarget_get_handle(struct sw_winsys *winsys,
struct sw_displaytarget *dt,
struct winsys_handle *whandle)
{
+ struct kms_sw_winsys *kms_sw = kms_sw_winsys(winsys);
struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
- if (whandle-type == DRM_API_HANDLE_TYPE_KMS) {
+ switch(whandle-type) {
+ case DRM_API_HANDLE_TYPE_KMS:
whandle-handle = kms_sw_dt-handle;
whandle-stride = kms_sw_dt-stride;
- } else {
+ return TRUE;
+ case DRM_API_HANDLE_TYPE_FD:
+ if (drmPrimeHandleToFD(kms_sw-fd, kms_sw_dt-handle, DRM_CLOEXEC,
whandle-handle
[Mesa-dev] [PATCH 0/2] kms-swrast: PRIME and missing defines
Hi, This adds support for dma_buf fds to kms_swrast. This is especially interesting for drm capable drivers like qxl or udl. The former recently gained prime support. The second part adds a few defines that werent set anywhere else, but are necessary for dri_kms_init_screen to be not empty. regards Andreas Andreas Pokorny (2): kms-swrast: Support Prime fd handling kms-swrast: defines missing to build kms-swrast src/gallium/state_trackers/dri/Makefile.am| 5 ++ src/gallium/state_trackers/dri/dri2.c | 8 ++ src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 91 +++ 3 files changed, 91 insertions(+), 13 deletions(-) -- 2.1.0.rc1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] kms-swrast: defines missing to build kms-swrast
--- src/gallium/state_trackers/dri/Makefile.am | 5 + 1 file changed, 5 insertions(+) diff --git a/src/gallium/state_trackers/dri/Makefile.am b/src/gallium/state_trackers/dri/Makefile.am index bda75c3..bcbd081 100644 --- a/src/gallium/state_trackers/dri/Makefile.am +++ b/src/gallium/state_trackers/dri/Makefile.am @@ -26,6 +26,7 @@ include $(top_srcdir)/src/gallium/Automake.inc AM_CPPFLAGS = \ $(GALLIUM_PIPE_LOADER_DEFINES) \ + -DDRI_TARGET \ -DPIPE_SEARCH_DIR=\$(libdir)/gallium-pipe\ \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src/mapi \ @@ -37,6 +38,10 @@ AM_CPPFLAGS = \ $(LIBDRM_CFLAGS) \ $(VISIBILITY_CFLAGS) +if HAVE_GALLIUM_SOFTPIPE +AM_CPPFLAGS += \ + -DGALLIUM_SOFTPIPE +endif if HAVE_GALLIUM_STATIC_TARGETS AM_CPPFLAGS += \ -DGALLIUM_STATIC_TARGETS=1 -- 2.1.0.rc1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 2/3] Add a dumb drm/kms winsys for software rendering
Hi, Nice patches! I found one minor issue below. I currently try to integrate and use that locally within kvm, currently on top of 10.2. 2014-06-15 13:49 GMT+02:00 Giovanni Campagna scampa.giova...@gmail.com: From: Giovanni Campagna gcampa...@src.gnome.org Add a new winsys and target that can be used with a dri2 state tracker and [..] diff --git a/configure.ac b/configure.ac index 390adaa..07e4648 100644 --- a/configure.ac +++ b/configure.ac @@ -1993,6 +1993,9 @@ if test -n $with_gallium_drivers; then if test x$enable_dri = xyes; then GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS dri-swrast fi +if text x$have_libdrm = xyes; then +GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS dri-kms-swrast +fi ;; s/text/test here ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/3] Add support for swrast to the DRM EGL platform
Hi,
Still trying the patch. Meanwhile I found two more things here:
2014-06-15 13:49 GMT+02:00 Giovanni Campagna scampa.giova...@gmail.com:
From: Giovanni Campagna gcampa...@src.gnome.org
[..]
static int
+dri_screen_create_swrast(struct gbm_dri_device *dri)
+{
+ int ret = 0;
+
+ dri-base.driver_name = swrast;
+
+ ret = dri_load_driver(dri);
The driver_name is later freed with free, so to avoid abort strdup should
be necessary.
+ if (ret) {
+ fprintf(stderr, failed to load swrast driver\n);
+ return ret;
+ }
+
+ dri-extensions = gbm_dri_screen_extensions;
+
+ if (dri-swrast == NULL)
+ return -1;
+
+ if (dri-swrast-base.version = 4) {
+ dri-screen = dri-swrast-createNewScreen2(0, dri-extensions,
+ dri-driver_extensions,
+ dri-driver_configs,
dri);
+ } else {
+ dri-screen = dri-swrast-createNewScreen(0, dri-extensions,
+ dri-driver_configs,
dri);
+ }
Is there any reason for not binding the gbm_dri_core_extensions here?
If there isnt I think you could easily combine that function with
dri_screen_create_dri2.
+
+ dri-lookup_image = NULL;
+ dri-lookup_user_data = NULL;
+
+ return 0;
+}
[...]
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/3] Add support for swrast to the DRM EGL platform
2014-07-02 18:48 GMT+02:00 Emil Velikov emil.l.veli...@gmail.com:
On 02/07/14 13:11, Andreas Pokorny wrote:
Hi,
Still trying the patch. Meanwhile I found two more things here:
[...]
The driver_name is later freed with free, so to avoid abort strdup should
be necessary.
The free snuck in shortly before Giovanni sent out the last revision. It
is on
my todo list, as I rebase the patches next week.
Good. There was another case with kms_swrast in the other patch.
+ if (ret) {
+ fprintf(stderr, failed to load swrast driver\n);
+ return ret;
+ }
+
+ dri-extensions = gbm_dri_screen_extensions;
+
+ if (dri-swrast == NULL)
+ return -1;
+
+ if (dri-swrast-base.version = 4) {
+ dri-screen = dri-swrast-createNewScreen2(0, dri-extensions,
+
dri-driver_extensions,
+ dri-driver_configs,
dri);
+ } else {
+ dri-screen = dri-swrast-createNewScreen(0, dri-extensions,
+ dri-driver_configs,
dri);
+ }
Is there any reason for not binding the gbm_dri_core_extensions here?
If there isnt I think you could easily combine that function with
dri_screen_create_dri2.
gbm_dri_core_extensions seems to be missing in here. If you're thinking
about
gbm_dri_device_extensions, then things go a bit different. Those extensions
are present for hw backed drivers only, thus it would make little sense to
try
and bind them in here.
A minor split in dri_load_driver() to handle only the required one will
come
with the rebase.
I think am mostly interested in __DRI_IMAGE extension. This part of the
code is still confusing for me.
regards
Andreas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vega: fix for object handle leak
Hello, I have been chasing a leak with OpenVG mesa-8.0.5. Massif gave me the following stack: -09.66% (3,471,568B) 0xB706B80: util_hash_table_set (u_hash_table.c:163) | -09.66% (3,471,568B) 0xB4E106F: create_handle (handle.c:83) | -09.66% (3,471,568B) 0xB527B7D: vg_init_object (vg_context.c:186) | -06.56% (2,358,352B) 0xB4E3599: paint_create (paint.c:201) | | -06.56% (2,358,320B) 0xB4DAF4F: vegaCreatePaint (api_paint.c:37) Within the first snapshots this stack only occupies a small portion of the memory below the thresholds. This portion grows to 9% after 100 seconds of slow mode rendering.The application that creates the paints, frees them right after use.. I only discovered the issue with paints, since all other handles (paths, images..) are kept alive and are reused for the next frame. With the patch applied the leak is gone, and the memory usage stays constant. The patch is against MesaLib-9.0.1 since I could not clone from annongit.freedesktop.org. Andreas Pokorny (1): vega: fix for object handle leak src/gallium/state_trackers/vega/mask.c |1 + src/gallium/state_trackers/vega/paint.c |4 +++- src/gallium/state_trackers/vega/path.c |2 ++ src/gallium/state_trackers/vega/text.c |2 ++ 4 files changed, 8 insertions(+), 1 deletion(-) -- 1.7.10.4 0001-vega-fix-for-object-handle-leak.patch Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Debugging crashes in llvm
Hi, I recently stumbled over regular crashes with llvmpipe on llvm-2.9 in windows: 0261908D mov ebx,dword ptr [esp+33Ch] 02619094 lea ebx,[ebx+3] 02619097 imulebx,edx 0261909A add ebx,ecx 0261909C insertpsxmm0,dword ptr [esi+ebx],30h -- 026190A3 mov ecx,dword ptr [ebp+8] 026190A6 mov edx,dword ptr [ecx] 026190A8 movss xmm2,dword ptr [edx+100h] libEGL.dll!llvm_pipeline_generic(draw_pt_middle_end * middle=0x, const draw_fetch_info * fetch_info=0x0006e828, const draw_prim_info * prim_info=0x0006e838) Line 262 + 0x12 bytes C libEGL.dll!llvm_middle_end_linear_run(draw_pt_middle_end * middle=, unsigned int start=, unsigned int count=, unsigned int prim_flags=) Line 364 + 0x13 bytes C libEGL.dll!vsplit_run_linear(draw_pt_front_end * frontend=0x03ff, unsigned int start=0, unsigned int count=150) Line 61 + 0x11 bytesC libEGL.dll!draw_pt_arrays(draw_context * draw=0x, unsigned int prim=4, unsigned int start=0, unsigned int count=3) Line 115 C libEGL.dll!draw_vbo(draw_context * draw=0x, const pipe_draw_info * info=0x) Line 491 + 0x13 bytesC libEGL.dll!llvmpipe_draw_vbo(pipe_context * pipe=0x021dc790, const pipe_draw_info * info=0x0006e918) Line 86 C libEGL.dll!st_draw_vbo(gl_context * ctx=0x025a14b0, const gl_client_array * * arrays=0x02661810, const _mesa_prim * prims=0x0006e97c, unsigned int nr_prims=1, const _mesa_index_buffer * ib=0x, unsigned char index_bounds_valid='', unsigned int min_index=0, unsigned int max_index=149) Line 750 + 0xf bytes C libEGL.dll!vbo_draw_arrays(gl_context * ctx=0x, unsigned int mode=4, int start=0, int count=150, unsigned int numInstances=1) Line 645 + 0x28 bytesC libEGL.dll!vbo_exec_DrawArrays(unsigned int mode=4, int start=0, int count=150) Line 675 + 0x11 bytes C [...] What Information can I gather to find the cause for the crash? Regards Andreas Pokorny ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Name mangling in win32 build of EGL and GLESv2
Hi, Looking at the Symbol table of a recent (66b66295d0bc856c69fd22575580c7ecee16 ) libEGL.dll. I get the following mangled names: eglBindAPI _eglBindContext _eglBindTexImage eglBindTexImage _eglBindWaylandDisplayWL@8 _eglCheckResource eglChooseConfig That is stdcall and cdecl calling convention mixed? and in libGLESv2.dll all functions are with stdcall conventions _glActiveTexture@4 _glAttachShader@8 _glBindAttribLocation@12 _glBindBuffer@8 _glBindFramebuffer@8 Then in libOpenVL.dll there is no mangling at all: vgSetf vgSetfv vgSeti vgSetiv vgShear vgTransformPath Is this happening by accident or on purspose? regards Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
Hi, 2011/2/15 Zack Rusin za...@vmware.com: [...] replace everything we have right now. the fact that piglit and our demos already use it make it even easier. the build system to rule them all. unfortunately Jose tried it and the issue was that cmake doesn't support convinenice libraries which mesa uses quite extensively and there was no decent way of making it work without recompiling the same file number of times (not a workable solution from a development point of view). so as it stands scons is the official way of building on windows. CMake devs regularly claim that they do not support convenience libraries. From my point of view cmake supports the most important feature of convenience libraries through static libraries. That is dependency tracking. We use that feature extensively, and so far it has not failed for us in the last two years. But I am not 100% sure what libtool does additionally to dependency tracking. regards Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
