* drm/exynos: add async G2D execution to libdrm
@ 2015-03-20 22:25 Tobias Jakobi
2015-03-20 22:25 ` [PATCH 1/5] tests/exynos: add fimg2d performance analysis Tobias Jakobi
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: Tobias Jakobi @ 2015-03-20 22:25 UTC (permalink / raw)
To: linux-samsung-soc
Cc: dri-devel, emil.l.velikov, jy0922.shim, m.szyprowski, inki.dae
Hello,
this series exposes async execution of G2D command buffers to userspace. Also includes is a small performance analysis test, which can also be used to
stress test the engine. The async operation is of course also tested.
Please review and let me know what I can improve.
With best wishes,
Tobias
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH 1/5] tests/exynos: add fimg2d performance analysis 2015-03-20 22:25 drm/exynos: add async G2D execution to libdrm Tobias Jakobi @ 2015-03-20 22:25 ` Tobias Jakobi 2015-03-22 15:36 ` Emil Velikov 2015-03-20 22:25 ` [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent Tobias Jakobi ` (2 subsequent siblings) 3 siblings, 1 reply; 17+ messages in thread From: Tobias Jakobi @ 2015-03-20 22:25 UTC (permalink / raw) To: linux-samsung-soc; +Cc: emil.l.velikov, dri-devel, Tobias Jakobi, m.szyprowski Currently only fast solid color clear performance is measured. A large buffer is allocated and solid color clear operations are executed on it with randomly chosen properties (position and size of the region, clear color). Execution time is measured and output together with the amount of pixels processed. The 'simple' variant only executes one G2D command buffer at a time, while the 'multi' variant executes multiple ones. This can be used to measure setup/exec overhead. The test also serves a stability check. If clocks/voltages are too high or low respectively, the test quickly reveals this. Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> --- tests/exynos/Makefile.am | 8 +- tests/exynos/exynos_fimg2d_perf.c | 245 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 252 insertions(+), 1 deletion(-) create mode 100644 tests/exynos/exynos_fimg2d_perf.c diff --git a/tests/exynos/Makefile.am b/tests/exynos/Makefile.am index b21d016..243f957 100644 --- a/tests/exynos/Makefile.am +++ b/tests/exynos/Makefile.am @@ -5,9 +5,11 @@ AM_CFLAGS = \ -I $(top_srcdir)/exynos \ -I $(top_srcdir) +bin_PROGRAMS = exynos_fimg2d_perf + if HAVE_LIBKMS if HAVE_INSTALL_TESTS -bin_PROGRAMS = \ +bin_PROGRAMS += \ exynos_fimg2d_test else noinst_PROGRAMS = \ @@ -15,6 +17,10 @@ noinst_PROGRAMS = \ endif endif +exynos_fimg2d_perf_LDADD = \ + $(top_builddir)/libdrm.la \ + $(top_builddir)/exynos/libdrm_exynos.la + exynos_fimg2d_test_LDADD = \ $(top_builddir)/libdrm.la \ $(top_builddir)/libkms/libkms.la \ diff --git a/tests/exynos/exynos_fimg2d_perf.c b/tests/exynos/exynos_fimg2d_perf.c new file mode 100644 index 0000000..f45cacc --- /dev/null +++ b/tests/exynos/exynos_fimg2d_perf.c @@ -0,0 +1,245 @@ +#include <stdlib.h> +#include <stdio.h> +#include <time.h> + +#include <xf86drm.h> + +#include "exynos_drm.h" +#include "exynos_drmif.h" +#include "exynos_fimg2d.h" + +/* Enable to format the output so that it can be fed into Mathematica. */ +#define OUTPUT_MATHEMATICA 0 + +static int fimg2d_perf_simple(struct exynos_bo *bo, struct g2d_context *ctx, + unsigned buf_width, unsigned buf_height, unsigned iterations) +{ + struct timespec tspec = { 0 }; + struct g2d_image img = { 0 }; + + unsigned long long g2d_time; + unsigned i; + int ret = 0; + + img.width = buf_width; + img.height = buf_height; + img.stride = buf_width * 4; + img.color_mode = G2D_COLOR_FMT_ARGB8888 | G2D_ORDER_AXRGB; + img.buf_type = G2D_IMGBUF_GEM; + img.bo[0] = bo->handle; + + srand(time(NULL)); + + printf("starting simple G2D performance test\n"); + printf("buffer width = %u, buffer height = %u, iterations = %u\n", + buf_width, buf_height, iterations); + +#if (OUTPUT_MATHEMATICA == 1) + putchar('{'); +#endif + + for (i = 0; i < iterations; ++i) { + unsigned x, y, w, h; + + x = rand() % buf_width; + y = rand() % buf_height; + + if (x == (buf_width - 1)) + x -= 1; + if (y == (buf_height - 1)) + y -= 1; + + w = rand() % (buf_width - x); + h = rand() % (buf_height - y); + + if (w == 0) w = 1; + if (h == 0) h = 1; + + img.color = rand(); + + ret = g2d_solid_fill(ctx, &img, x, y, w, h); + + clock_gettime(CLOCK_MONOTONIC, &tspec); + + if (ret == 0) + ret = g2d_exec(ctx); + + if (ret != 0) { + fprintf(stderr, "error: iteration %u failed (x = %u, y = %u, w = %u, h = %u)\n", + i, x, y, w, h); + break; + } else { + struct timespec end = { 0 }; + clock_gettime(CLOCK_MONOTONIC, &end); + + g2d_time = (end.tv_sec - tspec.tv_sec) * 1000000000ULL; + g2d_time += (end.tv_nsec - tspec.tv_nsec); + +#if (OUTPUT_MATHEMATICA == 1) + if (i != 0) putchar(','); + printf("{%u,%llu}", w * h, g2d_time); +#else + printf("num_pixels = %u, usecs = %llu\n", w * h, g2d_time); +#endif + } + } + +#if (OUTPUT_MATHEMATICA == 1) + printf("}\n"); +#endif + + return ret; +} + +static int fimg2d_perf_multi(struct exynos_bo *bo, struct g2d_context *ctx, + unsigned buf_width, unsigned buf_height, unsigned iterations, unsigned batch) +{ + struct timespec tspec = { 0 }; + struct g2d_image *images; + + unsigned long long g2d_time; + unsigned i, j; + int ret = 0; + + images = calloc(batch, sizeof(struct g2d_image)); + for (i = 0; i < batch; ++i) { + images[i].width = buf_width; + images[i].height = buf_height; + images[i].stride = buf_width * 4; + images[i].color_mode = G2D_COLOR_FMT_ARGB8888 | G2D_ORDER_AXRGB; + images[i].buf_type = G2D_IMGBUF_GEM; + images[i].bo[0] = bo->handle; + } + + srand(time(NULL)); + + printf("starting multi G2D performance test (batch size = %u)\n", batch); + printf("buffer width = %u, buffer height = %u, iterations = %u\n", + buf_width, buf_height, iterations); + +#if (OUTPUT_MATHEMATICA == 1) + putchar('{'); +#endif + + for (i = 0; i < iterations; ++i) { + unsigned num_pixels = 0; + + for (j = 0; j < batch; ++j) { + unsigned x, y, w, h; + + x = rand() % buf_width; + y = rand() % buf_height; + + if (x == (buf_width - 1)) + x -= 1; + if (y == (buf_height - 1)) + y -= 1; + + w = rand() % (buf_width - x); + h = rand() % (buf_height - y); + + if (w == 0) w = 1; + if (h == 0) h = 1; + + images[j].color = rand(); + + num_pixels += w * h; + + ret = g2d_solid_fill(ctx, &images[j], x, y, w, h); + if (ret != 0) + break; + } + + clock_gettime(CLOCK_MONOTONIC, &tspec); + + if (ret == 0) + ret = g2d_exec(ctx); + + if (ret != 0) { + fprintf(stderr, "error: iteration %u failed (num_pixels = %u)\n", i, num_pixels); + break; + break; + } else { + struct timespec end = { 0 }; + clock_gettime(CLOCK_MONOTONIC, &end); + + g2d_time = (end.tv_sec - tspec.tv_sec) * 1000000000ULL; + g2d_time += (end.tv_nsec - tspec.tv_nsec); + +#if (OUTPUT_MATHEMATICA == 1) + if (i != 0) putchar(','); + printf("{%u,%llu}", num_pixels, g2d_time); +#else + printf("num_pixels = %u, usecs = %llu\n", num_pixels, g2d_time); +#endif + } + } + +#if (OUTPUT_MATHEMATICA == 1) + printf("}\n"); +#endif + + return ret; +} + +int main(int argc, char **argv) +{ + int fd, ret; + + struct exynos_device *dev; + struct g2d_context *ctx; + struct exynos_bo *bo; + + ret = 0; + + fd = drmOpen("exynos", NULL); + if (fd < 0) { + fprintf(stderr, "error: failed to open drm\n"); + ret = -1; + + goto out; + } + + dev = exynos_device_create(fd); + if (dev == NULL) { + fprintf(stderr, "error: failed to create device\n"); + ret = -2; + + goto fail; + } + + ctx = g2d_init(fd); + if (ctx == NULL) { + fprintf(stderr, "error: failed to init G2D\n"); + ret = -3; + + goto g2d_fail; + } + + bo = exynos_bo_create(dev, 4096 * 4096 * 4, 0); + if (bo == NULL) { + fprintf(stderr, "error: failed to create bo\n"); + ret = -4; + + goto bo_fail; + } + + ret = fimg2d_perf_simple(bo, ctx, 4096, 4096, 128); + + if (ret == 0) + ret = fimg2d_perf_multi(bo, ctx, 4096, 4096, 128, 3); + + exynos_bo_destroy(bo); + +bo_fail: + g2d_fini(ctx); + +g2d_fail: + exynos_device_destroy(dev); + +fail: + drmClose(fd); + +out: + return ret; +} -- 2.0.5 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 1/5] tests/exynos: add fimg2d performance analysis 2015-03-20 22:25 ` [PATCH 1/5] tests/exynos: add fimg2d performance analysis Tobias Jakobi @ 2015-03-22 15:36 ` Emil Velikov 2015-03-22 16:35 ` Tobias Jakobi 0 siblings, 1 reply; 17+ messages in thread From: Emil Velikov @ 2015-03-22 15:36 UTC (permalink / raw) To: Tobias Jakobi, linux-samsung-soc; +Cc: emil.l.velikov, dri-devel, m.szyprowski On 20/03/15 22:25, Tobias Jakobi wrote: > Currently only fast solid color clear performance is measured. > A large buffer is allocated and solid color clear operations > are executed on it with randomly chosen properties (position > and size of the region, clear color). Execution time is > measured and output together with the amount of pixels > processed. > > The 'simple' variant only executes one G2D command buffer at > a time, while the 'multi' variant executes multiple ones. This > can be used to measure setup/exec overhead. > > The test also serves a stability check. If clocks/voltages are > too high or low respectively, the test quickly reveals this. > > Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Hi Tobias, As most of this series is quite Exynos specific I will cover the misc bits, and leave the core part to someone familiar with the hardware. > --- > tests/exynos/Makefile.am | 8 +- > tests/exynos/exynos_fimg2d_perf.c | 245 ++++++++++++++++++++++++++++++++++++++ > 2 files changed, 252 insertions(+), 1 deletion(-) > create mode 100644 tests/exynos/exynos_fimg2d_perf.c > > diff --git a/tests/exynos/Makefile.am b/tests/exynos/Makefile.am > index b21d016..243f957 100644 > --- a/tests/exynos/Makefile.am > +++ b/tests/exynos/Makefile.am > @@ -5,9 +5,11 @@ AM_CFLAGS = \ > -I $(top_srcdir)/exynos \ > -I $(top_srcdir) > > +bin_PROGRAMS = exynos_fimg2d_perf > + Might I suggest that we treat this (and your follow up utility) as a test ? I.e. use if HAVE_INSTALL_TESTS bin_PROGRAMS = \ exynos_fimg2d_perf else noinst_PROGRAMS = \ exynos_fimg2d_perf endif and amend the block below appropriately ? > if HAVE_LIBKMS > if HAVE_INSTALL_TESTS > -bin_PROGRAMS = \ > +bin_PROGRAMS += \ > exynos_fimg2d_test > else > noinst_PROGRAMS = \ > @@ -15,6 +17,10 @@ noinst_PROGRAMS = \ > endif > endif > > +exynos_fimg2d_perf_LDADD = \ > + $(top_builddir)/libdrm.la \ > + $(top_builddir)/exynos/libdrm_exynos.la > + > exynos_fimg2d_test_LDADD = \ > $(top_builddir)/libdrm.la \ > $(top_builddir)/libkms/libkms.la \ > diff --git a/tests/exynos/exynos_fimg2d_perf.c b/tests/exynos/exynos_fimg2d_perf.c > new file mode 100644 > index 0000000..f45cacc > --- /dev/null > +++ b/tests/exynos/exynos_fimg2d_perf.c > @@ -0,0 +1,245 @@ Can you add a licence to this file. Would be nice if it's covered by X/MIT so that *BSD folk and others can use your tool. > +#include <stdlib.h> > +#include <stdio.h> > +#include <time.h> > + > +#include <xf86drm.h> > + > +#include "exynos_drm.h" > +#include "exynos_drmif.h" > +#include "exynos_fimg2d.h" > + > +/* Enable to format the output so that it can be fed into Mathematica. */ > +#define OUTPUT_MATHEMATICA 0 > + > +static int fimg2d_perf_simple(struct exynos_bo *bo, struct g2d_context *ctx, > + unsigned buf_width, unsigned buf_height, unsigned iterations) > +{ > + struct timespec tspec = { 0 }; > + struct g2d_image img = { 0 }; > + > + unsigned long long g2d_time; > + unsigned i; > + int ret = 0; > + > + img.width = buf_width; > + img.height = buf_height; > + img.stride = buf_width * 4; > + img.color_mode = G2D_COLOR_FMT_ARGB8888 | G2D_ORDER_AXRGB; > + img.buf_type = G2D_IMGBUF_GEM; > + img.bo[0] = bo->handle; > + > + srand(time(NULL)); > + > + printf("starting simple G2D performance test\n"); > + printf("buffer width = %u, buffer height = %u, iterations = %u\n", > + buf_width, buf_height, iterations); > + > +#if (OUTPUT_MATHEMATICA == 1) > + putchar('{'); > +#endif > + I'm suspecting that having this as a runtime option will be better. Something like ./exynos_fimg2d_perf --output mathematica ? As a general note I would recommend keeping statements on separate lines (none of if (foo) far()) as it makes debugging easier. Although all of the above are my take on things, so checks with the Exynos crew if they feel otherwise :-) Cheers, Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/5] tests/exynos: add fimg2d performance analysis 2015-03-22 15:36 ` Emil Velikov @ 2015-03-22 16:35 ` Tobias Jakobi 2015-03-25 18:27 ` Tobias Jakobi 0 siblings, 1 reply; 17+ messages in thread From: Tobias Jakobi @ 2015-03-22 16:35 UTC (permalink / raw) To: Emil Velikov, Tobias Jakobi, linux-samsung-soc; +Cc: dri-devel, m.szyprowski Hello Emil, Emil Velikov wrote: > Might I suggest that we treat this (and your follow up utility) as a > test ? I.e. use > > if HAVE_INSTALL_TESTS > bin_PROGRAMS = \ > exynos_fimg2d_perf > else > noinst_PROGRAMS = \ > exynos_fimg2d_perf > endif > > and amend the block below appropriately ? sure, honestly I don't even remember why I didn't add these as tests? *confused* > Can you add a licence to this file. Would be nice if it's covered by > X/MIT so that *BSD folk and others can use your tool. Will do! Even though I probably won't go with a MIT license. > I'm suspecting that having this as a runtime option will be better. > Something like ./exynos_fimg2d_perf --output mathematica ? Well, I was thinking about removing the Mathematica specific code for the submission, but I then left it in. I use Mathematica for parts of my thesis, so it's usually my preferred tool to visualize data. I guess a more 'open-source' friendly solution here would be to provide GnuPlot output, but I guess I leave that to another use :) > As a general note I would recommend keeping statements on separate lines > (none of if (foo) far()) as it makes debugging easier. OK, changing this. With best wishes, Tobias _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/5] tests/exynos: add fimg2d performance analysis 2015-03-22 16:35 ` Tobias Jakobi @ 2015-03-25 18:27 ` Tobias Jakobi 2015-03-26 15:16 ` Emil Velikov 0 siblings, 1 reply; 17+ messages in thread From: Tobias Jakobi @ 2015-03-25 18:27 UTC (permalink / raw) To: Tobias Jakobi, Emil Velikov, linux-samsung-soc Cc: dri-devel, jy0922.shim, m.szyprowski, inki.dae Hello, the new version should fix most of the mentioned issues. Tobias Jakobi wrote: >> As a general note I would recommend keeping statements on separate lines >> (none of if (foo) far()) as it makes debugging easier. > OK, changing this. Except for this, I didn't change it since I don't see the point. In fact I think that splitting the few occurrences makes the code less readable. I haven't worked with getopt before, so I gave it a try and made all these hardcoded parameters configurable. With best wishes, Tobias ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/5] tests/exynos: add fimg2d performance analysis 2015-03-25 18:27 ` Tobias Jakobi @ 2015-03-26 15:16 ` Emil Velikov 0 siblings, 0 replies; 17+ messages in thread From: Emil Velikov @ 2015-03-26 15:16 UTC (permalink / raw) To: Tobias Jakobi, Tobias Jakobi, linux-samsung-soc Cc: emil.l.velikov, dri-devel, m.szyprowski On 25/03/15 18:27, Tobias Jakobi wrote: > Hello, > > the new version should fix most of the mentioned issues. > > Tobias Jakobi wrote: >>> As a general note I would recommend keeping statements on separate lines >>> (none of if (foo) far()) as it makes debugging easier. >> OK, changing this. > Except for this, I didn't change it since I don't see the point. In fact > I think that splitting the few occurrences makes the code less readable. > Beauty is in the eye of the beholder. > I haven't worked with getopt before, so I gave it a try and made all > these hardcoded parameters configurable. > Nice :-) Cheers, Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent 2015-03-20 22:25 drm/exynos: add async G2D execution to libdrm Tobias Jakobi 2015-03-20 22:25 ` [PATCH 1/5] tests/exynos: add fimg2d performance analysis Tobias Jakobi @ 2015-03-20 22:25 ` Tobias Jakobi 2015-03-22 15:41 ` Emil Velikov 2015-03-30 0:02 ` Rob Clark 2015-03-20 22:25 ` [PATCH 3/5] exynos/fimg2d: add g2d_config_event Tobias Jakobi 2015-03-21 14:03 ` drm/exynos: add async G2D execution to libdrm Tobias Jakobi 3 siblings, 2 replies; 17+ messages in thread From: Tobias Jakobi @ 2015-03-20 22:25 UTC (permalink / raw) To: linux-samsung-soc Cc: dri-devel, emil.l.velikov, jy0922.shim, m.szyprowski, inki.dae, Tobias Jakobi This event is specific to Exynos G2D DRM driver. Only process it when Exynos support is enabled. Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> --- exynos/exynos_drm.h | 12 ++++++++++++ xf86drm.h | 7 ++++++- xf86drmMode.c | 18 ++++++++++++++++++ 3 files changed, 36 insertions(+), 1 deletion(-) diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h index 256c02f..c3af0ac 100644 --- a/exynos/exynos_drm.h +++ b/exynos/exynos_drm.h @@ -157,4 +157,16 @@ struct drm_exynos_g2d_exec { #define DRM_IOCTL_EXYNOS_G2D_EXEC DRM_IOWR(DRM_COMMAND_BASE + \ DRM_EXYNOS_G2D_EXEC, struct drm_exynos_g2d_exec) +/* EXYNOS specific events */ +#define DRM_EXYNOS_G2D_EVENT 0x80000000 + +struct drm_exynos_g2d_event { + struct drm_event base; + __u64 user_data; + __u32 tv_sec; + __u32 tv_usec; + __u32 cmdlist_no; + __u32 reserved; +}; + #endif diff --git a/xf86drm.h b/xf86drm.h index 40c55c9..6b1c9b4 100644 --- a/xf86drm.h +++ b/xf86drm.h @@ -719,7 +719,7 @@ extern void drmMsg(const char *format, ...) DRM_PRINTFLIKE(1, 2); extern int drmSetMaster(int fd); extern int drmDropMaster(int fd); -#define DRM_EVENT_CONTEXT_VERSION 2 +#define DRM_EVENT_CONTEXT_VERSION 3 typedef struct _drmEventContext { @@ -739,6 +739,11 @@ typedef struct _drmEventContext { unsigned int tv_usec, void *user_data); + void (*g2d_event_handler)(int fd, + unsigned int cmdlist_no, + unsigned int tv_sec, + unsigned int tv_usec, + void *user_data); } drmEventContext, *drmEventContextPtr; extern int drmHandleEvent(int fd, drmEventContextPtr evctx); diff --git a/xf86drmMode.c b/xf86drmMode.c index 61d5e01..d9f2898 100644 --- a/xf86drmMode.c +++ b/xf86drmMode.c @@ -53,6 +53,10 @@ #include <unistd.h> #include <errno.h> +#ifdef HAVE_EXYNOS +#include <exynos/exynos_drm.h> +#endif + #ifdef HAVE_VALGRIND #include <valgrind.h> #include <memcheck.h> @@ -846,6 +850,7 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx) int len, i; struct drm_event *e; struct drm_event_vblank *vblank; + struct drm_exynos_g2d_event *g2d; /* The DRM read semantics guarantees that we always get only * complete events. */ @@ -882,6 +887,19 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx) vblank->tv_usec, U642VOID (vblank->user_data)); break; +#ifdef HAVE_EXYNOS + case DRM_EXYNOS_G2D_EVENT: + if (evctx->version < 3 || + evctx->g2d_event_handler == NULL) + break; + g2d = (struct drm_exynos_g2d_event *) e; + evctx->g2d_event_handler(fd, + g2d->cmdlist_no, + g2d->tv_sec, + g2d->tv_usec, + U642VOID (g2d->user_data)); + break; +#endif default: break; } -- 2.0.5 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent 2015-03-20 22:25 ` [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent Tobias Jakobi @ 2015-03-22 15:41 ` Emil Velikov 2015-03-22 16:29 ` Tobias Jakobi 2015-03-30 0:02 ` Rob Clark 1 sibling, 1 reply; 17+ messages in thread From: Emil Velikov @ 2015-03-22 15:41 UTC (permalink / raw) To: Tobias Jakobi, linux-samsung-soc; +Cc: emil.l.velikov, dri-devel, m.szyprowski On 20/03/15 22:25, Tobias Jakobi wrote: > This event is specific to Exynos G2D DRM driver. Only > process it when Exynos support is enabled. > > Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> > --- > exynos/exynos_drm.h | 12 ++++++++++++ > xf86drm.h | 7 ++++++- > xf86drmMode.c | 18 ++++++++++++++++++ > 3 files changed, 36 insertions(+), 1 deletion(-) > I fear we are not (yet) allowed to do either of these changes. The exynos/exynos_drm.h header is (supposed to) be in sync/come from the kernel. And changes here are to be reflected only when the corresponding patch lands in drm-next (as per RELEASING). Wrt extending the current drmEventContext, I'm not sure that adding device specific changes to it are allowed. Wish I would give you some better news but... I cannot sorry :-\ -Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent 2015-03-22 15:41 ` Emil Velikov @ 2015-03-22 16:29 ` Tobias Jakobi 2015-03-23 11:03 ` Emil Velikov 0 siblings, 1 reply; 17+ messages in thread From: Tobias Jakobi @ 2015-03-22 16:29 UTC (permalink / raw) To: Emil Velikov, Tobias Jakobi, linux-samsung-soc; +Cc: dri-devel, m.szyprowski Hello Emil, Emil Velikov wrote: > I fear we are not (yet) allowed to do either of these changes. > > The exynos/exynos_drm.h header is (supposed to) be in sync/come from the > kernel. And changes here are to be reflected only when the corresponding > patch lands in drm-next (as per RELEASING). the point here is, that the current header in libdrm in _not_ in sync with the one in the kernel. It's hopelessly outdated, but mainly because exynos/libdrm doesn't use any new functionality provided by some update. Here's the current kernel header: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/uapi/drm/exynos_drm.h The event stuff has been there since 2012: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/include/drm/exynos_drm.h?id=d7f1642c90ab5eb2d7c48af0581c993094f97e1a The only reason why I haven't added the IPP things, is because I don't intend to work on this for the moment. > Wrt extending the current drmEventContext, I'm not sure that adding > device specific changes to it are allowed. Why shouldn't it? Isn't drmHandleEvent supposed to handle all kinds of DRM events that the kernel produces? With best wishes, Tobias _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent 2015-03-22 16:29 ` Tobias Jakobi @ 2015-03-23 11:03 ` Emil Velikov 0 siblings, 0 replies; 17+ messages in thread From: Emil Velikov @ 2015-03-23 11:03 UTC (permalink / raw) To: Tobias Jakobi, Tobias Jakobi, linux-samsung-soc Cc: emil.l.velikov, dri-devel, m.szyprowski Hi Tobias, On 22/03/15 16:29, Tobias Jakobi wrote: > Hello Emil, > Emil Velikov wrote: >> I fear we are not (yet) allowed to do either of these changes. >> >> The exynos/exynos_drm.h header is (supposed to) be in sync/come from the >> kernel. And changes here are to be reflected only when the corresponding >> patch lands in drm-next (as per RELEASING). > the point here is, that the current header in libdrm in _not_ in sync > with the one in the kernel. It's hopelessly outdated, but mainly because > exynos/libdrm doesn't use any new functionality provided by some update. > > Here's the current kernel header: > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/uapi/drm/exynos_drm.h > > The event stuff has been there since 2012: > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/include/drm/exynos_drm.h?id=d7f1642c90ab5eb2d7c48af0581c993094f97e1a > > The only reason why I haven't added the IPP things, is because I don't > intend to work on this for the moment. > Hmmm good point. Seems like the changes went in before I started following exynos development. If it's in an upstream kernel, then it's save to land in libdrm. Objection withdrawn. I have an idea how we can get things back into shape (wrt headers being out if sync) - I will propose/post a solution shortly. >> Wrt extending the current drmEventContext, I'm not sure that adding >> device specific changes to it are allowed. > Why shouldn't it? Isn't drmHandleEvent supposed to handle all kinds of > DRM events that the kernel produces? > Bth I'm not familiar with the code in question, although a quick grep indicates that libdrm does not contain any driver specific information. That is aside from the include/drm headers, although they are not part of the library or its interface. Maybe some of the more experienced devs can share some light ? Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent 2015-03-20 22:25 ` [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent Tobias Jakobi 2015-03-22 15:41 ` Emil Velikov @ 2015-03-30 0:02 ` Rob Clark 2015-03-30 11:37 ` Tobias Jakobi 2015-03-30 13:04 ` Tobias Jakobi 1 sibling, 2 replies; 17+ messages in thread From: Rob Clark @ 2015-03-30 0:02 UTC (permalink / raw) To: Tobias Jakobi Cc: Thomas Hellstrom, moderated list:ARM/S5P EXYNOS AR..., Emil Velikov, dri-devel, Marek Szyprowski so, iirc, vmwgfx also has some custom events.. not really sure if they have their own hand-rolled drmHandleEvent() or if they have another way of catching those. Maybe we need some more flexible way to register handlers for driver custom events? But everyone adding their own thing to drmHandleEvent() doesn't really seem so nice.. that said, I'm not sure how much to care. If it is just exynos and vmwgfx, then telling them to use there own version of of drmHandleEvent() might be ok. But if driver custom events somehow become more popular, maybe we want a better solution.. BR, -R On Fri, Mar 20, 2015 at 6:25 PM, Tobias Jakobi <tjakobi@math.uni-bielefeld.de> wrote: > This event is specific to Exynos G2D DRM driver. Only > process it when Exynos support is enabled. > > Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> > --- > exynos/exynos_drm.h | 12 ++++++++++++ > xf86drm.h | 7 ++++++- > xf86drmMode.c | 18 ++++++++++++++++++ > 3 files changed, 36 insertions(+), 1 deletion(-) > > diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h > index 256c02f..c3af0ac 100644 > --- a/exynos/exynos_drm.h > +++ b/exynos/exynos_drm.h > @@ -157,4 +157,16 @@ struct drm_exynos_g2d_exec { > #define DRM_IOCTL_EXYNOS_G2D_EXEC DRM_IOWR(DRM_COMMAND_BASE + \ > DRM_EXYNOS_G2D_EXEC, struct drm_exynos_g2d_exec) > > +/* EXYNOS specific events */ > +#define DRM_EXYNOS_G2D_EVENT 0x80000000 > + > +struct drm_exynos_g2d_event { > + struct drm_event base; > + __u64 user_data; > + __u32 tv_sec; > + __u32 tv_usec; > + __u32 cmdlist_no; > + __u32 reserved; > +}; > + > #endif > diff --git a/xf86drm.h b/xf86drm.h > index 40c55c9..6b1c9b4 100644 > --- a/xf86drm.h > +++ b/xf86drm.h > @@ -719,7 +719,7 @@ extern void drmMsg(const char *format, ...) DRM_PRINTFLIKE(1, 2); > extern int drmSetMaster(int fd); > extern int drmDropMaster(int fd); > > -#define DRM_EVENT_CONTEXT_VERSION 2 > +#define DRM_EVENT_CONTEXT_VERSION 3 > > typedef struct _drmEventContext { > > @@ -739,6 +739,11 @@ typedef struct _drmEventContext { > unsigned int tv_usec, > void *user_data); > > + void (*g2d_event_handler)(int fd, > + unsigned int cmdlist_no, > + unsigned int tv_sec, > + unsigned int tv_usec, > + void *user_data); > } drmEventContext, *drmEventContextPtr; > > extern int drmHandleEvent(int fd, drmEventContextPtr evctx); > diff --git a/xf86drmMode.c b/xf86drmMode.c > index 61d5e01..d9f2898 100644 > --- a/xf86drmMode.c > +++ b/xf86drmMode.c > @@ -53,6 +53,10 @@ > #include <unistd.h> > #include <errno.h> > > +#ifdef HAVE_EXYNOS > +#include <exynos/exynos_drm.h> > +#endif > + > #ifdef HAVE_VALGRIND > #include <valgrind.h> > #include <memcheck.h> > @@ -846,6 +850,7 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx) > int len, i; > struct drm_event *e; > struct drm_event_vblank *vblank; > + struct drm_exynos_g2d_event *g2d; > > /* The DRM read semantics guarantees that we always get only > * complete events. */ > @@ -882,6 +887,19 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx) > vblank->tv_usec, > U642VOID (vblank->user_data)); > break; > +#ifdef HAVE_EXYNOS > + case DRM_EXYNOS_G2D_EVENT: > + if (evctx->version < 3 || > + evctx->g2d_event_handler == NULL) > + break; > + g2d = (struct drm_exynos_g2d_event *) e; > + evctx->g2d_event_handler(fd, > + g2d->cmdlist_no, > + g2d->tv_sec, > + g2d->tv_usec, > + U642VOID (g2d->user_data)); > + break; > +#endif > default: > break; > } > -- > 2.0.5 > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent 2015-03-30 0:02 ` Rob Clark @ 2015-03-30 11:37 ` Tobias Jakobi 2015-03-30 13:04 ` Tobias Jakobi 1 sibling, 0 replies; 17+ messages in thread From: Tobias Jakobi @ 2015-03-30 11:37 UTC (permalink / raw) To: Rob Clark Cc: Thomas Hellstrom, moderated list:ARM/S5P EXYNOS AR..., Emil Velikov, dri-devel, Marek Szyprowski Hello, On 2015-03-30 02:02, Rob Clark wrote: > Maybe we need some more flexible way to register handlers for driver > custom events? But everyone adding their own thing to > drmHandleEvent() doesn't really seem so nice.. that said, I'm not > sure how much to care. If it is just exynos and vmwgfx, then telling > them to use there own version of of drmHandleEvent() might be ok. But > if driver custom events somehow become more popular, maybe we want a > better solution.. I don't like the idea of just copying the current drmHandleEvent() code and putting it into the exynos code together with the additional switch cases. It just screams "HACK!" to me. I'm going to try to come up with a solution where we can at least share some of the code. With best wishes, Tobias > > BR, > -R > > On Fri, Mar 20, 2015 at 6:25 PM, Tobias Jakobi > <tjakobi@math.uni-bielefeld.de> wrote: >> This event is specific to Exynos G2D DRM driver. Only >> process it when Exynos support is enabled. >> >> Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> >> --- >> exynos/exynos_drm.h | 12 ++++++++++++ >> xf86drm.h | 7 ++++++- >> xf86drmMode.c | 18 ++++++++++++++++++ >> 3 files changed, 36 insertions(+), 1 deletion(-) >> >> diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h >> index 256c02f..c3af0ac 100644 >> --- a/exynos/exynos_drm.h >> +++ b/exynos/exynos_drm.h >> @@ -157,4 +157,16 @@ struct drm_exynos_g2d_exec { >> #define DRM_IOCTL_EXYNOS_G2D_EXEC >> DRM_IOWR(DRM_COMMAND_BASE + \ >> DRM_EXYNOS_G2D_EXEC, struct drm_exynos_g2d_exec) >> >> +/* EXYNOS specific events */ >> +#define DRM_EXYNOS_G2D_EVENT 0x80000000 >> + >> +struct drm_exynos_g2d_event { >> + struct drm_event base; >> + __u64 user_data; >> + __u32 tv_sec; >> + __u32 tv_usec; >> + __u32 cmdlist_no; >> + __u32 reserved; >> +}; >> + >> #endif >> diff --git a/xf86drm.h b/xf86drm.h >> index 40c55c9..6b1c9b4 100644 >> --- a/xf86drm.h >> +++ b/xf86drm.h >> @@ -719,7 +719,7 @@ extern void drmMsg(const char *format, ...) >> DRM_PRINTFLIKE(1, 2); >> extern int drmSetMaster(int fd); >> extern int drmDropMaster(int fd); >> >> -#define DRM_EVENT_CONTEXT_VERSION 2 >> +#define DRM_EVENT_CONTEXT_VERSION 3 >> >> typedef struct _drmEventContext { >> >> @@ -739,6 +739,11 @@ typedef struct _drmEventContext { >> unsigned int tv_usec, >> void *user_data); >> >> + void (*g2d_event_handler)(int fd, >> + unsigned int cmdlist_no, >> + unsigned int tv_sec, >> + unsigned int tv_usec, >> + void *user_data); >> } drmEventContext, *drmEventContextPtr; >> >> extern int drmHandleEvent(int fd, drmEventContextPtr evctx); >> diff --git a/xf86drmMode.c b/xf86drmMode.c >> index 61d5e01..d9f2898 100644 >> --- a/xf86drmMode.c >> +++ b/xf86drmMode.c >> @@ -53,6 +53,10 @@ >> #include <unistd.h> >> #include <errno.h> >> >> +#ifdef HAVE_EXYNOS >> +#include <exynos/exynos_drm.h> >> +#endif >> + >> #ifdef HAVE_VALGRIND >> #include <valgrind.h> >> #include <memcheck.h> >> @@ -846,6 +850,7 @@ int drmHandleEvent(int fd, drmEventContextPtr >> evctx) >> int len, i; >> struct drm_event *e; >> struct drm_event_vblank *vblank; >> + struct drm_exynos_g2d_event *g2d; >> >> /* The DRM read semantics guarantees that we always get only >> * complete events. */ >> @@ -882,6 +887,19 @@ int drmHandleEvent(int fd, drmEventContextPtr >> evctx) >> vblank->tv_usec, >> U642VOID >> (vblank->user_data)); >> break; >> +#ifdef HAVE_EXYNOS >> + case DRM_EXYNOS_G2D_EVENT: >> + if (evctx->version < 3 || >> + evctx->g2d_event_handler == NULL) >> + break; >> + g2d = (struct drm_exynos_g2d_event *) e; >> + evctx->g2d_event_handler(fd, >> + g2d->cmdlist_no, >> + g2d->tv_sec, >> + g2d->tv_usec, >> + U642VOID >> (g2d->user_data)); >> + break; >> +#endif >> default: >> break; >> } >> -- >> 2.0.5 >> >> _______________________________________________ >> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent 2015-03-30 0:02 ` Rob Clark 2015-03-30 11:37 ` Tobias Jakobi @ 2015-03-30 13:04 ` Tobias Jakobi 2015-04-21 18:14 ` Emil Velikov 1 sibling, 1 reply; 17+ messages in thread From: Tobias Jakobi @ 2015-03-30 13:04 UTC (permalink / raw) To: Rob Clark Cc: moderated list:ARM/S5P EXYNOS AR..., Emil Velikov, dri-devel, Marek Szyprowski, Thomas Hellstrom Hello, On 2015-03-30 02:02, Rob Clark wrote: > so, iirc, vmwgfx also has some custom events.. not really sure if > they have their own hand-rolled drmHandleEvent() or if they have > another way of catching those. > > Maybe we need some more flexible way to register handlers for driver > custom events? But everyone adding their own thing to > drmHandleEvent() doesn't really seem so nice.. that said, I'm not > sure how much to care. If it is just exynos and vmwgfx, then telling > them to use there own version of of drmHandleEvent() might be ok. But > if driver custom events somehow become more popular, maybe we want a > better solution.. would something like this work for you guys: https://www.math.uni-bielefeld.de/~tjakobi/archive/0001-custom-events.patch (this is not compile tested or anything, just a draft) Basically this introduces drmHandleEvent2, which is drmHandleEvent with two additional arguments. The first one being a function pointer through which the 'remaining' events (which are not handled by the common code) are handled, and some (opaque) pointer to data that the handler might need. In the vendor specific code I then introcuded exynos_handle_event which calls dramHandleEvent2 with a properly setup handler. vmwgfx could do the same here I guess. With best wishes, Tobias ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent 2015-03-30 13:04 ` Tobias Jakobi @ 2015-04-21 18:14 ` Emil Velikov 2015-04-23 12:04 ` Tobias Jakobi 0 siblings, 1 reply; 17+ messages in thread From: Emil Velikov @ 2015-04-21 18:14 UTC (permalink / raw) To: Tobias Jakobi, Rob Clark Cc: emil.l.velikov, moderated list:ARM/S5P EXYNOS AR..., dri-devel, Marek Szyprowski, Thomas Hellstrom Hi Tobias, On 30/03/15 13:04, Tobias Jakobi wrote: > Hello, > > On 2015-03-30 02:02, Rob Clark wrote: >> so, iirc, vmwgfx also has some custom events.. not really sure if >> they have their own hand-rolled drmHandleEvent() or if they have >> another way of catching those. >> >> Maybe we need some more flexible way to register handlers for driver >> custom events? But everyone adding their own thing to >> drmHandleEvent() doesn't really seem so nice.. that said, I'm not >> sure how much to care. If it is just exynos and vmwgfx, then telling >> them to use there own version of of drmHandleEvent() might be ok. But >> if driver custom events somehow become more popular, maybe we want a >> better solution.. > > would something like this work for you guys: > https://www.math.uni-bielefeld.de/~tjakobi/archive/0001-custom-events.patch > > (this is not compile tested or anything, just a draft) > > Basically this introduces drmHandleEvent2, which is drmHandleEvent with > two additional arguments. The first one being a function pointer through > which the 'remaining' events (which are not handled by the common code) > are handled, and some (opaque) pointer to data that the handler might need. > > In the vendor specific code I then introcuded exynos_handle_event which > calls dramHandleEvent2 with a properly setup handler. vmwgfx could do > the same here I guess. > I'm assuming that one of the concerns here is about adding API for a single (and not so common) user to the core library. >From a quick look at the mesa and xf86-video-vmware I cannot see the vmwgfx driver using events. It has some definitions in vmwgfx_drm.h but that's about it. That aside - the drmHandleEvent2 approach looks like a massive improvement over the original patch. Personally I do not see any problems with it and think that it's a good way forward. Perhaps you can come over to #dri-devel and ping the devs to get some more feedback. As the topic is not a priority for most of them your suggestions has mostly gone unnoticed. Cheers, Emil ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent 2015-04-21 18:14 ` Emil Velikov @ 2015-04-23 12:04 ` Tobias Jakobi 0 siblings, 0 replies; 17+ messages in thread From: Tobias Jakobi @ 2015-04-23 12:04 UTC (permalink / raw) To: Emil Velikov Cc: Rob Clark, moderated list:ARM/S5P EXYNOS AR..., dri-devel, Marek Szyprowski, Thomas Hellstrom Hello Emil, On 2015-04-21 20:14, Emil Velikov wrote: > Hi Tobias, > > On 30/03/15 13:04, Tobias Jakobi wrote: >> Hello, >> >> On 2015-03-30 02:02, Rob Clark wrote: >>> so, iirc, vmwgfx also has some custom events.. not really sure if >>> they have their own hand-rolled drmHandleEvent() or if they have >>> another way of catching those. >>> >>> Maybe we need some more flexible way to register handlers for driver >>> custom events? But everyone adding their own thing to >>> drmHandleEvent() doesn't really seem so nice.. that said, I'm not >>> sure how much to care. If it is just exynos and vmwgfx, then telling >>> them to use there own version of of drmHandleEvent() might be ok. >>> But >>> if driver custom events somehow become more popular, maybe we want a >>> better solution.. >> >> would something like this work for you guys: >> https://www.math.uni-bielefeld.de/~tjakobi/archive/0001-custom-events.patch >> >> (this is not compile tested or anything, just a draft) >> >> Basically this introduces drmHandleEvent2, which is drmHandleEvent >> with >> two additional arguments. The first one being a function pointer >> through >> which the 'remaining' events (which are not handled by the common >> code) >> are handled, and some (opaque) pointer to data that the handler might >> need. >> >> In the vendor specific code I then introcuded exynos_handle_event >> which >> calls dramHandleEvent2 with a properly setup handler. vmwgfx could do >> the same here I guess. >> > I'm assuming that one of the concerns here is about adding API for a > single (and not so common) user to the core library. > > From a quick look at the mesa and xf86-video-vmware I cannot see the > vmwgfx driver using events. It has some definitions in vmwgfx_drm.h but > that's about it. > > That aside - the drmHandleEvent2 approach looks like a massive > improvement over the original patch. Personally I do not see any > problems with it and think that it's a good way forward. > > Perhaps you can come over to #dri-devel and ping the devs to get some > more feedback. As the topic is not a priority for most of them your > suggestions has mostly gone unnoticed. I'm going to flesh out the non-exynos patches some more before sending them to the ML for discussion. With best wishes, Tobias ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 3/5] exynos/fimg2d: add g2d_config_event 2015-03-20 22:25 drm/exynos: add async G2D execution to libdrm Tobias Jakobi 2015-03-20 22:25 ` [PATCH 1/5] tests/exynos: add fimg2d performance analysis Tobias Jakobi 2015-03-20 22:25 ` [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent Tobias Jakobi @ 2015-03-20 22:25 ` Tobias Jakobi 2015-03-21 14:03 ` drm/exynos: add async G2D execution to libdrm Tobias Jakobi 3 siblings, 0 replies; 17+ messages in thread From: Tobias Jakobi @ 2015-03-20 22:25 UTC (permalink / raw) To: linux-samsung-soc; +Cc: emil.l.velikov, dri-devel, Tobias Jakobi, m.szyprowski This enables us to pass command buffers to the kernel which trigger an event on the DRM fd upon completion. The final goal is to enable asynchronous operation of the G2D engine, similar to async page flips. Passing the event userdata pointer through the G2D context was chosen to not change the current API (e.g. by adding a userdata argument to each public functions). Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> --- exynos/exynos_fimg2d.c | 27 +++++++++++++++++++++++++-- exynos/exynos_fimg2d.h | 2 ++ 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index fc605ed..e90ffed 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -202,8 +202,15 @@ static int g2d_flush(struct g2d_context *ctx) cmdlist.cmd_buf = (uint64_t)(uintptr_t)&ctx->cmd_buf[0]; cmdlist.cmd_nr = ctx->cmd_nr; cmdlist.cmd_buf_nr = ctx->cmd_buf_nr; - cmdlist.event_type = G2D_EVENT_NOT; - cmdlist.user_data = 0; + + if (ctx->event_userdata) { + cmdlist.event_type = G2D_EVENT_NONSTOP; + cmdlist.user_data = (uint64_t)(uintptr_t)(ctx->event_userdata); + ctx->event_userdata = NULL; + } else { + cmdlist.event_type = G2D_EVENT_NOT; + cmdlist.user_data = 0; + } ctx->cmd_nr = 0; ctx->cmd_buf_nr = 0; @@ -259,6 +266,22 @@ drm_public void g2d_fini(struct g2d_context *ctx) } /** + * g2d_config_event - setup userdata configuration for a g2d event. + * The next invocation of a g2d call (e.g. g2d_solid_fill) is + * then going to flag the command buffer as 'nonstop'. + * Completion of the command buffer execution can then be + * determined by using drmHandleEvent on the DRM fd. + * The userdata is 'consumed' in the process. + * + * @ctx: a pointer to g2d_context structure. + * @userdata: a pointer to the user data + */ +drm_public void g2d_config_event(struct g2d_context *ctx, void *userdata) +{ + ctx->event_userdata = userdata; +} + +/** * g2d_exec - start the dma to process all commands summited by g2d_flush(). * * @ctx: a pointer to g2d_context structure. diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h index 9db0c88..421249d 100644 --- a/exynos/exynos_fimg2d.h +++ b/exynos/exynos_fimg2d.h @@ -298,10 +298,12 @@ struct g2d_context { unsigned int cmd_nr; unsigned int cmd_buf_nr; unsigned int cmdlist_nr; + void *event_userdata; }; struct g2d_context *g2d_init(int fd); void g2d_fini(struct g2d_context *ctx); +void g2d_config_event(struct g2d_context *ctx, void *userdata); int g2d_exec(struct g2d_context *ctx); int g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img, unsigned int x, unsigned int y, unsigned int w, -- 2.0.5 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: drm/exynos: add async G2D execution to libdrm 2015-03-20 22:25 drm/exynos: add async G2D execution to libdrm Tobias Jakobi ` (2 preceding siblings ...) 2015-03-20 22:25 ` [PATCH 3/5] exynos/fimg2d: add g2d_config_event Tobias Jakobi @ 2015-03-21 14:03 ` Tobias Jakobi 3 siblings, 0 replies; 17+ messages in thread From: Tobias Jakobi @ 2015-03-21 14:03 UTC (permalink / raw) To: Tobias Jakobi, linux-samsung-soc Cc: dri-devel, emil.l.velikov, jy0922.shim, m.szyprowski, inki.dae Tobias Jakobi wrote: > Hello, > > this series exposes async execution of G2D command buffers to userspace. Also includes is a small performance analysis test, which can also be used to > stress test the engine. The async operation is of course also tested. > > Please review and let me know what I can improve. > > With best wishes, > Tobias Almost forgot this. In case someone is interested in the solid fill performance, I've uploaded a plot here: http://www.math.uni-bielefeld.de/~tjakobi/exynos/g2d_clear_perf.pdf And yes, that should be _nano_seconds on the y-axis. What I find interesting that despite the performance being linear (well, affine linear, since we have a setup time) in the number of pixels to process, you can still see some kind of 'clustering'. I wonder where this comes from, maybe some small alignment penalty, or something? With best wishes, Tobias ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-04-23 12:04 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-20 22:25 drm/exynos: add async G2D execution to libdrm Tobias Jakobi 2015-03-20 22:25 ` [PATCH 1/5] tests/exynos: add fimg2d performance analysis Tobias Jakobi 2015-03-22 15:36 ` Emil Velikov 2015-03-22 16:35 ` Tobias Jakobi 2015-03-25 18:27 ` Tobias Jakobi 2015-03-26 15:16 ` Emil Velikov 2015-03-20 22:25 ` [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent Tobias Jakobi 2015-03-22 15:41 ` Emil Velikov 2015-03-22 16:29 ` Tobias Jakobi 2015-03-23 11:03 ` Emil Velikov 2015-03-30 0:02 ` Rob Clark 2015-03-30 11:37 ` Tobias Jakobi 2015-03-30 13:04 ` Tobias Jakobi 2015-04-21 18:14 ` Emil Velikov 2015-04-23 12:04 ` Tobias Jakobi 2015-03-20 22:25 ` [PATCH 3/5] exynos/fimg2d: add g2d_config_event Tobias Jakobi 2015-03-21 14:03 ` drm/exynos: add async G2D execution to libdrm Tobias Jakobi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.