Re: drm/exynos: g2d userptr memory corruption
Thanks Lucas for the explanation! Lucas Stach wrote: Hi Tobias, Am Sonntag, den 16.08.2015, 14:48 +0200 schrieb Tobias Jakobi: Hello, some time ago I checked whether I could use the userptr functionality to do zero-copy from userspace allocated buffers via the G2D. This didn't work out so well, so kinda put this to the bottom of my TODO list. Now that IOMMU support has landed and Jan Kara has rewrote page pinning using frame vectors (see [1]) I gave userptr another try. The results are much better. I'm not experiencing any kernel lockups or sysmmu pagefaults anymore. However the image now suffers from visual artifacts. These images show the nature of the artifacts: http://i.imgur.com/nzT6g3Y.jpg http://i.imgur.com/wkuYI6X.jpg The corruption always manifests itself in these pixel lines of fixed size and wrong color. I have written a testcase as part of libdrm for this issue: https://github.com/tobiasjakobi/libdrm/commit/db8bf6844436598251f67a71fc334b929bfb2b71 It allocates N (N an even number) buffers which are aligned to the system pagesize. Then it does this each iteration: 1) Fill the first N/2 buffers with random data 2) Copy the first half to the second half of the buffers 3) memcmp() first and second half (verification pass) Usually this verification already fails on the first iteration. An interesting observation is that increasing (!) the buffer size (so the amount of pixels that have to copied per buffer grows) makes this issue less likely to happen. With the default 512x512 buffers however it happens, like I said above, almost immediately. This is obviously a cache flush missing. The memory you get from userspace is normal cached memory, so to make it visible to the GPU you need to flush parts of the cache out to main memory. The corruption you are seeing is just unflushed cachelines. This also explains why increasing the buffer size helps: the more memory the CPU touches the more cachelines will be flushed out to be replaced with new data. I should point out that the snapshots I uploaded were done with a different setup. There only the source memory of the G2D operation is a userspace allocated buffer. The destination is a GEM buffer allocated through libdrm, which is then used as framebuffer. So the issue already appears when just the source is userspace allocated. What works however is an operation between GEM to GEM. However this might be related to the default allocation flags libdrm uses. So you need to go and have a look at dma_map() and dma_sync_*_for_*() and friends. Regards, Lucas With best wishes, Tobias -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
drm/exynos: g2d userptr memory corruption
Hello, some time ago I checked whether I could use the userptr functionality to do zero-copy from userspace allocated buffers via the G2D. This didn't work out so well, so kinda put this to the bottom of my TODO list. Now that IOMMU support has landed and Jan Kara has rewrote page pinning using frame vectors (see [1]) I gave userptr another try. The results are much better. I'm not experiencing any kernel lockups or sysmmu pagefaults anymore. However the image now suffers from visual artifacts. These images show the nature of the artifacts: http://i.imgur.com/nzT6g3Y.jpg http://i.imgur.com/wkuYI6X.jpg The corruption always manifests itself in these pixel lines of fixed size and wrong color. I have written a testcase as part of libdrm for this issue: https://github.com/tobiasjakobi/libdrm/commit/db8bf6844436598251f67a71fc334b929bfb2b71 It allocates N (N an even number) buffers which are aligned to the system pagesize. Then it does this each iteration: 1) Fill the first N/2 buffers with random data 2) Copy the first half to the second half of the buffers 3) memcmp() first and second half (verification pass) Usually this verification already fails on the first iteration. An interesting observation is that increasing (!) the buffer size (so the amount of pixels that have to copied per buffer grows) makes this issue less likely to happen. With the default 512x512 buffers however it happens, like I said above, almost immediately. I first suspected that the clock rate of the G2D was too high (I overclock the engine from 200MHz to 400MHz here), but even with the default clock there is no change to the behaviour. While looking at the issue I remember this discussion [2] so while ago. Adding Marek to Cc since I guess that this could be related to the IOMMU as well (some missing flushing?). With best wishes, Tobias [1] http://www.spinics.net/lists/linux-samsung-soc/msg45931.html [2] http://lists.freedesktop.org/archives/dri-devel/2014-July/062675.html -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[libdrm tests ebuild error] modetest needs update?
Hi there, with a fresh git master from the libdrm repo compilation fails: make[3]: Entering directory `/var/tmp/portage/x11-libs/libdrm-/work/libdrm-/tests/modetest' i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../..-I../../include/drm -I../../intel/ -I../.. -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -O2 -march=pentium-m -fomit-frame-pointer -pipe -MT modetest.o -MD -MP -MF .deps/modetest.Tpo -c -o modetest.o modetest.c modetest.c: In function ‘dump_framebuffers’: modetest.c:259: warning: too few arguments for format modetest.c: In function ‘set_mode’: modetest.c:621: error: ‘drmEventContext’ has no member named ‘pageflip_handler’ modetest.c: In function ‘main’: modetest.c:700: warning: format ‘%64s’ expects type ‘char *’, but argument 4 has type ‘char (*)[64]’ modetest.c:704: warning: format ‘%64s’ expects type ‘char *’, but argument 5 has type ‘char (*)[64]’ Looking at drmEventContext in xf86drm.h the member is called page_flip_handler, and NOT pageflip_handler. Can someone push a fix? Greets, Tobias -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [libdrm tests ebuild error] modetest needs update?
On Fri, 04 Dec 2009 17:22:22 +0100 Tobias Jakobiliquid.a...@gmx.net wrote: Hi there, with a fresh git master from the libdrm repo compilation fails: make[3]: Entering directory `/var/tmp/portage/x11-libs/libdrm-/work/libdrm-/tests/modetest' i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include/drm -I../../intel/ -I../.. -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -O2 -march=pentium-m -fomit-frame-pointer -pipe -MT modetest.o -MD -MP -MF .deps/modetest.Tpo -c -o modetest.o modetest.c modetest.c: In function ‘dump_framebuffers’: modetest.c:259: warning: too few arguments for format modetest.c: In function ‘set_mode’: modetest.c:621: error: ‘drmEventContext’ has no member named ‘pageflip_handler’ modetest.c: In function ‘main’: modetest.c:700: warning: format ‘%64s’ expects type ‘char *’, but argument 4 has type ‘char (*)[64]’ modetest.c:704: warning: format ‘%64s’ expects type ‘char *’, but argument 5 has type ‘char (*)[64]’ Looking at drmEventContext in xf86drm.h the member is called page_flip_handler, and NOT pageflip_handler. Can someone push a fix? Yep, fix pushed. Thanks Jesse, works fine for me! -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[xf86-video-intel] mplayer + GL backend
Hi there, I have some issues with playing back HD (720p) material with mplayer and using the GL video output backend. Usually my system is fast enough to playback 720p if the material is not subtitled. In case ASS style subtitles are used, using the standard Xv output is not fast enough. Therefore I tried to improve the display performance by switching to the GL output backend, which should perform better. It does perform better but I now loose AV-sync. From the mplayer manpage: swapinterval=n Minimum interval between two buffer swaps, counted in displayed frames (default: 1). 1 is equivalent to enabling VSYNC, 0 to disabling VSYNC. Values below 0 will leave it at the system default. This limits the framerate to (horizontal refresh rate / n). Requires GLX_SGI_swap_control support to work.With some (most/all?) implementations this only works in fullscreen mode. I'm using these components: gentoo-sources-2.6.30 libdrm git master mesa git master xf86-video-intel-2.9.1 Could this be a DRI2 related problem? IIRC the vsync stuff for DRI2 is currently in flux and probably not working correctly. I should mention that the AV-sync is lost both with windowed and fullscreen mode. So it doesn't really matter if I start the player with -fs or not. Also the CPU utilization is clearly lower than the one when using Xv and it's also clearly lower than 100% (somewhere around 70%). So the system should be fast enough to do the task, but somehow GLX_SGI_swap_control isn't working like it should. Can somebody comment on this issue? Greets, Tobias -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[libdrm] version number wasn't bumped?
Hi there, I noticed that in mesa/drm/configure.ac there is still version 2.3.1 hardcoded, while in mesa/drm/libdrm/Makefile.am there is version 2.3.0 hardcoded. I'm using libdrm from GIT (master branch) but now the xf86-video-intel driver fails to initialize the TTM buffer manager, resulting in slow 3D acceleration and very laggy 2D acceleration in Xorg. This seems because when building xf86-video-intel DRI_MM is set to disabled, resulting in not using TTM. I've checked the autotools script in the intel repo and found out that DRI_MM gets disabled if the libdrm version is below 2.4.0. The attached patch bumps both version numbers in the mesa/drm repo to 2.4.0. After rebuilding intel the TTM bug mgr works again and 3D is fast again. At least this works for me. I assume that somehow the version number didn't get bumped, right? Or is this intended behaviour? Greets, Tobias From 356d6a3c9a1f9eee20a60a8900b1429231891b23 Mon Sep 17 00:00:00 2001 From: Tobias Jakobi [EMAIL PROTECTED] Date: Fri, 4 Jul 2008 09:52:04 +0200 Subject: bump version to 2.4.0 --- configure.ac |2 +- libdrm/Makefile.am |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 7820334..987b011 100644 --- a/configure.ac +++ b/configure.ac @@ -19,7 +19,7 @@ # CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. AC_PREREQ(2.57) -AC_INIT([libdrm], 2.3.1, [EMAIL PROTECTED], libdrm) +AC_INIT([libdrm], 2.4.0, [EMAIL PROTECTED], libdrm) AC_CONFIG_SRCDIR([Makefile.am]) AM_INIT_AUTOMAKE([dist-bzip2]) diff --git a/libdrm/Makefile.am b/libdrm/Makefile.am index e7e07e4..153bb15 100644 --- a/libdrm/Makefile.am +++ b/libdrm/Makefile.am @@ -20,7 +20,7 @@ libdrm_la_LTLIBRARIES = libdrm.la libdrm_ladir = $(libdir) -libdrm_la_LDFLAGS = -version-number 2:3:0 -no-undefined +libdrm_la_LDFLAGS = -version-number 2:4:0 -no-undefined AM_CFLAGS = -I$(top_srcdir)/shared-core libdrm_la_SOURCES = xf86drm.c xf86drmHash.c xf86drmRandom.c xf86drmSL.c -- 1.5.4.5 - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
