[Mesa-dev] [Bug 96949] [regression] Piglit numSamples assertion failures with 9a23a177b90
https://bugs.freedesktop.org/show_bug.cgi?id=96949 Kenneth Graunkechanged: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Kenneth Graunke --- Thanks! That indeed fixes the regressions. Pushed as: commit b89d0df5351eea1f26c6890dcdff7c0e38424ee1 Author: Brian Paul Date: Fri Jul 15 21:22:53 2016 -0600 mesa: handle numSamples=0 in _mesa_test_proxy_teximage() Should fix the regressions reported in bug 96949. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96949 Reviewed-by: Kenneth Graunke -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: handle numSamples=0 in _mesa_test_proxy_teximage()
On Friday, July 15, 2016 9:22:53 PM PDT Brian Paul wrote: > Should fix the regressions reported in bug 96949. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96949 > --- > src/mesa/main/teximage.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c > index 10232d6..d74a45f 100644 > --- a/src/mesa/main/teximage.c > +++ b/src/mesa/main/teximage.c > @@ -1271,8 +1271,6 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, > GLenum target, > { > uint64_t bytes, mbytes; > > - assert(numSamples > 0); > - > if (numLevels > 0) { >/* Compute total memory for a whole mipmap. This is the path > * taken for glTexStorage(GL_PROXY_TEXTURE_x). > @@ -1306,7 +1304,7 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, > GLenum target, > } > > bytes *= _mesa_num_tex_faces(target); > - bytes *= numSamples; > + bytes *= MAX2(1, numSamples); > > mbytes = bytes / (1024 * 1024); /* convert to MB */ This looks good to me. Thanks Brian! Reviewed-by: Kenneth GraunkeI'm running it through our test lab now - if it works, I'll push it. Have a great time next week! signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: handle numSamples=0 in _mesa_test_proxy_teximage()
Should fix the regressions reported in bug 96949. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96949 --- src/mesa/main/teximage.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c index 10232d6..d74a45f 100644 --- a/src/mesa/main/teximage.c +++ b/src/mesa/main/teximage.c @@ -1271,8 +1271,6 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum target, { uint64_t bytes, mbytes; - assert(numSamples > 0); - if (numLevels > 0) { /* Compute total memory for a whole mipmap. This is the path * taken for glTexStorage(GL_PROXY_TEXTURE_x). @@ -1306,7 +1304,7 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum target, } bytes *= _mesa_num_tex_faces(target); - bytes *= numSamples; + bytes *= MAX2(1, numSamples); mbytes = bytes / (1024 * 1024); /* convert to MB */ -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96949] [regression] Piglit numSamples assertion failures with 9a23a177b90
https://bugs.freedesktop.org/show_bug.cgi?id=96949 --- Comment #2 from Brian Paul--- OK, I think the fix is simple. I posted a patch to mesa-dev. If it checks out for you, feel free to push it to master. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96953] dri2_wl_swrast crashes on 64 bit, but not on 32 bit
https://bugs.freedesktop.org/show_bug.cgi?id=96953 --- Comment #1 from n3rdopolis--- I can add that this is swrast and wayland, as when I try using qtwayland's x11 backend it works, and when I try 64 bit on Intel with qtwayland it works -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96953] dri2_wl_swrast crashes on 64 bit, but not on 32 bit
https://bugs.freedesktop.org/show_bug.cgi?id=96953 Bug ID: 96953 Summary: dri2_wl_swrast crashes on 64 bit, but not on 32 bit Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: EGL/Wayland Assignee: wayland-b...@lists.freedesktop.org Reporter: bluescreen_aven...@verizon.net QA Contact: mesa-dev@lists.freedesktop.org I am not sure if this is because of qtwayland or because of mesa, but it seems I am getting a crash with git master I have a stack trace, let me know if running it with any variables exported I am building mesa with ./autogen.sh --prefix=$INSTALLDIR --enable-driglx-direct --enable-dri --with-dri-drivers=r200,radeon,nouveau,i915,i965,swrast --enable-osmesa --enable-xa --enable-glx-tls --enable-shared-dricore --enable-gles1 --enable-gles2 --with-gallium-drivers=nouveau,svga,r300,r600,swrast,radeonsi,virgl --with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi --enable-gallium-egl --with-llvm-prefix=/usr/lib/llvm-3.6/ --with-llvm-shared-libs --libdir=$INSTALLDIR/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH) 0 dri2_wl_swrast_put_image2 (draw=0x300c240, op=, x=, y=0, w=, h=0, stride=64, data=0x3012b40 "", loaderPrivate=0x3012240) at drivers/dri2/platform_wayland.c:1642 dri2_surf = 0x3012240 copy_width = -4 src = 0x36d4000 dst = 0x7fffcd4f4ffc __PRETTY_FUNCTION__ = "dri2_wl_swrast_put_image2" #1 0x7fffed28ed26 in dri2_wl_swrast_put_image ( draw=, op=, x=, y=, w=, h=, data=0x3012b40 "", loaderPrivate=0x3012240) at drivers/dri2/platform_wayland.c:1658 dri2_surf = 0x3012240 #2 0x7fffea1bbd38 in put_image (height=, width=, data=, dPriv=) at drisw.c:71 sPriv = loader = #3 drisw_put_image (drawable=, data=, width=, height=) at drisw.c:141 dPriv = #4 0x7fffea1bc1dd in drisw_copy_to_front (ptex=0x300c0d0, dPriv=0x300c240) at drisw.c:181 No locals. #5 drisw_swap_buffers (dPriv=0x300c240) at drisw.c:208 ctx = 0x2e2ac20 ptex = 0x300c0d0 #6 0x7fffed28d0b9 in dri2_wl_swrast_swap_buffers ( drv=, disp=, draw=) at drivers/dri2/platform_wayland.c:1729 No locals. #7 0x7fffed2839e2 in eglSwapBuffers (dpy=0x710400, surface=surface@entry=0x3012240) at main/eglapi.c:1008 ctx = 0x2e7ef00 disp = 0x710400 surf = 0x3012240 drv = ret = __func__ = "eglSwapBuffers" #8 0x77e57b7a in QtWaylandClient::QWaylandGLContext::swapBuffers (this=0x2e7eb90, surface=0x2dd1a00) at ../../../hardwareintegration/client/wayland-egl/qwaylandglcontext.cpp:553 window = 0x2dd19f0 eglSurface = 0x3012240 sub = 0x0 #9 0x76854238 in QOpenGLContext::swapBuffers ( this=this@entry=0x2d91790, surface=surface@entry=0x2dd0650) at /srcbuild/qtbase/src/gui/kernel/qopenglcontext.cpp:1063 __PRETTY_FUNCTION__ = "void QOpenGLContext::swapBuffers(QSurface*)" surfaceHandle = 0x2dd1a00 #10 0x769a4c8a in QPlatformBackingStore::composeAndFlush ( this=this@entry=0x2dd1550, window=window@entry=0x2dd0640, region=..., offset=..., textures=, context=, translucentBackground=false) at /srcbuild/qtbase/src/gui/painting/qplatformbackingstore.cpp:414 funcs = 0x3012080 deviceWindowRect = {x1 = 0, y1 = 0, x2 = 1009, y2 = 575} textureId = origin = #11 0x769a4d8b in QPlatformBackingStore::composeAndFlush ( this=this@entry=0x2dd1550, window=0x2dd0640, region=..., offset=..., textures=textures@entry=0x7745cf40 <(anonymous namespace)::Q_QGS_qt_dummy_platformTextureList::innerFunction()::holder>, context=context@entry=0x2d91790, translucentBackground=false) at /srcbuild/qtbase/src/gui/painting/qplatformbackingstore.cpp:317 No locals. #12 0x77049590 in QWidgetBackingStore::qt_flush ( widget=widget@entry=0x83d880, region=..., backingStore=, tlw=0x83d880, tlwOffset=..., widgetTextures=0x7745cf40 <(anonymous namespace)::Q_QGS_qt_dummy_platformTextureList::innerFunction()::holder>, widgetBackingStore=0x2dd1b30) at /srcbuild/qtbase/src/widgets/kernel/qwidgetbackingstore.cpp:138 translucentBackground = false flushUpdate = 0 fpsDebug = false __PRETTY_FUNCTION__ = "static void QWidgetBackingStore::qt_flush(QWidget*, const QRegion&, QBackingStore*, QWidget*, const QPoint&, QPlatformTextureList*, QWidgetBackingStore*)" offset = {xp = 0, yp = 0} compositionWasActive = #13 0x77049ed3 in QWidgetBackingStore::flush ( this=this@entry=0x2dd1b30, widget=widget@entry=0x0) at /srcbuild/qtbase/src/widgets/kernel/qwidgetbackingstore.cpp:1415 target = 0x83d880 hasDirtyOnScreenWidgets = false
Re: [Mesa-dev] mesa from git fails to compile
Sorry to not respond earlier, I've apparently been having silent filesystem corruption for over a week now. Can you use pip --user to install a newer version of mako locally? mako 0.5 was realeased in late 2011, and not having the output_encoding and future_imports arguments are going to make hybridizing for python3 very painful. In the short term I can send a patch that makes it work with 0.5.0, but there may not be a good way in the future to keep compatibility. Just FYI, mako 0.8 was released in early 2013, which is what piglit requires as it's minimum. On Thu, Jul 14, 2016, at 07:48, Pali Rohár wrote: > On Thursday 14 July 2016 15:41:51 Eric Engestrom wrote: > > On Thu, Jul 14, 2016 at 12:24:32PM +0200, Pali Rohár wrote: > > > Any news? Or possible fix? > > > > Have you tried Emil's suggestion, ie. upgrading to at least 0.8.0? > > No, as I wrote that ubuntu precise for that build has only python-mako > in version 0.5.0 :-( As ubuntu precise does not have newer version I > cannot update system package... > > > Build system wizards: > > Any way to check the version and abort the compilation before running > > into this issue? If it helps, this prints the version: > > python <<< 'import mako; print(mako.__version__)' > > -- > Pali Rohár > pali.ro...@gmail.com > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Dylan Baker dy...@pnwbakers.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Required Mako version? (WAS: mesa from git fails to compile)
Adding Dylan On Jul 14, 2016 10:24 PM, "Samuel Iglesias Gonsálvez"wrote: > > > On 14/07/16 18:34, Eric Engestrom wrote: > > On Thu, Jul 14, 2016 at 04:01:13PM +0100, Eric Engestrom wrote: > >> Oh right, there's already check for the Mako version, but the minimum is > >> currently set to 0.3.4 (configure.ac:92). > >> > >> Emil, you were the one to mention 0.8.0; is that the actual minimum, or > >> just a known working version? > > > > OK, so I did a bit of digging, and the version check was introduced by > > Samuel Iglesias Gonsalvez a couple years ago (2b37bea0) at 0.7.3, and > > he later lowered it to 0.3.4 (6d43a4c3), but I can't find any discussion > > regarding this change: it seems there was none on the mailing list [0]. > > > > Adding Samuel so he can enlighten us :) > > > > [0] > https://lists.freedesktop.org/archives/mesa-dev/2015-January/074366.html > > > > There was a discussion in the mailing list. Just after I pushed this > patch to master [0] setting it to 0.7.3 (because that was the version I > had back then), Dave Airlie mentioned that RHEL6 only ships mako 0.3.4 > [1] and asked if we really need a later version or not. We did some > tests [2][3] and finally this patch [4] was pushed upstream. > > I don't know if we need some feature from mako 0.8.0 to generate > isl_format_layout because this file was added later than my change, > probably Emil knows it. > > Sam > > [0] > https://lists.freedesktop.org/archives/mesa-dev/2015-January/074000.html > [1] > https://lists.freedesktop.org/archives/mesa-dev/2015-January/074283.html > [2] > https://lists.freedesktop.org/archives/mesa-dev/2015-January/074287.html > [3] > https://lists.freedesktop.org/archives/mesa-dev/2015-January/074332.html > [4] > https://lists.freedesktop.org/archives/mesa-dev/2015-January/074366.html > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] i915: store reference to the context within struct intel_fence
Hi, I'm sending the v2 re-spin of patch as per i965, rechecked twice line-by-line with Tomasz's one. Building ok, marshmallow-x86 booting ok and here are the results of Android CTS egl and gles2 x86 target tests Android CTS 6.0_r7 build:2906653 07-16 00:52:42 I/DeviceManager: Detected new device 192.168.1.7: cts-tf > list r Session Pass Fail Not Executed Start time Plan name Device serial(s) 0(EGL) 1410 24 0 2016.07.16_00.21.30 NA unknown 1(GLES2) 13832 82 0 2016.07.16_00.24.23 NA unknown cts-tf > I get the same results as per i965GM Mauro >From d35c093d48facae4ad0d7119a8b6fdc898a6a1e8 Mon Sep 17 00:00:00 2001 From: Mauro RossiDate: Fri, 15 Jul 2016 21:46:09 +0200 Subject: [PATCH] i915: store reference to the context within struct intel_fence (v2) Porting of the corresponding patch for i965. Here follows the original commit message by Tomasz Figa: "As the spec allows for {server,client}_wait_sync to be called without currently bound context, while our implementation requires context pointer. v2: Add a mutex and acquire it for the duration of brw_fence_client_wait() and brw_fence_is_completed() as suggested by Chad." NOTE: in i915 all references to 'brw' are replaced by 'intel' --- src/mesa/drivers/dri/i915/intel_syncobj.c | 55 --- 1 file changed, 44 insertions(+), 11 deletions(-) diff --git a/src/mesa/drivers/dri/i915/intel_syncobj.c b/src/mesa/drivers/dri/i915/intel_syncobj.c index 18d1546..5d37204a 100644 --- a/src/mesa/drivers/dri/i915/intel_syncobj.c +++ b/src/mesa/drivers/dri/i915/intel_syncobj.c @@ -46,9 +46,11 @@ #include "intel_reg.h" struct intel_fence { + struct intel_context *intel; /** The fence waits for completion of this batch. */ drm_intel_bo *batch_bo; + mtx_t mutex; bool signalled; }; @@ -77,7 +79,7 @@ intel_fence_insert(struct intel_context *intel, struct intel_fence *fence) } static bool -intel_fence_has_completed(struct intel_fence *fence) +intel_fence_has_completed_locked(struct intel_fence *fence) { if (fence->signalled) return true; @@ -92,13 +94,21 @@ intel_fence_has_completed(struct intel_fence *fence) return false; } -/** - * Return true if the function successfully signals or has already signalled. - * (This matches the behavior expected from __DRI2fence::client_wait_sync). - */ static bool -intel_fence_client_wait(struct intel_context *intel, struct intel_fence *fence, - uint64_t timeout) +intel_fence_has_completed(struct intel_fence *fence) +{ + bool ret; + + mtx_lock(>mutex); + ret = intel_fence_has_completed_locked(fence); + mtx_unlock(>mutex); + + return ret; +} + +static bool +intel_fence_client_wait_locked(struct intel_context *intel, struct intel_fence *fence, + uint64_t timeout) { if (fence->signalled) return true; @@ -123,6 +133,23 @@ intel_fence_client_wait(struct intel_context *intel, struct intel_fence *fence, return true; } +/** + * Return true if the function successfully signals or has already signalled. + * (This matches the behavior expected from __DRI2fence::client_wait_sync). + */ +static bool +intel_fence_client_wait(struct intel_context *intel, struct intel_fence *fence, + uint64_t timeout) +{ + bool ret; + + mtx_lock(>mutex); + ret = intel_fence_client_wait_locked(intel, fence, timeout); + mtx_unlock(>mutex); + + return ret; +} + static void intel_fence_server_wait(struct intel_context *intel, struct intel_fence *fence) { @@ -215,6 +242,8 @@ intel_dri_create_fence(__DRIcontext *ctx) if (!fence) return NULL; + mtx_init(>mutex, mtx_plain); + fence->intel = intel; intel_fence_insert(intel, fence); return fence; @@ -233,19 +262,23 @@ static GLboolean intel_dri_client_wait_sync(__DRIcontext *ctx, void *driver_fence, unsigned flags, uint64_t timeout) { - struct intel_context *intel = ctx->driverPrivate; struct intel_fence *fence = driver_fence; - return intel_fence_client_wait(intel, fence, timeout); + return intel_fence_client_wait(fence->intel, fence, timeout); } static void intel_dri_server_wait_sync(__DRIcontext *ctx, void *driver_fence, unsigned flags) { - struct intel_context *intel = ctx->driverPrivate; struct intel_fence *fence = driver_fence; - intel_fence_server_wait(intel, fence); + /* We might be called here with a NULL fence as a result of WaitSyncKHR +* on a EGL_KHR_reusable_sync fence. Nothing to do here in such case. +*/ + if (!fence) + return; + + intel_fence_server_wait(fence->intel, fence); } const __DRI2fenceExtension intelFenceExtension = { -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96949] [regression] Piglit numSamples assertion failures with 9a23a177b90
https://bugs.freedesktop.org/show_bug.cgi?id=96949 Nanley Cherychanged: What|Removed |Added CC||anuj.pho...@gmail.com -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode
Zhang, Boyuan wrote: Hi Andy, The memory issue is fixed. Please try the new patch set I just submitted. Should NOT have hard lock anymore. Seems good, no leak and no lock :-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96950] Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.
https://bugs.freedesktop.org/show_bug.cgi?id=96950 --- Comment #2 from Brian Paul--- (In reply to Rob Clark from comment #1) > Do you still see the issue after 64d35f81 "vbo: fix attr reset"? Yes. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96950] Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.
https://bugs.freedesktop.org/show_bug.cgi?id=96950 --- Comment #1 from Rob Clark--- Do you still see the issue after 64d35f81 "vbo: fix attr reset"? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96950] Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.
https://bugs.freedesktop.org/show_bug.cgi?id=96950 Rob Clarkchanged: What|Removed |Added CC||robcl...@freedesktop.org -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96950] Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.
https://bugs.freedesktop.org/show_bug.cgi?id=96950 Brian Paulchanged: What|Removed |Added CC||mathias.froehl...@web.de -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96950] Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.
https://bugs.freedesktop.org/show_bug.cgi?id=96950 Bug ID: 96950 Summary: Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*. Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: bri...@vmware.com QA Contact: mesa-dev@lists.freedesktop.org I'm seeing a failed assertion at vbo_exec_api.c:183 that started with commit bc4e0c486. It occurs with Redway3D's Turbine demo (I think it's Windows only). I've taken a quick look but haven't found the cause. I may take a look in a week when I'm back from vacation. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96949] [regression] Piglit numSamples assertion failures with 9a23a177b90
https://bugs.freedesktop.org/show_bug.cgi?id=96949 --- Comment #1 from Brian Paul--- I'd appreciate it if you could debug this a bit further. I didn't see any of those regressions here. I'm on vacation for the next week so I won't be able to do anything. Feel free to revert the patch if you can't debug it. Thanks. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Multithreaded shader compilation
On Wed, Jul 13, 2016 at 10:50 AM, Vedran Miletićwrote: > On 07/13/2016 05:19 AM, Timothy Arceri wrote: >> >> So I finally got around to setting up my new polaris card on fedora. I >> was curious to see how Talos performed compared to i965 as I was pretty >> sure the compiling/linking was not just to do with variants and should >> be noticable regardless of hardware. >> >> The results looks the same to me, there is really bad jerkyness for >> around 5-10 seconds as you walk when the game first loads from a >> contine point in the big hall area (the place where you often start a >> continue from as this is where it auto saves). Obviously these get >> cached in memory but you see them everytime you start the game and they >> are very noticable on my machine at least. >> >> Anyway obviously up to you what you work on but I don't think an on >> disk shader cache for radeonsi would be a wasted effort. >> >> Tim >> > > Can confirm on Tonga. Very visible in first vs second run of a Benchmark in > the game; in the first run there is a very long stop (approx 1 second) the > moment the character picks up the green sigil (and a few other points, I > would have to check exactly), second run is all smooth. Those stalls are not so visible while you're playing the game. It's somehow just more visible during the benchmark. I'd say the games that would benefit from a persistent shader cache are in this order: - Borderlands 2 - Bioshock Infinite - ??? Not so much Talos Principle unless you are focusing on the benchmark only. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 19/34] i965/state: Add a helper for emitting a surface state using isl
On Fri, Jul 15, 2016 at 2:30 PM, Chad Versacewrote: > On Thu 14 Jul 2016, Chad Versace wrote: > > On Wed 13 Jul 2016, Jason Ekstrand wrote: > > > Reviewed-by: Topi Pohjolainen > > > --- > > > src/mesa/drivers/dri/i965/brw_state.h| 8 +++ > > > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 79 > > > > 2 files changed, 87 insertions(+) > > > > > > diff --git a/src/mesa/drivers/dri/i965/brw_state.h > b/src/mesa/drivers/dri/i965/brw_state.h > > > index a16e876..91ebce9 100644 > > > --- a/src/mesa/drivers/dri/i965/brw_state.h > > > +++ b/src/mesa/drivers/dri/i965/brw_state.h > > > @@ -274,6 +274,14 @@ GLuint translate_tex_format(struct brw_context > *brw, > > > int brw_get_texture_swizzle(const struct gl_context *ctx, > > > const struct gl_texture_object *t); > > > > > > > Move the forward declaration below to the top of the header. As written, > > it looks like the function's return type. > I'll do one better. Now that we have an isl_device in brw_context, we isl.h is included basically globally so there's no need for the forward declaration. :) > > > +struct isl_view; > > > +void brw_emit_surface_state(struct brw_context *brw, > > > +struct intel_mipmap_tree *mt, > > > +const struct isl_view *view, > > > +uint32_t mocs, bool for_gather, > > > +uint32_t *surf_offset, int surf_index, > > > +unsigned read_domains, unsigned > write_domains); > > Ping! Unresolved issue^^^ > > Fix that, and this patch is > Reviewed-by: Chad Versace > Thanks! > > But keep reading... > > > > > > + if (aux_surf) { > > > + /* On gen7 and prior, the bottom 12 bits of the MCS base > address are > > > + * used to store other information. This should be ok, > however, because > > > + * surface buffer addresses are always 4K page alinged. > > > + */ > > > > Could you please insert the original comment from gen7_wm_surface_state? > > Because... > > > > > + assert((aux_offset & 0xfff) == 0); > > > + drm_intel_bo_emit_reloc(brw->batch.bo, > > > + *surf_offset + 4 * ss_info.aux_reloc_dw, > > > + mt->mcs_mt->bo, > dw[ss_info.aux_reloc_dw] & 0xfff, > > > > > > > ...that ^^^ bit of code REALLY confused me until I found the original > > comment. What's happening is obvious in retrospect, yet terribly obscure > > without a fuller comment. > > I prefer you insert the original comment, or at least some more > explanation. My r-b stands with or without a comment update. > I copied the original comment. The only change I made was to prefix it with "on gen7 and prior..." --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96949] [regression] Piglit numSamples assertion failures with 9a23a177b90
https://bugs.freedesktop.org/show_bug.cgi?id=96949 Bug ID: 96949 Summary: [regression] Piglit numSamples assertion failures with 9a23a177b90 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: nanleych...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org CC: bri...@vmware.com With commit 9a23a177b90ea60ba45b8b5090b832c87d595346 , mesa: handle numLevels, numSamples in _mesa_test_proxy_teximage() The 26 piglit tests listed below start failing with the error, src/mesa/main/teximage.c:1274: _mesa_test_proxy_teximage: Assertion `numSamples > 0' failed. piglit.spec.arb_texture_view.sampling-2d-array-as-cubemap-array piglit.spec.arb_texture_view.copytexsubimage-layers piglit.spec.arb_texture_view.texsubimage-levels pbo piglit.spec.arb_texture_view.targets piglit.spec.arb_texture_view.rendering-levels piglit.spec.arb_texture_view.texsubimage-layers pbo piglit.spec.arb_texture_view.clear-into-view-layered piglit.spec.arb_copy_image.arb_copy_image-texview piglit.spec.arb_texture_view.cubemap-view piglit.spec.arb_texture_view.texsubimage-layers piglit.spec.arb_texture_view.mipgen piglit.spec.arb_texture_view.max-level piglit.spec.arb_texture_view.clear-into-view-2d-array piglit.spec.arb_texture_view.clear-into-view-2d piglit.spec.arb_texture_view.rendering-formats piglit.spec.arb_texture_view.sampling-2d-array-as-2d-layer piglit.spec.arb_texture_view.sampling-2d-array-as-cubemap piglit.spec.arb_texture_view.lifetime-format piglit.spec.arb_texture_view.texsubimage-levels piglit.spec.arb_texture_view.formats piglit.spec.arb_texture_view.queries piglit.spec.arb_clear_texture.arb_clear_texture-texview piglit.spec.arb_texture_view.rendering-layers piglit.spec.arb_texture_view.getteximage-srgb piglit.spec.arb_texture_view.rendering-target piglit.spec.arb_texture_view.params -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] nir: Add a nir_deref_foreach_leaf helper
Signed-off-by: Jason EkstrandCc: "12.0" Cc: Connor Abbott --- src/compiler/nir/nir.c | 107 +++ src/compiler/nir/nir.h | 4 ++ src/compiler/nir/nir_lower_returns.c | 9 +-- 3 files changed, 116 insertions(+), 4 deletions(-) diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c index 3c8b4e0..a4a28a3 100644 --- a/src/compiler/nir/nir.c +++ b/src/compiler/nir/nir.c @@ -659,6 +659,113 @@ nir_copy_deref(void *mem_ctx, nir_deref *deref) return NULL; } +/* This is the second step in the recursion. We've found the tail and made a + * copy. Now we need to iterate over all possible leaves and call the + * callback on each one. + */ +static bool +deref_foreach_leaf_build_recur(nir_deref_var *deref, nir_deref *tail, + nir_deref_foreach_leaf_cb cb, void *state) +{ + unsigned length; + union { + nir_deref_array arr; + nir_deref_struct str; + } tmp; + + assert(tail->child == NULL); + switch (glsl_get_base_type(tail->type)) { + case GLSL_TYPE_ARRAY: + tmp.arr.deref.deref_type = nir_deref_type_array; + tmp.arr.deref.child = NULL; + tmp.arr.deref.type = glsl_get_array_element(tail->type); + tmp.arr.deref_array_type = nir_deref_array_type_direct; + tmp.arr.indirect = NIR_SRC_INIT; + tail->child = + + length = glsl_get_length(tail->type); + for (unsigned i = 0; i < length; i++) { + tmp.arr.base_offset = i; + if (!deref_foreach_leaf_build_recur(deref, , cb, state)) +return false; + } + return true; + + case GLSL_TYPE_STRUCT: + tmp.str.deref.deref_type = nir_deref_type_struct; + tmp.str.deref.child = NULL; + tail->child = + + length = glsl_get_length(tail->type); + for (unsigned i = 0; i < length; i++) { + tmp.str.deref.type = glsl_get_struct_field(tail->type, i); + tmp.str.index = i; + if (!deref_foreach_leaf_build_recur(deref, , cb, state)) +return false; + } + return true; + + default: + return cb(deref, state); + } +} + +/* This is the first step of the foreach_leaf recursion. In this step we are + * walking to the end of the deref chain and making a copy in the stack as we + * go. This is because we don't want to mutate the deref chain that was + * passed in by the caller. The downside is that this deref chain is on the + * stack and , if the caller wants to do anything with it, they will have to + * make their own copy because this one will go away. + */ +static bool +deref_foreach_leaf_copy_recur(nir_deref_var *deref, nir_deref *tail, + nir_deref_foreach_leaf_cb cb, void *state) +{ + union { + nir_deref_array arr; + nir_deref_struct str; + } c; + + if (tail->child) { + switch (tail->child->deref_type) { + case nir_deref_type_array: + c.arr = *nir_deref_as_array(tail->child); + tail->child = + return deref_foreach_leaf_copy_recur(deref, , cb, state); + + case nir_deref_type_struct: + c.str = *nir_deref_as_struct(tail->child); + tail->child = + return deref_foreach_leaf_copy_recur(deref, , cb, state); + + case nir_deref_type_var: + default: + unreachable("Invalid deref type for a child"); + } + } else { + /* We've gotten to the end of the original deref. Time to start + * building our own derefs. + */ + return deref_foreach_leaf_build_recur(deref, tail, cb, state); + } +} + +/** + * This function iterates over all of the possible derefs that can be created + * with the given deref as the head. It then calls the provided callback with + * a full deref for each one. + * + * The deref passed to the callback will be allocated on the stack. You will + * need to make a copy if you want it to hang around. + */ +bool +nir_deref_foreach_leaf(nir_deref_var *deref, + nir_deref_foreach_leaf_cb cb, void *state) +{ + nir_deref_var copy = *deref; + return deref_foreach_leaf_copy_recur(, , cb, state); +} + /* Returns a load_const instruction that represents the constant * initializer for the given deref chain. The caller is responsible for * ensuring that there actually is a constant initializer. diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h index a7921ee..79716b1 100644 --- a/src/compiler/nir/nir.h +++ b/src/compiler/nir/nir.h @@ -1929,6 +1929,10 @@ nir_deref_struct *nir_deref_struct_create(void *mem_ctx, unsigned field_index); nir_deref *nir_copy_deref(void *mem_ctx, nir_deref *deref); +typedef bool (*nir_deref_foreach_leaf_cb)(nir_deref_var *deref, void *state); +bool nir_deref_foreach_leaf(nir_deref_var *deref, +nir_deref_foreach_leaf_cb cb, void *state); + nir_load_const_instr *
[Mesa-dev] [PATCH 2/2] nir/inline: Constant-initialize local variables in the callee if needed
Signed-off-by: Jason EkstrandCc: "12.0" Cc: Connor Abbott --- src/compiler/nir/nir_inline_functions.c | 41 +++-- 1 file changed, 39 insertions(+), 2 deletions(-) diff --git a/src/compiler/nir/nir_inline_functions.c b/src/compiler/nir/nir_inline_functions.c index c36748d..5e7382a 100644 --- a/src/compiler/nir/nir_inline_functions.c +++ b/src/compiler/nir/nir_inline_functions.c @@ -25,6 +25,19 @@ #include "nir_builder.h" #include "nir_control_flow.h" +static bool +deref_apply_constant_initializer(nir_deref_var *deref, void *state) +{ + struct nir_builder *b = state; + + nir_load_const_instr *initializer = + nir_deref_get_const_initializer_load(b->shader, deref); + + nir_store_deref_var(b, deref, >def, 0xf); + + return true; +} + static bool inline_function_impl(nir_function_impl *impl, struct set *inlined); static void @@ -174,11 +187,35 @@ inline_functions_block(nir_block *block, nir_builder *b, /* Add copies of all in parameters */ assert(call->num_params == callee_copy->num_params); + b->cursor = nir_before_instr(>instr); + + /* Before we insert the copy of the function, we need to lower away + * constant initializers on local variables. This is because constant + * initializers happen (effectively) at the top of the function and, + * since these are about to become locals of the calling function, + * initialization will happen at the top of the caller rather than at + * the top of the callee. This isn't usually a problem, but if we are + * being inlined inside of a loop, it can result in the variable not + * getting re-initizlied properly for all loop iterations. + */ + nir_foreach_variable(local, _copy->locals) { + if (!local->constant_initializer) +continue; + + nir_deref_var deref; + deref.deref.deref_type = nir_deref_type_var, + deref.deref.child = NULL; + deref.deref.type = local->type, + deref.var = local; + + nir_deref_foreach_leaf(, deref_apply_constant_initializer, b); + + local->constant_initializer = NULL; + } + exec_list_append(>impl->locals, _copy->locals); exec_list_append(>impl->registers, _copy->registers); - b->cursor = nir_before_instr(>instr); - /* We now need to tie the two functions together using the * parameters. There are two ways we do this: One is to turn the * parameter into a local variable and do a shadow-copy. The other -- 2.5.0.400.gff86faf ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode
Hi Andy, The memory issue is fixed. Please try the new patch set I just submitted. Should NOT have hard lock anymore. And thanks for providing the rate control info, I will do some test about it. Regards, Boyuan -Original Message- From: Andy Furniss [mailto:adf.li...@gmail.com] Sent: July-15-16 1:32 PM To: Zhang, Boyuan; Christian König; mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode Zhang, Boyuan wrote: > Hi Andy, > > Thanks for the testing. I will look into the memory issue. For the cbr > test, what was the bitrate you set? And by saying testing high rates, > how high was the rate approximately? Testing more shows that I get the same size file independent of framerate. An example inputting rawvideo and asking gstreamer for 30mbit with 500 frames 2560x1440 for both 25fps and 50fps produces 60M byte files for both. omx doesn't have this issue, for 30mbit the files produced are 53M and 26M. Also noted that omx takes 3.8 seconds and vaapi 13.8 for the same input. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/11] st/va: add preset values for VAAPI encode
Add some hardcoded values hardware needs mainly for rate control purpose. With previously hardcoded values for OMX, the rate control result is not correct. This change fixed the rate control result by setting correct values for Vaapi. Signed-off-by: Boyuan Zhang--- src/gallium/state_trackers/va/picture.c | 36 + 1 file changed, 36 insertions(+) diff --git a/src/gallium/state_trackers/va/picture.c b/src/gallium/state_trackers/va/picture.c index c244619..275250f 100644 --- a/src/gallium/state_trackers/va/picture.c +++ b/src/gallium/state_trackers/va/picture.c @@ -95,6 +95,41 @@ vlVaGetReferenceFrame(vlVaDriver *drv, VASurfaceID surface_id, *ref_frame = NULL; } +static void +getEncParamPreset(vlVaContext *context) +{ + //motion estimation preset + context->desc.h264enc.motion_est.motion_est_quarter_pixel = 0x0001; + context->desc.h264enc.motion_est.lsmvert = 0x0002; + context->desc.h264enc.motion_est.enc_disable_sub_mode = 0x0078; + context->desc.h264enc.motion_est.enc_en_ime_overw_dis_subm = 0x0001; + context->desc.h264enc.motion_est.enc_ime_overw_dis_subm_no = 0x0001; + context->desc.h264enc.motion_est.enc_ime2_search_range_x = 0x0004; + context->desc.h264enc.motion_est.enc_ime2_search_range_y = 0x0004; + + //pic control preset + context->desc.h264enc.pic_ctrl.enc_cabac_enable = 0x0001; + context->desc.h264enc.pic_ctrl.enc_constraint_set_flags = 0x0040; + + //rate control + context->desc.h264enc.rate_ctrl.vbv_buffer_size = 2000; + if (context->desc.h264enc.rate_ctrl.frame_rate_num == 0) { + context->desc.h264enc.rate_ctrl.frame_rate_num = 30; + context->desc.h264enc.rate_ctrl.frame_rate_den = 1; + } + context->desc.h264enc.rate_ctrl.vbv_buf_lv = 48; + context->desc.h264enc.rate_ctrl.fill_data_enable = 1; + context->desc.h264enc.rate_ctrl.enforce_hrd = 1; + context->desc.h264enc.enable_vui = false; + context->desc.h264enc.rate_ctrl.target_bits_picture = + context->desc.h264enc.rate_ctrl.target_bitrate / context->desc.h264enc.rate_ctrl.frame_rate_num; + context->desc.h264enc.rate_ctrl.peak_bits_picture_integer = + context->desc.h264enc.rate_ctrl.peak_bitrate / context->desc.h264enc.rate_ctrl.frame_rate_num; + context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0; + + context->desc.h264enc.ref_pic_mode = 0x0201; +} + static VAStatus handlePictureParameterBuffer(vlVaDriver *drv, vlVaContext *context, vlVaBuffer *buf) { @@ -514,6 +549,7 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id) if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) { coded_buf = context->coded_buf; + getEncParamPreset(context); context->decoder->begin_frame(context->decoder, context->target, >desc.base); context->decoder->encode_bitstream(context->decoder, context->target, coded_buf->derived_surface.resource, ); -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/11] st/va: get rate control method from configattrib
Rate control method is passed from app to driver through config attrib list. That is why we need to store this rate control method to config. And later on, we will pass this value to context->desc.h264enc.rate_ctrl.rate_ctrl_method. Signed-off-by: Boyuan Zhang--- src/gallium/state_trackers/va/config.c | 11 +++ src/gallium/state_trackers/va/context.c| 3 ++- src/gallium/state_trackers/va/va_private.h | 1 + 3 files changed, 14 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/va/config.c b/src/gallium/state_trackers/va/config.c index 73704a1..ea838c0 100644 --- a/src/gallium/state_trackers/va/config.c +++ b/src/gallium/state_trackers/va/config.c @@ -172,6 +172,17 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin config->profile = p; + for (int i = 0; i rc = PIPE_H264_ENC_RATE_CONTROL_METHOD_CONSTANT; + else if (attrib_list[i].value == VA_RC_VBR) +config->rc = PIPE_H264_ENC_RATE_CONTROL_METHOD_VARIABLE; + else +config->rc = PIPE_H264_ENC_RATE_CONTROL_METHOD_DISABLE; + } + } + *config_id = handle_table_add(drv->htab, config); return VA_STATUS_SUCCESS; diff --git a/src/gallium/state_trackers/va/context.c b/src/gallium/state_trackers/va/context.c index b4334f4..c67ed1f 100644 --- a/src/gallium/state_trackers/va/context.c +++ b/src/gallium/state_trackers/va/context.c @@ -274,7 +274,8 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID config_id, int picture_width, context->desc.base.profile = config->profile; context->desc.base.entry_point = config->entrypoint; - + if (config->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) + context->desc.h264enc.rate_ctrl.rate_ctrl_method = config->rc; pipe_mutex_lock(drv->mutex); *context_id = handle_table_add(drv->htab, context); pipe_mutex_unlock(drv->mutex); diff --git a/src/gallium/state_trackers/va/va_private.h b/src/gallium/state_trackers/va/va_private.h index 723983d..ad9010a 100644 --- a/src/gallium/state_trackers/va/va_private.h +++ b/src/gallium/state_trackers/va/va_private.h @@ -246,6 +246,7 @@ typedef struct { typedef struct { VAEntrypoint entrypoint; enum pipe_video_profile profile; + enum pipe_h264_enc_rate_control_method rc; } vlVaConfig; typedef struct { -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/11] st/va: enable h264 VAAPI encode
Enable H.264 VAAPI encoding through config. Currently only H.264 baseline is supported. Signed-off-by: Boyuan Zhang--- src/gallium/state_trackers/va/config.c | 32 ++-- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/src/gallium/state_trackers/va/config.c b/src/gallium/state_trackers/va/config.c index ea838c0..04d214d 100644 --- a/src/gallium/state_trackers/va/config.c +++ b/src/gallium/state_trackers/va/config.c @@ -74,6 +74,7 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx, VAProfile profile, { struct pipe_screen *pscreen; enum pipe_video_profile p; + int va_status = VA_STATUS_ERROR_UNSUPPORTED_PROFILE; if (!ctx) return VA_STATUS_ERROR_INVALID_CONTEXT; @@ -90,12 +91,18 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx, VAProfile profile, return VA_STATUS_ERROR_UNSUPPORTED_PROFILE; pscreen = VL_VA_PSCREEN(ctx); - if (!pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_SUPPORTED)) - return VA_STATUS_ERROR_UNSUPPORTED_PROFILE; - - entrypoint_list[(*num_entrypoints)++] = VAEntrypointVLD; + if (pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_SUPPORTED)) { + entrypoint_list[(*num_entrypoints)++] = VAEntrypointVLD; + va_status = VA_STATUS_SUCCESS; + } + if (pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_ENCODE, PIPE_VIDEO_CAP_SUPPORTED) && + p == PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) { + entrypoint_list[(*num_entrypoints)++] = VAEntrypointEncSlice; + entrypoint_list[(*num_entrypoints)++] = VAEntrypointEncPicture; + va_status = VA_STATUS_SUCCESS; + } - return VA_STATUS_SUCCESS; + return va_status; } VAStatus @@ -114,7 +121,7 @@ vlVaGetConfigAttributes(VADriverContextP ctx, VAProfile profile, VAEntrypoint en value = VA_RT_FORMAT_YUV420; break; case VAConfigAttribRateControl: - value = VA_RC_NONE; + value = VA_RC_CQP | VA_RC_CBR; break; default: value = VA_ATTRIB_NOT_SUPPORTED; @@ -159,10 +166,15 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin return VA_STATUS_ERROR_UNSUPPORTED_PROFILE; pscreen = VL_VA_PSCREEN(ctx); - if (!pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_SUPPORTED)) - return VA_STATUS_ERROR_UNSUPPORTED_PROFILE; - - if (entrypoint != VAEntrypointVLD) + if (entrypoint == VAEntrypointVLD) { + if (!pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_SUPPORTED)) + return VA_STATUS_ERROR_UNSUPPORTED_PROFILE; + } + else if (entrypoint == VAEntrypointEncSlice) { + if (!pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_ENCODE, PIPE_VIDEO_CAP_SUPPORTED)) + return VA_STATUS_ERROR_UNSUPPORTED_PROFILE; + } + else return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT; if (entrypoint == VAEntrypointEncSlice || entrypoint == VAEntrypointEncPicture) -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/11] st/va: add functions for VAAPI encode
Add necessary functions/changes for VAAPI encoding to buffer and picture. These changes will allow driver to handle all Vaapi encode related operations. This patch doesn't change the Vaapi decode behaviour. Signed-off-by: Boyuan Zhang--- src/gallium/state_trackers/va/buffer.c | 6 ++ src/gallium/state_trackers/va/picture.c| 162 - src/gallium/state_trackers/va/va_private.h | 3 + 3 files changed, 169 insertions(+), 2 deletions(-) diff --git a/src/gallium/state_trackers/va/buffer.c b/src/gallium/state_trackers/va/buffer.c index 7d3167b..dfcebbe 100644 --- a/src/gallium/state_trackers/va/buffer.c +++ b/src/gallium/state_trackers/va/buffer.c @@ -133,6 +133,12 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void **pbuff) if (!buf->derived_surface.transfer || !*pbuff) return VA_STATUS_ERROR_INVALID_BUFFER; + if (buf->type == VAEncCodedBufferType) { + ((VACodedBufferSegment*)buf->data)->buf = *pbuff; + ((VACodedBufferSegment*)buf->data)->size = buf->coded_size; + ((VACodedBufferSegment*)buf->data)->next = NULL; + *pbuff = buf->data; + } } else { pipe_mutex_unlock(drv->mutex); *pbuff = buf->data; diff --git a/src/gallium/state_trackers/va/picture.c b/src/gallium/state_trackers/va/picture.c index 89ac024..c244619 100644 --- a/src/gallium/state_trackers/va/picture.c +++ b/src/gallium/state_trackers/va/picture.c @@ -78,7 +78,8 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID context_id, VASurfaceID rende return VA_STATUS_SUCCESS; } - context->decoder->begin_frame(context->decoder, context->target, >desc.base); + if (context->decoder->entrypoint != PIPE_VIDEO_ENTRYPOINT_ENCODE) + context->decoder->begin_frame(context->decoder, context->target, >desc.base); return VA_STATUS_SUCCESS; } @@ -278,6 +279,132 @@ handleVASliceDataBufferType(vlVaContext *context, vlVaBuffer *buf) num_buffers, (const void * const*)buffers, sizes); } +static VAStatus +handleVAEncMiscParameterTypeRateControl(vlVaContext *context, VAEncMiscParameterBuffer *misc) +{ + VAEncMiscParameterRateControl *rc = (VAEncMiscParameterRateControl *)misc->data; + if (context->desc.h264enc.rate_ctrl.rate_ctrl_method == + PIPE_H264_ENC_RATE_CONTROL_METHOD_CONSTANT) + context->desc.h264enc.rate_ctrl.target_bitrate = rc->bits_per_second; + else + context->desc.h264enc.rate_ctrl.target_bitrate = rc->bits_per_second * rc->target_percentage; + context->desc.h264enc.rate_ctrl.peak_bitrate = rc->bits_per_second; + if (context->desc.h264enc.rate_ctrl.target_bitrate < 200) + context->desc.h264enc.rate_ctrl.vbv_buffer_size = MIN2((context->desc.h264enc.rate_ctrl.target_bitrate * 2.75), 200); + else + context->desc.h264enc.rate_ctrl.vbv_buffer_size = context->desc.h264enc.rate_ctrl.target_bitrate; + + return VA_STATUS_SUCCESS; +} + +static VAStatus +handleVAEncSequenceParameterBufferType(vlVaDriver *drv, vlVaContext *context, vlVaBuffer *buf) +{ + VAEncSequenceParameterBufferH264 *h264 = (VAEncSequenceParameterBufferH264 *)buf->data; + if (!context->decoder) { + context->templat.max_references = h264->max_num_ref_frames; + context->templat.level = h264->level_idc; + context->decoder = drv->pipe->create_video_codec(drv->pipe, >templat); + if (!context->decoder) + return VA_STATUS_ERROR_ALLOCATION_FAILED; + } + context->desc.h264enc.gop_size = h264->intra_idr_period; + return VA_STATUS_SUCCESS; +} + +static VAStatus +handleVAEncMiscParameterBufferType(vlVaContext *context, vlVaBuffer *buf) +{ + VAStatus vaStatus = VA_STATUS_SUCCESS; + VAEncMiscParameterBuffer *misc; + misc = buf->data; + + switch (misc->type) { + case VAEncMiscParameterTypeRateControl: + vaStatus = handleVAEncMiscParameterTypeRateControl(context, misc); + break; + + default: + break; + } + + return vaStatus; +} + +static VAStatus +handleVAEncPictureParameterBufferType(vlVaDriver *drv, vlVaContext *context, vlVaBuffer *buf) +{ + VAEncPictureParameterBufferH264 *h264; + vlVaBuffer *coded_buf; + + h264 = buf->data; + context->desc.h264enc.frame_num = h264->frame_num; + context->desc.h264enc.not_referenced = false; + context->desc.h264enc.is_idr = (h264->pic_fields.bits.idr_pic_flag == 1); + context->desc.h264enc.pic_order_cnt = h264->CurrPic.TopFieldOrderCnt / 2; + if (context->desc.h264enc.is_idr) + context->desc.h264enc.i_remain = 1; + else + context->desc.h264enc.i_remain = 0; + + context->desc.h264enc.p_remain = context->desc.h264enc.gop_size - context->desc.h264enc.gop_cnt - context->desc.h264enc.i_remain; + + coded_buf = handle_table_get(drv->htab, h264->coded_buf); + if (!coded_buf->derived_surface.resource) + coded_buf->derived_surface.resource = pipe_buffer_create(drv->pipe->screen, PIPE_BIND_VERTEX_BUFFER, +
[Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface
Add function to copy from yv12 image to nv12 surface for VAAPI putimage call. We need this function in VaPutImage call where copying from yv12 image to nv12 surface for encoding. Existing function can't be used because it only work for copying from yv12 surface to nv12 image in Vaapi. Signed-off-by: Boyuan Zhang--- src/gallium/auxiliary/util/u_video.h | 23 +++ 1 file changed, 23 insertions(+) diff --git a/src/gallium/auxiliary/util/u_video.h b/src/gallium/auxiliary/util/u_video.h index 9196afc..d147295 100644 --- a/src/gallium/auxiliary/util/u_video.h +++ b/src/gallium/auxiliary/util/u_video.h @@ -130,6 +130,29 @@ u_copy_yv12_to_nv12(void *const *destination_data, } static inline void +u_copy_yv12_img_to_nv12_surf(uint8_t *const *src, + uint8_t *dest, + int *offset, + int field) +{ + if (field == 0) { + for (int i = 0; i < offset[1] ; i++) + dest[i] = src[field][i]; + } else if (field == 1) { + bool odd = false; + for (int i = 0; i < (offset[1]/2) ; i++){ + if (odd == false) { +dest[i] = src[field][i/2]; +odd = true; + } else { +dest[i] = src[field+1][i/2]; +odd = false; + } + } + } +} + +static inline void u_copy_swap422_packed(void *const *destination_data, uint32_t const *destination_pitches, int src_plane, int src_field, -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/11] st/va: add encode entrypoint
VAAPI passes PIPE_VIDEO_ENTRYPOINT_ENCODE as entry point for encoding case. We will save this encode entry point in config. config_id was used as profile previously. Now, config has both profile and entrypoint field, and config_id is used to get the config object. Later on, we pass this entrypoint to context->templat.entrypoint instead of always hardcoded to PIPE_VIDEO_ENTRYPOINT_BITSTREAM for decoding case previously. Signed-off-by: Boyuan Zhang--- src/gallium/state_trackers/va/config.c | 61 +++--- src/gallium/state_trackers/va/context.c| 57 src/gallium/state_trackers/va/surface.c| 12 -- src/gallium/state_trackers/va/va_private.h | 5 +++ 4 files changed, 103 insertions(+), 32 deletions(-) diff --git a/src/gallium/state_trackers/va/config.c b/src/gallium/state_trackers/va/config.c index 9ca0aa8..73704a1 100644 --- a/src/gallium/state_trackers/va/config.c +++ b/src/gallium/state_trackers/va/config.c @@ -34,6 +34,8 @@ #include "va_private.h" +#include "util/u_handle_table.h" + DEBUG_GET_ONCE_BOOL_OPTION(mpeg4, "VAAPI_MPEG4_ENABLED", false) VAStatus @@ -128,14 +130,27 @@ VAStatus vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoint, VAConfigAttrib *attrib_list, int num_attribs, VAConfigID *config_id) { + vlVaDriver *drv; + vlVaConfig *config; struct pipe_screen *pscreen; enum pipe_video_profile p; if (!ctx) return VA_STATUS_ERROR_INVALID_CONTEXT; + drv = VL_VA_DRIVER(ctx); + + if (!drv) + return VA_STATUS_ERROR_INVALID_CONTEXT; + + config = CALLOC(1, sizeof(vlVaConfig)); + if (!config) + return VA_STATUS_ERROR_ALLOCATION_FAILED; + if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) { - *config_id = PIPE_VIDEO_PROFILE_UNKNOWN; + config->entrypoint = VAEntrypointVideoProc; + config->profile = PIPE_VIDEO_PROFILE_UNKNOWN; + *config_id = handle_table_add(drv->htab, config); return VA_STATUS_SUCCESS; } @@ -150,7 +165,14 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin if (entrypoint != VAEntrypointVLD) return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT; - *config_id = p; + if (entrypoint == VAEntrypointEncSlice || entrypoint == VAEntrypointEncPicture) + config->entrypoint = PIPE_VIDEO_ENTRYPOINT_ENCODE; + else + config->entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM; + + config->profile = p; + + *config_id = handle_table_add(drv->htab, config); return VA_STATUS_SUCCESS; } @@ -158,9 +180,25 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin VAStatus vlVaDestroyConfig(VADriverContextP ctx, VAConfigID config_id) { + vlVaDriver *drv; + vlVaConfig *config; + if (!ctx) return VA_STATUS_ERROR_INVALID_CONTEXT; + drv = VL_VA_DRIVER(ctx); + + if (!drv) + return VA_STATUS_ERROR_INVALID_CONTEXT; + + config = handle_table_get(drv->htab, config_id); + + if (!config) + return VA_STATUS_ERROR_INVALID_CONFIG; + + FREE(config); + handle_table_remove(drv->htab, config_id); + return VA_STATUS_SUCCESS; } @@ -168,18 +206,31 @@ VAStatus vlVaQueryConfigAttributes(VADriverContextP ctx, VAConfigID config_id, VAProfile *profile, VAEntrypoint *entrypoint, VAConfigAttrib *attrib_list, int *num_attribs) { + vlVaDriver *drv; + vlVaConfig *config; + if (!ctx) return VA_STATUS_ERROR_INVALID_CONTEXT; - *profile = PipeToProfile(config_id); + drv = VL_VA_DRIVER(ctx); + + if (!drv) + return VA_STATUS_ERROR_INVALID_CONTEXT; + + config = handle_table_get(drv->htab, config_id); + + if (!config) + return VA_STATUS_ERROR_INVALID_CONFIG; + + *profile = PipeToProfile(config->profile); - if (config_id == PIPE_VIDEO_PROFILE_UNKNOWN) { + if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) { *entrypoint = VAEntrypointVideoProc; *num_attribs = 0; return VA_STATUS_SUCCESS; } - *entrypoint = VAEntrypointVLD; + *entrypoint = config->entrypoint; *num_attribs = 1; attrib_list[0].type = VAConfigAttribRTFormat; diff --git a/src/gallium/state_trackers/va/context.c b/src/gallium/state_trackers/va/context.c index 402fbb2..b4334f4 100644 --- a/src/gallium/state_trackers/va/context.c +++ b/src/gallium/state_trackers/va/context.c @@ -195,18 +195,21 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID config_id, int picture_width, { vlVaDriver *drv; vlVaContext *context; + vlVaConfig *config; int is_vpp; if (!ctx) return VA_STATUS_ERROR_INVALID_CONTEXT; - is_vpp = config_id == PIPE_VIDEO_PROFILE_UNKNOWN && !picture_width && + drv = VL_VA_DRIVER(ctx); + config = handle_table_get(drv->htab, config_id); + + is_vpp = config->profile == PIPE_VIDEO_PROFILE_UNKNOWN && !picture_width && !picture_height &&
[Mesa-dev] [PATCH 07/11] st/va: add conversion for yv12 to nv12in putimage
For putimage call, if image format is yv12 (or IYUV with U V field swap) and surface format is nv12, then we need to convert yv12 to nv12 and then copy the converted data from image to surface. We can't use the existing logic where surface is destroyed and re-created with yv12 format. Signed-off-by: Boyuan Zhang--- src/gallium/state_trackers/va/image.c | 33 ++--- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/src/gallium/state_trackers/va/image.c b/src/gallium/state_trackers/va/image.c index 1b956e3..47895ee 100644 --- a/src/gallium/state_trackers/va/image.c +++ b/src/gallium/state_trackers/va/image.c @@ -471,7 +471,9 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, VAImageID image, return VA_STATUS_ERROR_OPERATION_FAILED; } - if (format != surf->buffer->buffer_format) { + if ((format != surf->buffer->buffer_format) && + ((format != PIPE_FORMAT_YV12) || (surf->buffer->buffer_format != PIPE_FORMAT_NV12)) && + ((format != PIPE_FORMAT_IYUV) || (surf->buffer->buffer_format != PIPE_FORMAT_NV12))) { struct pipe_video_buffer *tmp_buf; struct pipe_video_buffer templat = surf->templat; @@ -513,12 +515,29 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, VAImageID image, unsigned width, height; if (!views[i]) continue; vlVaVideoSurfaceSize(surf, i, , ); - for (j = 0; j < views[i]->texture->array_size; ++j) { - struct pipe_box dst_box = {0, 0, j, width, height, 1}; - drv->pipe->transfer_inline_write(drv->pipe, views[i]->texture, 0, -PIPE_TRANSFER_WRITE, _box, -data[i] + pitches[i] * j, -pitches[i] * views[i]->texture->array_size, 0); + if ((format == PIPE_FORMAT_YV12) || (format == PIPE_FORMAT_IYUV) && +(surf->buffer->buffer_format == PIPE_FORMAT_NV12)) { + struct pipe_transfer *transfer = NULL; + uint8_t *map = NULL; + struct pipe_box dst_box_1 = {0, 0, 0, width, height, 1}; + map = drv->pipe->transfer_map(drv->pipe, + views[i]->texture, + 0, + PIPE_TRANSFER_DISCARD_RANGE, + _box_1, ); + if (map == NULL) +return VA_STATUS_ERROR_OPERATION_FAILED; + + u_copy_yv12_img_to_nv12_surf (data, map, vaimage->offsets, i); + pipe_transfer_unmap(drv->pipe, transfer); + } else { + for (j = 0; j < views[i]->texture->array_size; ++j) { +struct pipe_box dst_box = {0, 0, j, width, height, 1}; +drv->pipe->transfer_inline_write(drv->pipe, views[i]->texture, 0, + PIPE_TRANSFER_WRITE, _box, + data[i] + pitches[i] * j, + pitches[i] * views[i]->texture->array_size, 0); + } } } pipe_mutex_unlock(drv->mutex); -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/11] vl: add entry point
Add entrypoint to distinguish H.264 decode and encode. For example, in patch 5/11 when is calling "VaCreateContext", "pps" and "sps" shouldn't be allocated for H.264 encoding. So we need to use the entry_point to determine this is H.264 decode or H.264 encode. We can use config to determine the entrypoint since config_id is passed to us for VaCreateContext call. However, for VaDestoyContext call, only context_id is passed to us. So we need to know the entrypoint in order to not free the pps/sps for encoding case. Signed-off-by: Boyuan Zhang--- src/gallium/include/pipe/p_video_state.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/include/pipe/p_video_state.h b/src/gallium/include/pipe/p_video_state.h index 754d013..39b3905 100644 --- a/src/gallium/include/pipe/p_video_state.h +++ b/src/gallium/include/pipe/p_video_state.h @@ -131,6 +131,7 @@ enum pipe_h264_enc_rate_control_method struct pipe_picture_desc { enum pipe_video_profile profile; + enum pipe_video_entrypoint entry_point; }; struct pipe_quant_matrix -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/sw/kms: Fix multiple imports from PRIME FDs
On 15 July 2016 at 08:27, Tomasz Figawrote: > When a buffer with a GEM handle already existing in our context is > (re-)imported from a PRIME FD, the resulting GEM handle is exactly the > same as the original one. Since the GEM handles are not reference > counted, we need to detect duplicate imports and reference count our > internal buffer structs ourselves. > > Signed-off-by: Tomasz Figa > --- > src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 30 > +-- > 1 file changed, 22 insertions(+), 8 deletions(-) > > 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 21ac0d7..c4f56cb 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 > @@ -211,7 +211,9 @@ kms_sw_displaytarget_map(struct sw_winsys *ws, > } > > static struct kms_sw_displaytarget * > -kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd) > +kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd, > +unsigned width, unsigned height, > +unsigned stride) > { > uint32_t handle = -1; > struct kms_sw_displaytarget * kms_sw_dt; > @@ -222,6 +224,17 @@ kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys > *kms_sw, int fd) > if (ret) >return NULL; > > + LIST_FOR_EACH_ENTRY(kms_sw_dt, _sw->bo_list, link) { > + if (kms_sw_dt->handle == handle) { > + kms_sw_dt->ref_count++; > + > + DEBUG_PRINT("KMS-DEBUG: imported buffer %u (size %u)\n", > + kms_sw_dt->handle, kms_sw_dt->size); > + > + return kms_sw_dt; > + } > + } > + > kms_sw_dt = CALLOC_STRUCT(kms_sw_displaytarget); > if (!kms_sw_dt) >return NULL; > @@ -229,6 +242,9 @@ kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys > *kms_sw, int fd) > kms_sw_dt->ref_count = 1; > kms_sw_dt->handle = handle; > kms_sw_dt->size = lseek(fd, 0, SEEK_END); > + kms_sw_dt->width = width; > + kms_sw_dt->height = height; > + kms_sw_dt->stride = stride; > > if (kms_sw_dt->size == (off_t)-1) { >FREE(kms_sw_dt); > @@ -274,14 +290,12 @@ kms_sw_displaytarget_from_handle(struct sw_winsys *ws, > > 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; > + kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw, > whandle->handle, > + templ->width0, > + templ->height0, > + whandle->stride); > + if (kms_sw_dt) > *stride = kms_sw_dt->stride; > - } So there's actually a couple of things here: - kms_sw_displaytarget_add_from_prime now takes a width, height, stride. not a bugfix but very nice imho. - DRM_API_HANDLE_TYPE_FD were ref_counted twice upon creation - once in kms_sw_displaytarget_add_from_prime, and a second time immediatelly after. - one should have checked the bo_list prior to importing the BO as prime FD. Can we split the former (2/2) and get the other two (1/2) with CC: mesa-stable... ? Ideally we would have just a single "LIST_FOR_EACH_ENTRY(..._sw->bo_list...)" block in kms_sw_displaytarget_from_handle and none in kms_sw_displaytarget_add_from_prime. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 24/34] i965/gen8: Use the generic ISL-based path for texture surfaces
On Wed 13 Jul 2016, Jason Ekstrand wrote: > Reviewed-by: Topi Pohjolainen> --- Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 19/34] i965/state: Add a helper for emitting a surface state using isl
On Thu 14 Jul 2016, Chad Versace wrote: > On Wed 13 Jul 2016, Jason Ekstrand wrote: > > Reviewed-by: Topi Pohjolainen> > --- > > src/mesa/drivers/dri/i965/brw_state.h| 8 +++ > > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 79 > > > > 2 files changed, 87 insertions(+) > > > > diff --git a/src/mesa/drivers/dri/i965/brw_state.h > > b/src/mesa/drivers/dri/i965/brw_state.h > > index a16e876..91ebce9 100644 > > --- a/src/mesa/drivers/dri/i965/brw_state.h > > +++ b/src/mesa/drivers/dri/i965/brw_state.h > > @@ -274,6 +274,14 @@ GLuint translate_tex_format(struct brw_context *brw, > > int brw_get_texture_swizzle(const struct gl_context *ctx, > > const struct gl_texture_object *t); > > > > Move the forward declaration below to the top of the header. As written, > it looks like the function's return type. > > +struct isl_view; > > +void brw_emit_surface_state(struct brw_context *brw, > > +struct intel_mipmap_tree *mt, > > +const struct isl_view *view, > > +uint32_t mocs, bool for_gather, > > +uint32_t *surf_offset, int surf_index, > > +unsigned read_domains, unsigned write_domains); Ping! Unresolved issue^^^ Fix that, and this patch is Reviewed-by: Chad Versace But keep reading... > > + if (aux_surf) { > > + /* On gen7 and prior, the bottom 12 bits of the MCS base address are > > + * used to store other information. This should be ok, however, > > because > > + * surface buffer addresses are always 4K page alinged. > > + */ > > Could you please insert the original comment from gen7_wm_surface_state? > Because... > > > + assert((aux_offset & 0xfff) == 0); > > + drm_intel_bo_emit_reloc(brw->batch.bo, > > + *surf_offset + 4 * ss_info.aux_reloc_dw, > > + mt->mcs_mt->bo, dw[ss_info.aux_reloc_dw] & > > 0xfff, > > > > ...that ^^^ bit of code REALLY confused me until I found the original > comment. What's happening is obvious in retrospect, yet terribly obscure > without a fuller comment. I prefer you insert the original comment, or at least some more explanation. My r-b stands with or without a comment update. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] main/shaderimage: image unit invalid if texture is incomplete, independently of the level
Alejandro Piñeirowrites: > On 14/07/16 21:24, Francisco Jerez wrote: >> Alejandro Piñeiro writes: >> >>> Without this commit, a image is considered valid if the level of the >>> texture bound to the image is complete, something we can check as mesa >>> save independently if it is "base incomplete" of "mipmap incomplete". >>> >>> But, from the OpenGL 4.3 Core Specification, section 8.25 ("Texture >>> Image Loads and Stores"): >>> >>> "An access is considered invalid if: >>> the texture bound to the selected image unit is incomplete;" >>> >>> This implies that the access to the image unit is invalid if the >>> texture is incomplete, no mattering details about the specific texture >>> level bound to the image. >>> >>> This fixes: >>> GL44-CTS.shader_image_load_store.incomplete_textures >>> --- >>> >>> Current piglit test is not testing what this commit tries to fix. I >>> will send a patch to piglit in short. >>> >>> src/mesa/main/shaderimage.c | 14 +++--- >>> 1 file changed, 11 insertions(+), 3 deletions(-) >>> >>> diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c >>> index 90643c4..d20cd90 100644 >>> --- a/src/mesa/main/shaderimage.c >>> +++ b/src/mesa/main/shaderimage.c >>> @@ -469,10 +469,18 @@ _mesa_is_image_unit_valid(struct gl_context *ctx, >>> struct gl_image_unit *u) >>> if (!t->_BaseComplete && !t->_MipmapComplete) >>> _mesa_test_texobj_completeness(ctx, t); >>> >>> + /* From the OpenGL 4.3 Core Specification, Chapter 8.25, Texture Image >>> +* Loads and Stores: >>> +* >>> +* "An access is considered invalid if: >>> +*the texture bound to the selected image unit is incomplete;" >>> +*/ >>> + if (!t->_BaseComplete || >>> + !t->_MipmapComplete) >>> + return GL_FALSE; >> I don't think this is correct, AFAIUI a texture having _MipmapComplete >> equal to false doesn't imply that the texture as a whole would be >> considered incomplete according to the GL's definition of completeness. >> Whether or not it's considered complete usually depends on the sampler >> state while you're doing regular texture sampling: If the sampler a >> texture object is used with has any of the mipmap filtering modes >> enabled you need to check _MipmapComplete, otherwise you need to check >> _BaseComplete. The problem when you attempt to carry over this >> definition to shader images (as the spec implies) is that image units >> have no sampler state as such, and that they can only ever access one >> specified level of the texture at a time (potentially a texture level >> other than the base). This patch makes image units behave like a >> sampler unit with mipmap filtering enabled for the purpose of texture >> completeness validation, which is almost definitely too strong. > > Yes, I didn't realize that _BaseComplete and _MipmapComplete were not > checking the state at all. Thanks for pointing it. > >> An alternative would be to do something along the lines of: >> >> | if (!_mesa_is_texture_complete(t, >Sampler)) >> |return GL_FALSE; > > Yes, that is what I wanted, to return false if the texture is incomplete. > >> >> The problem is that you would then run into problems when some of the >> non-base mipmap levels are missing but the sampler state baked into the >> gl_texture_object says that you aren't mipmapping, so the GL spec would >> normally consider the texture to be complete and >> _mesa_is_texture_complete would return true accordingly, but still you >> wouldn't be able to use any of the missing texture levels as shader >> image if the application tried to bind them to an image unit (that's the >> reason for the u->Level vs t->BaseLevel checks below you're removing). > > Ok, then if I understand correctly, the solution is not about replacing > the level checks for _mesa_is_texture_complete, but keeping current > checks, and add a _mesa_is_texture_complete check. Just checked and > everything seems to work fine (except that now the behaviour is more > strict, see below). I will send a patch in short. > Yeah, that would likely work and get the CTS test to pass, but it would still be more strict than the spec says and consider cases that are OK according to the spec to be incomplete, so I was reluctant to call it a solution. I think the ideal solution would be for the state of an image unit to be independent from the filtering and sampling state, and depend on the completeness of the bound level *only*. Any idea if this CTS (or your equivalent piglit test) passes on other GL implementations that support image load/store (e.g. nVidia's -- I would be surprised if it does). >> Honestly I think the current definition of image unit completeness is >> broken, because it considers the image unit state to be complete in >> cases where the image unit state is unusable (because the target image >> level may be missing even though the texture object itself is considered >> complete),
Re: [Mesa-dev] [PATCH] st/nine: add missing copyright headers
Some copyrights are not correct, please look at the log of https://github.com/chrisbmr/Mesa-3D/tree/gallium-nine/src/gallium/state_trackers/nine to find out. Axel On 14/07/2016 20:17, Vedran Miletić wrote : Few files were missing the copyright headers. This patch adds correct copyright headers according to the commit author and date. Signed-off-by: Vedran Miletić--- src/gallium/state_trackers/nine/nine_dump.c | 21 + src/gallium/state_trackers/nine/nine_dump.h | 21 + src/gallium/state_trackers/nine/nine_ff.c| 21 + src/gallium/state_trackers/nine/nine_ff.h| 21 + src/gallium/state_trackers/nine/nine_flags.h | 22 +- src/gallium/state_trackers/nine/nine_pdata.h | 21 + 6 files changed, 126 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/nine/nine_dump.c b/src/gallium/state_trackers/nine/nine_dump.c index 1ca5505..28145d0 100644 --- a/src/gallium/state_trackers/nine/nine_dump.c +++ b/src/gallium/state_trackers/nine/nine_dump.c @@ -1,3 +1,24 @@ +/* + * Copyright 2011 Joakim Sindholt + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * on the rights to use, copy, modify, merge, publish, distribute, sub + * license, and/or sell copies of the Software, and to permit persons to whom + * the Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL + * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM, + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE + * USE OR OTHER DEALINGS IN THE SOFTWARE. */ #include "nine_debug.h" #include "nine_pipe.h" diff --git a/src/gallium/state_trackers/nine/nine_dump.h b/src/gallium/state_trackers/nine/nine_dump.h index a0ffe7b..2ee08bd 100644 --- a/src/gallium/state_trackers/nine/nine_dump.h +++ b/src/gallium/state_trackers/nine/nine_dump.h @@ -1,3 +1,24 @@ +/* + * Copyright 2011 Joakim Sindholt + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * on the rights to use, copy, modify, merge, publish, distribute, sub + * license, and/or sell copies of the Software, and to permit persons to whom + * the Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL + * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM, + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE + * USE OR OTHER DEALINGS IN THE SOFTWARE. */ #ifndef _NINE_DUMP_H_ #define _NINE_DUMP_H_ diff --git a/src/gallium/state_trackers/nine/nine_ff.c b/src/gallium/state_trackers/nine/nine_ff.c index 899e54e..0cd0c77 100644 --- a/src/gallium/state_trackers/nine/nine_ff.c +++ b/src/gallium/state_trackers/nine/nine_ff.c @@ -1,3 +1,24 @@ +/* + * Copyright 2011 Joakim Sindholt + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * on the rights to use, copy, modify, merge, publish, distribute, sub + * license, and/or sell copies of the Software, and to permit persons to whom + * the Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
Re: [Mesa-dev] [PATCH 4/4] mesa: handle numLevels, numSamples in _mesa_test_proxy_teximage()
On Fri, Jul 15, 2016 at 12:34 PM, Brian Paulwrote: > On 07/15/2016 01:19 PM, Anuj Phogat wrote: >> >> On Fri, Jul 15, 2016 at 10:14 AM, Brian Paul wrote: >>> >>> If numSamples > 0, we can compute the size of the whole mipmapped >>> texture. >>> That's the case for glTexStorage(GL_PROXY_TEXTURE_x). >>> >>> Also, multiply the texture size by numSamples for MSAA textures. >>> --- >>> src/mesa/main/teximage.c | 48 >>> +--- >>> 1 file changed, 45 insertions(+), 3 deletions(-) >>> >>> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c >>> index c75f605..0f13d61 100644 >>> --- a/src/mesa/main/teximage.c >>> +++ b/src/mesa/main/teximage.c >>> @@ -40,6 +40,7 @@ >>> #include "image.h" >>> #include "imports.h" >>> #include "macros.h" >>> +#include "mipmap.h" >>> #include "multisample.h" >>> #include "pixelstore.h" >>> #include "state.h" >>> @@ -1268,12 +1269,53 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, >>> GLenum target, >>> mesa_format format, GLuint numSamples, >>> GLint width, GLint height, GLint depth) >>> { >>> + uint64_t bytes, mbytes; >>> + >>> + assert(numSamples > 0); >>> + >>> + if (numLevels > 0) { >>> + /* Compute total memory for a whole mipmap. This is the path >>> + * taken for glTexStorage(GL_PROXY_TEXTURE_x). >>> + */ >>> + unsigned l; >>> + >>> + assert(level == 0); >>> + >>> + bytes = 0; >>> + >>> + for (l = 0; l < numLevels; l++) { >>> + GLint nextWidth, nextHeight, nextDepth; >>> + >>> + /* XXX this doesn't yet account for multisampling */ >>> + bytes += _mesa_format_image_size64(format, width, height, >>> depth); >>> + >>> + if (_mesa_next_mipmap_level_size(target, 0, width, height, >>> depth, >>> + , , >>> + )) { >>> +width = nextWidth; >>> +height = nextHeight; >>> +depth = nextDepth; >>> + } >>> + else { >>> +break; >>> + } >>> + } >>> + } >>> + else { >> >> nitpick. Use } else { >> >>> + /* We just compute the size of one mipmap level. This is the path >>> + * taken for glTexImage(GL_PROXY_TEXTURE_x). >>> + */ >>> + bytes = _mesa_format_image_size64(format, width, height, depth); >> >> Don't we need to multiply bytes by _mesa_num_tex_faces() here too? > > > Uh, that's done a few lines below. > Right. I can now see it's a common code. Sorry for the noise. >>> + } >>> + >>> + bytes *= _mesa_num_tex_faces(target); >>> + bytes *= numSamples; >>> + >>> + mbytes = bytes / (1024 * 1024); /* convert to MB */ >>> + >>> /* We just check if the image size is less than MaxTextureMbytes. >>> * Some drivers may do more specific checks. >>> */ >>> - uint64_t bytes = _mesa_format_image_size64(format, width, height, >>> depth); >>> - uint64_t mbytes = bytes / (1024 * 1024); /* convert to MB */ >>> - mbytes *= _mesa_num_tex_faces(target); >>> return mbytes <= (uint64_t) ctx->Const.MaxTextureMbytes; >>> } >>> >>> -- >>> 1.9.1 >>> >>> ___ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8=Chw7SvWUSVQKjs40uL5HS7a3CnCLscN8vvbeFek5DJ8=OMMsCQ7_rpU1xc2WbqI6X64jcC4_RwtUhV_nnNtgtCE= > > Series is: Reviewed-by: Anuj Phogat ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/10] egl/android: Respect buffer mask in droid_image_get_buffers
On 15 July 2016 at 08:53, Tomasz Figawrote: > Drivers can request different set of buffers depending on the buffer > mask they pass to the get_buffers callback. This patch makes > droid_image_get_buffers() respect this mask. > > Signed-off-by: Tomasz Figa > --- > src/egl/drivers/dri2/platform_android.c | 15 +++ > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/src/egl/drivers/dri2/platform_android.c > b/src/egl/drivers/dri2/platform_android.c > index de1e5e6..7495445 100644 > --- a/src/egl/drivers/dri2/platform_android.c > +++ b/src/egl/drivers/dri2/platform_android.c > @@ -434,16 +434,23 @@ droid_image_get_buffers(__DRIdrawable *driDrawable, > { > struct dri2_egl_surface *dri2_surf = loaderPrivate; > > + images->image_mask = 0; > + > if (update_buffers(dri2_surf) < 0) >return 0; > > - if (get_back_bo(dri2_surf) < 0) { > - _eglError(EGL_BAD_PARAMETER, "get_back_bo"); > + if (buffer_mask & __DRI_IMAGE_BUFFER_FRONT) { > + _eglLog(_EGL_WARNING, "Front buffer is not supported for window > surfaces"); Not sure if using EGL_WARNING won't cause too much unnecessary "spam". Although we could tweak that at later stage, if needed. Reviewed-by: Emil Velikov Related: other platforms (platform_drm and platform_wayland) could use the same fix. I believe they all share the EGL semantics of "Thou shall not have a front buffer" -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] i915: Enable EGL_KHR_{fence, wait}_sync
2016-07-15 21:18 GMT+02:00 Emil Velikov: > Hi Mauro, > > On 14 July 2016 at 04:33, Mauro Rossi wrote: > > Sending patches to implement DRI2_Fence extension for i915, > > to enable EGL_KHR_fence_sync and EGL_KHR_wait_sync. > > > > It is the step-by-step porting to i915 of i965/sync, > > plus patch to support {server,client}_wait_sync without bound context. > > > > [PATCH 1/3] i915/sync: Replace prefix 'intel_sync' -> 'intel_gl_sync' > > [PATCH 2/3] i915/sync: Implement DRI2_Fence extension > These two are > Acked-by: Emil Velikov > > > [PATCH 3/3] i915: store reference to the context within struct > > > And this one needs a re-spin to include locking, as done my Tomasz. > I'm already doing the re-spin, I will submit v2 by step by step replication of Tomasz patch for i915. > > Motivation is to support (web)chromium which requires > EGL_KHR_{fence,wait}_sync > > Tested with marshmallow-x86 build on Asus Eee PC 1015PEM > > > Did you perform any tests as stated in the i965 "Implement DRI2_Fence > extension" patch ? Afaict the new functionality is nicely separated so > there's little chance for regressions but giving it greater testing > would be appreciated. > Tests were performed by Paulo and they consisted in checking chromium browser that was crashing without those features. I will test on intel G33 in the weekend and perform Android CTS deqp EGL and report back. > > > Spotted by Paulo Travaglia > > > > Cc: "12.0" > I'm not sold that these are stable material - they add feature and > don't fix bug(s). If anything Android could use some updates to honour > the lack of the EGL (EGL_KHR_fence_sync and EGL_KHR_wait_sync) > extensions. > Thanks, I understand your point about additional features for mesa-stable. It depends if we consider that these are step-by-step cloned from i965 ones, with the only difference that 'brw' was renamed as 'intel' as in all other similar functions in i915 Also these capabilities are independent from underlying HW, if I understood correctly > That said if the Intel devs are OK with having these in stable I won't > object too much ;-) > > Thanks > Emil > Merging in mesa-dev will be ok, If patches not accepted for mesa-stable it is not a problem, because they can be used as they are in android-x86 marshmallow-x86 branch. M. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] mesa: handle numLevels, numSamples in _mesa_test_proxy_teximage()
On 07/15/2016 01:19 PM, Anuj Phogat wrote: On Fri, Jul 15, 2016 at 10:14 AM, Brian Paulwrote: If numSamples > 0, we can compute the size of the whole mipmapped texture. That's the case for glTexStorage(GL_PROXY_TEXTURE_x). Also, multiply the texture size by numSamples for MSAA textures. --- src/mesa/main/teximage.c | 48 +--- 1 file changed, 45 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c index c75f605..0f13d61 100644 --- a/src/mesa/main/teximage.c +++ b/src/mesa/main/teximage.c @@ -40,6 +40,7 @@ #include "image.h" #include "imports.h" #include "macros.h" +#include "mipmap.h" #include "multisample.h" #include "pixelstore.h" #include "state.h" @@ -1268,12 +1269,53 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum target, mesa_format format, GLuint numSamples, GLint width, GLint height, GLint depth) { + uint64_t bytes, mbytes; + + assert(numSamples > 0); + + if (numLevels > 0) { + /* Compute total memory for a whole mipmap. This is the path + * taken for glTexStorage(GL_PROXY_TEXTURE_x). + */ + unsigned l; + + assert(level == 0); + + bytes = 0; + + for (l = 0; l < numLevels; l++) { + GLint nextWidth, nextHeight, nextDepth; + + /* XXX this doesn't yet account for multisampling */ + bytes += _mesa_format_image_size64(format, width, height, depth); + + if (_mesa_next_mipmap_level_size(target, 0, width, height, depth, + , , + )) { +width = nextWidth; +height = nextHeight; +depth = nextDepth; + } + else { +break; + } + } + } + else { nitpick. Use } else { + /* We just compute the size of one mipmap level. This is the path + * taken for glTexImage(GL_PROXY_TEXTURE_x). + */ + bytes = _mesa_format_image_size64(format, width, height, depth); Don't we need to multiply bytes by _mesa_num_tex_faces() here too? Uh, that's done a few lines below. + } + + bytes *= _mesa_num_tex_faces(target); + bytes *= numSamples; + + mbytes = bytes / (1024 * 1024); /* convert to MB */ + /* We just check if the image size is less than MaxTextureMbytes. * Some drivers may do more specific checks. */ - uint64_t bytes = _mesa_format_image_size64(format, width, height, depth); - uint64_t mbytes = bytes / (1024 * 1024); /* convert to MB */ - mbytes *= _mesa_num_tex_faces(target); return mbytes <= (uint64_t) ctx->Const.MaxTextureMbytes; } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8=Chw7SvWUSVQKjs40uL5HS7a3CnCLscN8vvbeFek5DJ8=OMMsCQ7_rpU1xc2WbqI6X64jcC4_RwtUhV_nnNtgtCE= ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] egl/android: Set EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT
On 15 July 2016 at 18:57, Tomasz Figawrote: > [Adding Haixia to the thread.] > > On Sat, Jul 16, 2016 at 2:52 AM, Eric Anholt wrote: >> Tomasz Figa writes: >> >>> From: Haixia Shi >>> >>> Set config attributes EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT to >>> hard-coded non-zero values. These two attributes are required on Android. >>> >>> Signed-off-by: Tomasz Figa >>> --- >>> src/egl/drivers/dri2/platform_android.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/src/egl/drivers/dri2/platform_android.c >>> b/src/egl/drivers/dri2/platform_android.c >>> index b33f4e8..f42febc 100644 >>> --- a/src/egl/drivers/dri2/platform_android.c >>> +++ b/src/egl/drivers/dri2/platform_android.c >>> @@ -655,6 +655,8 @@ droid_add_configs_for_visuals(_EGLDriver *drv, >>> _EGLDisplay *dpy) >>> EGL_NATIVE_VISUAL_TYPE, 0, >>> EGL_FRAMEBUFFER_TARGET_ANDROID, EGL_TRUE, >>> EGL_RECORDABLE_ANDROID, EGL_TRUE, >>> + EGL_MAX_PBUFFER_WIDTH, 4096, >>> + EGL_MAX_PBUFFER_HEIGHT, 4096, >>> EGL_NONE >> >> It seems weird to me to pick a plausible value that hardware might have, >> without actually asking the hardware for the value. Could we use some >> MAX_INT-type value to make it obvious that we're just lying and leaving >> it up to buffer creation time to error out? > > If I remember correctly, there are dEQP tests which attempt to use > pbuffers bigger and bigger until reaching the limits and checking if > they work properly. Haixia, what was the story behind hardcoding these > values? > > I suppose the proper way would be to query the driver indeed... > IIRC we had a similar case, where when requesting the EGL_LARGEST_PBUFFER we were capping to the width/height 4k in _eglInitSurface. The reason behind the hardcoded (gross?) workaround was that one cannot query the sane limits, at least from the xlib/xcb side of EGL. See commit 582ae91e3a615afdecbb8c3dc98d1397ebee1cd6 for more. Perhaps the dEQP tests should set EGL_LARGEST_PBUFFER ? Alternatively I'm wondering if we cannot have a common path for this/these workarounds ? Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] mesa: handle numLevels, numSamples in _mesa_test_proxy_teximage()
On Fri, Jul 15, 2016 at 10:14 AM, Brian Paulwrote: > If numSamples > 0, we can compute the size of the whole mipmapped texture. > That's the case for glTexStorage(GL_PROXY_TEXTURE_x). > > Also, multiply the texture size by numSamples for MSAA textures. > --- > src/mesa/main/teximage.c | 48 > +--- > 1 file changed, 45 insertions(+), 3 deletions(-) > > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c > index c75f605..0f13d61 100644 > --- a/src/mesa/main/teximage.c > +++ b/src/mesa/main/teximage.c > @@ -40,6 +40,7 @@ > #include "image.h" > #include "imports.h" > #include "macros.h" > +#include "mipmap.h" > #include "multisample.h" > #include "pixelstore.h" > #include "state.h" > @@ -1268,12 +1269,53 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, > GLenum target, >mesa_format format, GLuint numSamples, >GLint width, GLint height, GLint depth) > { > + uint64_t bytes, mbytes; > + > + assert(numSamples > 0); > + > + if (numLevels > 0) { > + /* Compute total memory for a whole mipmap. This is the path > + * taken for glTexStorage(GL_PROXY_TEXTURE_x). > + */ > + unsigned l; > + > + assert(level == 0); > + > + bytes = 0; > + > + for (l = 0; l < numLevels; l++) { > + GLint nextWidth, nextHeight, nextDepth; > + > + /* XXX this doesn't yet account for multisampling */ > + bytes += _mesa_format_image_size64(format, width, height, depth); > + > + if (_mesa_next_mipmap_level_size(target, 0, width, height, depth, > + , , > + )) { > +width = nextWidth; > +height = nextHeight; > +depth = nextDepth; > + } > + else { > +break; > + } > + } > + } > + else { nitpick. Use } else { > + /* We just compute the size of one mipmap level. This is the path > + * taken for glTexImage(GL_PROXY_TEXTURE_x). > + */ > + bytes = _mesa_format_image_size64(format, width, height, depth); Don't we need to multiply bytes by _mesa_num_tex_faces() here too? > + } > + > + bytes *= _mesa_num_tex_faces(target); > + bytes *= numSamples; > + > + mbytes = bytes / (1024 * 1024); /* convert to MB */ > + > /* We just check if the image size is less than MaxTextureMbytes. > * Some drivers may do more specific checks. > */ > - uint64_t bytes = _mesa_format_image_size64(format, width, height, depth); > - uint64_t mbytes = bytes / (1024 * 1024); /* convert to MB */ > - mbytes *= _mesa_num_tex_faces(target); > return mbytes <= (uint64_t) ctx->Const.MaxTextureMbytes; > } > > -- > 1.9.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] i915: Enable EGL_KHR_{fence, wait}_sync
Hi Mauro, On 14 July 2016 at 04:33, Mauro Rossiwrote: > Sending patches to implement DRI2_Fence extension for i915, > to enable EGL_KHR_fence_sync and EGL_KHR_wait_sync. > > It is the step-by-step porting to i915 of i965/sync, > plus patch to support {server,client}_wait_sync without bound context. > > [PATCH 1/3] i915/sync: Replace prefix 'intel_sync' -> 'intel_gl_sync' > [PATCH 2/3] i915/sync: Implement DRI2_Fence extension These two are Acked-by: Emil Velikov > [PATCH 3/3] i915: store reference to the context within struct > And this one needs a re-spin to include locking, as done my Tomasz. > Motivation is to support (web)chromium which requires > EGL_KHR_{fence,wait}_sync > Tested with marshmallow-x86 build on Asus Eee PC 1015PEM > Did you perform any tests as stated in the i965 "Implement DRI2_Fence extension" patch ? Afaict the new functionality is nicely separated so there's little chance for regressions but giving it greater testing would be appreciated. > Spotted by Paulo Travaglia > > Cc: "12.0" I'm not sold that these are stable material - they add feature and don't fix bug(s). If anything Android could use some updates to honour the lack of the EGL (EGL_KHR_fence_sync and EGL_KHR_wait_sync) extensions. That said if the Intel devs are OK with having these in stable I won't object too much ;-) Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 18/34] i965/blorp: Use the generic ISL path for texture surfaces on gen6
On Wed 13 Jul 2016, Jason Ekstrand wrote: > Reviewed-by: Topi Pohjolainen> --- > src/mesa/drivers/dri/i965/gen6_blorp.c | 76 > +- > 1 file changed, 2 insertions(+), 74 deletions(-) Patches 14-18 are Reviewed-by: Chad Versace That's the whole series, now. Did I miss anything? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 13/34] i965/blorp: Add a generic ISL-based surface state emit path
On Thu 14 Jul 2016, Jason Ekstrand wrote: > On Thu, Jul 14, 2016 at 2:26 PM, Chad Versace> wrote: > > > On Wed 13 Jul 2016, Jason Ekstrand wrote: > > > Reviewed-by: Topi Pohjolainen > > > --- > > > src/mesa/drivers/dri/i965/brw_blorp.c | 157 > > ++ > > > src/mesa/drivers/dri/i965/brw_blorp.h | 6 ++ > > > 2 files changed, 163 insertions(+) > > > + struct isl_view view = { > > > + .format = surface->brw_surfaceformat, > > > + .base_level = 0, > > > + .levels = 1, > > > + .base_array_layer = 0, > > > + .array_len = 1, > > > + .channel_select = { > > > + ISL_CHANNEL_SELECT_RED, > > > + ISL_CHANNEL_SELECT_GREEN, > > > + ISL_CHANNEL_SELECT_BLUE, > > > + ISL_CHANNEL_SELECT_ALPHA, > > > + }, > > > + .usage = is_render_target ? ISL_SURF_USAGE_RENDER_TARGET_BIT : > > > + ISL_SURF_USAGE_TEXTURE_BIT, > > > + }; > > > > Are you confident that blorp never requires ISL_SURF_USAGE_CUBE_MAP_BIT? > > > > Yes, very confident. That's only required if you're going to use a cube > sampler. Blorp has no need for cube samplers. Ok. That's what I thought too. Just wanted to confirm. > > > > > > > + > > > + uint32_t offset, tile_x, tile_y; > > > + offset = brw_blorp_compute_tile_offsets(surface, _x, _y); > > > + > > > + uint32_t surf_offset; > > > + uint32_t *dw = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, > > > + ss_info.num_dwords * 4, > > ss_info.ss_align, > > > + _offset); > > > + > > > + const uint32_t mocs = is_render_target ? ss_info.rb_mocs : > > ss_info.tex_mocs; > > > + > > > + isl_surf_fill_state(>isl_dev, dw, .surf = , .view = , > > > + .address = surface->mt->bo->offset64 + offset, > > > + .aux_surf = aux_surf, .aux_usage = aux_usage, > > > + .aux_address = aux_offset, > > > + .mocs = mocs, .clear_color = clear_color, > > > + .x_offset_sa = tile_x, .y_offset_sa = tile_y); > > > > Whoa! Where did x_offset_sa and y_offset_sa come from? It's not on > > master, and I didn't see it in any earlier patches. > > Yep, I see it now. This patch is Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 34/34] i965/context: Remove some unnecessary vfuncs
On Wed 13 Jul 2016, Jason Ekstrand wrote: > Reviewed-by: Topi Pohjolainen> --- > src/mesa/drivers/dri/i965/brw_context.h | 17 - > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 3 +-- > src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 1 - > src/mesa/drivers/dri/i965/gen8_surface_state.c| 1 - > 4 files changed, 1 insertion(+), 21 deletions(-) Reviewed-by: Chad Versace I'm done with all the non-blorp patches, I believe. Let me know if I missed anything. I'll resume at the blorp patches now. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 33/34] i965: Get rid of gen6_surface_state.c
On Wed 13 Jul 2016, Jason Ekstrand wrote: > The only useful thing left was gen6_init_vtable_surface_functions which we > can easily put in brw_wm_surface_state.c. > > Reviewed-by: Topi Pohjolainen> --- > src/mesa/drivers/dri/i965/Makefile.sources | 1 - > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 7 > src/mesa/drivers/dri/i965/gen6_surface_state.c | 48 > > 3 files changed, 7 insertions(+), 49 deletions(-) > delete mode 100644 src/mesa/drivers/dri/i965/gen6_surface_state.c Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 25/34] i965/gen8: Use the generic ISL-based path for renderbuffer surfaces
On Wed 13 Jul 2016, Jason Ekstrand wrote: > Reviewed-by: Topi Pohjolainen> --- > src/mesa/drivers/dri/i965/brw_state.h | 16 -- > src/mesa/drivers/dri/i965/gen8_surface_state.c | 249 > + > 2 files changed, 2 insertions(+), 263 deletions(-) That diff has a lot of -'s :) Bye bye code! Looks good to me, Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 29/34] i965/gen4-6: Use the generic ISL-based path for texture surfaces
On Wed 13 Jul 2016, Jason Ekstrand wrote: > Reviewed-by: Topi Pohjolainen> --- > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 94 > +--- > 1 file changed, 1 insertion(+), 93 deletions(-) Patches 28 and 29 are Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 31/34] i965/state: Account for the element size in emit_buffer_surface_state
On Wed 13 Jul 2016, Jason Ekstrand wrote: > Reviewed-by: Topi Pohjolainen> --- > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 11 ++- > src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 9 + > src/mesa/drivers/dri/i965/gen8_surface_state.c| 9 + > 3 files changed, 16 insertions(+), 13 deletions(-) Patches 30 and 31 are Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 32/34] i965: Use ISL for emitting buffer surface states
On Wed 13 Jul 2016, Jason Ekstrand wrote: > Reviewed-by: Topi Pohjolainen> --- > src/mesa/drivers/dri/i965/brw_binding_tables.c| 2 +- > src/mesa/drivers/dri/i965/brw_context.h | 8 -- > src/mesa/drivers/dri/i965/brw_state.h | 9 +++ > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 93 > +++ > src/mesa/drivers/dri/i965/gen7_cs_state.c | 2 +- > src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 47 > src/mesa/drivers/dri/i965/gen8_surface_state.c| 42 -- > 7 files changed, 55 insertions(+), 148 deletions(-) Patch 32 is Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 27/34] i965/gen7: Use the generic ISL-based path for renderbuffer surfaces
On Wed 13 Jul 2016, Jason Ekstrand wrote: > Reviewed-by: Topi Pohjolainen> --- > src/mesa/drivers/dri/i965/brw_state.h | 7 - > src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 194 > +- > 2 files changed, 1 insertion(+), 200 deletions(-) More --'s ! Patches 26 and 27 (the gen7 patches) are Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode
Andy Furniss wrote: omx doesn't have this issue, for 30mbit the files produced are 53M and 26M. Actually by default omx will make the same size files, I lucked into that behavior playing around with the control-rate param. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 23/34] i965/state: Add generic surface update functions based on ISL
On Wed 13 Jul 2016, Jason Ekstrand wrote: > Reviewed-by: Topi Pohjolainen> --- > src/mesa/drivers/dri/i965/brw_state.h| 9 ++ > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 184 > +++ > 2 files changed, 193 insertions(+) > +void > +brw_update_texture_surface(struct gl_context *ctx, > + unsigned unit, > + uint32_t *surf_offset, > + bool for_gather, > + uint32_t plane) > +{ > + struct brw_context *brw = brw_context(ctx); > + struct gl_texture_object *obj = ctx->Texture.Unit[unit]._Current; > + > + if (obj->Target == GL_TEXTURE_BUFFER) { > + brw_update_buffer_texture_surface(ctx, unit, surf_offset); > + > + } else { > + struct intel_texture_object *intel_obj = intel_texture_object(obj); > + struct intel_mipmap_tree *mt = intel_obj->mt; > + struct gl_sampler_object *sampler = _mesa_get_samplerobj(ctx, unit); > + /* If this is a view with restricted NumLayers, then our effective > depth > + * is not just the miptree depth. > + */ > + const unsigned mt_num_layers = > + mt->logical_depth0 * (_mesa_is_cube_map_texture(mt->target) ? 6 : > 1); > + const unsigned depth = (obj->Immutable && obj->Target != GL_TEXTURE_3D > ? > + obj->NumLayers : mt_num_layers); Since 'depth' here is no longer depth, I would prefer that it be named better. Below, the code does 'view.array_len = depth', so the name 'view_array_len' or 'view_num_layers' seems appropriate. Just a suggestion. ... > + struct isl_view view = { > + .format = format, > + .base_level = obj->MinLevel + obj->BaseLevel, > + .levels = intel_obj->_MaxLevel - obj->BaseLevel + 1, > + .base_array_layer = obj->MinLayer, > + .array_len = depth, > + .channel_select = { > +swizzle_to_scs(GET_SWZ(swizzle, 0), need_green_to_blue), > +swizzle_to_scs(GET_SWZ(swizzle, 1), need_green_to_blue), > +swizzle_to_scs(GET_SWZ(swizzle, 2), need_green_to_blue), > +swizzle_to_scs(GET_SWZ(swizzle, 3), need_green_to_blue), > + }, > + .usage = ISL_SURF_USAGE_TEXTURE_BIT, > + }; > + > + if (obj->Target == GL_TEXTURE_CUBE_MAP || > + obj->Target == GL_TEXTURE_CUBE_MAP_ARRAY) > + view.usage |= ISL_SURF_USAGE_CUBE_BIT; > + > + brw_emit_surface_state(brw, mt, , > + surface_state_infos[brw->gen].tex_mocs, > for_gather, > + surf_offset, surf_index, > + I915_GEM_DOMAIN_SAMPLER, 0); > + } Looks good. Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/10] egl/android: Stop leaking DRI images
Tomasz Figawrites: > Hi Eric, > > On Sat, Jul 16, 2016 at 3:05 AM, Eric Anholt wrote: >> Tomasz Figa writes: >> >>> Current implementation of the DRI image loader does not free the images >>> created in get_back_bo() and so leaks memory. Moreover, it creates a new >>> image every time the DRI driver queries for buffers, even if the backing >>> native buffer has not changed. leaking memory again. >>> >>> This patch adds missing call to destroyImage() in droid_enqueue_buffer() >>> and a check if image is already created to get_back_bo() to fix the >>> above. >> >> This patch is: >> >> Reviewed-by: Eric Anholt >> >> But I noticed in review, it looks like droid_destroy_surface() could >> also use an image destroy. > > Thanks for review! > > It already calls droid_window_cancel_buffer(), which in turns calls > droid_window_enqueue_buffer() (typo in commit message...). Or you mean > something else I didn't notice? Ah, I missed that path. Excellent. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/10] egl/android: Add fallback to kms_swrast driver
Tomasz Figawrites: > If no hardware driver is present, it is possible to fall back to > the kms_swrast driver with any DRI node that supports dumb GEM create > and mmap IOCTLs with softpipe/llvmpipe drivers. This patch makes the > Android EGL platform code retry probe with kms_swrast if hardware-only > probe fails. This seems sensible, and if you change the "int swrast" and 0/1s to some sort of boolean (I guess EGLBoolean?), it's: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/10] egl/android: Make get_fourcc() accept HAL formats
Tomasz Figawrites: > There are DRI_IMAGE_FOURCC macros, for which there are no corresponding > DRI_IMAGE_FORMAT macros. To support such formats we need to make the > lookup function take the native format directly. As a side effect, it > simplifies all existing calls to this function, because they all called > get_format() first to convert from native to DRI_IMAGE_FORMAT. > > Signed-off-by: Tomasz Figa > --- > src/egl/drivers/dri2/platform_android.c | 22 +- > 1 file changed, 13 insertions(+), 9 deletions(-) > > diff --git a/src/egl/drivers/dri2/platform_android.c > b/src/egl/drivers/dri2/platform_android.c > index 4473400..26d7b35 100644 > --- a/src/egl/drivers/dri2/platform_android.c > +++ b/src/egl/drivers/dri2/platform_android.c > @@ -69,18 +69,20 @@ get_format_bpp(int native) > } > > /* createImageFromFds requires fourcc format */ > -static int get_fourcc(int format) > +static int get_fourcc(int native) > { > - switch(format) { > - case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565; > - case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB; > - case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB; > - case __DRI_IMAGE_FORMAT_ABGR: return __DRI_IMAGE_FOURCC_ABGR; > - case __DRI_IMAGE_FORMAT_XBGR: return __DRI_IMAGE_FOURCC_XBGR; > + switch (native) { > + case HAL_PIXEL_FORMAT_RGB_565: return __DRI_IMAGE_FOURCC_RGB565; > + case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FOURCC_ARGB; > + case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FOURCC_ABGR; > + case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR; > + default: > + _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", native); > } > return -1; > } > > +#ifdef HAS_GRALLOC_DRM_HEADERS > static int get_format(int format) > { > switch (format) { > @@ -95,6 +97,8 @@ static int get_format(int format) > } > return -1; > } > +#endif > + > static int > get_native_buffer_fd(struct ANativeWindowBuffer *buf) > { > @@ -435,7 +439,7 @@ get_back_bo(struct dri2_egl_surface *dri2_surf) >return -1; > } > > - fourcc = get_fourcc(get_format(dri2_surf->buffer->format)); > + fourcc = get_fourcc(dri2_surf->buffer->format); > > pitch = dri2_surf->buffer->stride * >get_format_bpp(dri2_surf->buffer->format); > @@ -525,7 +529,7 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp, > _EGLContext *ctx, > if (fd < 0) > return NULL; > > - const int fourcc = get_fourcc(get_format(buf->format)); > + const int fourcc = get_fourcc(buf->format); > const int pitch = buf->stride * get_format_bpp(buf->format); > > const EGLint attr_list[14] = { > -- It looks like this patch could get moved before the previous one, and then the HAS_GRALLOC_DRM_HEADERS additions could all be in that patch. I don't know enough about the state of various grallocs to review that one. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/10] egl/android: Fix support for pbuffers
Tomasz Figawrites: > From: Nicolas Boichat > > Existing image loader code supports creating images only for window > surfaces. Moreover droid_create_surface() passes wrong surface type to > dri2_get_dri_config(), resulting in incorrect configs being returned for > pbuffers. This patch fixes these issues. > > In addition, the config generation code is fixed to include single > buffered contexts required for pbuffers and make sure that generated > configs support only surfaces which can handle their supported buffering > modes. > > Signed-off-by: Nicolas Boichat > Signed-off-by: Tomasz Figa > --- > src/egl/drivers/dri2/egl_dri2.h | 1 + > src/egl/drivers/dri2/platform_android.c | 61 > +++-- > 2 files changed, 51 insertions(+), 11 deletions(-) > > diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h > index 317de06..3ffc177 100644 > --- a/src/egl/drivers/dri2/egl_dri2.h > +++ b/src/egl/drivers/dri2/egl_dri2.h > @@ -287,6 +287,7 @@ struct dri2_egl_surface > struct ANativeWindow *window; > struct ANativeWindowBuffer *buffer; > __DRIimage *dri_image; > + __DRIimage *dri_front_image; > > /* EGL-owned buffers */ > __DRIbuffer *local_buffers[__DRI_BUFFER_COUNT]; > diff --git a/src/egl/drivers/dri2/platform_android.c > b/src/egl/drivers/dri2/platform_android.c > index 7495445..0f707dd 100644 > --- a/src/egl/drivers/dri2/platform_android.c > +++ b/src/egl/drivers/dri2/platform_android.c > @@ -728,6 +754,19 @@ droid_add_configs_for_visuals(_EGLDriver *drv, > _EGLDisplay *dpy) >/* there is no front buffer so no OpenGL */ >dri2_conf->base.RenderableType &= ~EGL_OPENGL_BIT; >dri2_conf->base.Conformant &= ~EGL_OPENGL_BIT; > + > + for (j = 0; j < 2; j++) { > + /* Unsupported color space variants should not affect surface type. > */ > + if (!dri2_conf->dri_single_config[j] && > !dri2_conf->dri_double_config[j]) > +continue; > + > + /* Pbuffers support only single buffering. */ > + if (!dri2_conf->dri_single_config[j]) > +dri2_conf->base.SurfaceType &= ~EGL_PBUFFER_BIT; > + /* Windows support only double buffering. */ > + else if (!dri2_conf->dri_double_config[j]) > +dri2_conf->base.SurfaceType &= ~EGL_WINDOW_BIT; > + } Style nitpick, I'd either drop the "else" or use some braces and put the comments within the inner blocks. Having the "else if" separated from the "if" by the comment looked weird. Up to you, though. The actual contents of the patch are: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96943] [gallium] glCopyPixels is affected by enabled texture state
https://bugs.freedesktop.org/show_bug.cgi?id=96943 --- Comment #2 from Ilia Mirkin--- (In reply to Roland Scheidegger from comment #1) > The piglit test is probably wrong (I didn't really look), at least different > results based on enabled texturing don't surprise me. This is one of the > more weird "features" of glCopyPixels(), glDrawPixels() and friends. > From the respective man pages: > "Texture mapping, fog, and all the fragment operations are applied before > the fragments are written to the frame buffer." So if you don't disable > texturing, you'll get texturing on top of your copied pixels (which just > represent the primary color), in whatever way the shader specified (albeit > the texture coords should be constant IIRC). OK, so in that case, any time that a texture unit is enabled, we should be falling back to the drawpixels-style shader? (The multiply, btw, is coming from the texture combine logic, which defaults to "combine" aka "multiply".) -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/10] egl/android: Stop leaking DRI images
Hi Eric, On Sat, Jul 16, 2016 at 3:05 AM, Eric Anholtwrote: > Tomasz Figa writes: > >> Current implementation of the DRI image loader does not free the images >> created in get_back_bo() and so leaks memory. Moreover, it creates a new >> image every time the DRI driver queries for buffers, even if the backing >> native buffer has not changed. leaking memory again. >> >> This patch adds missing call to destroyImage() in droid_enqueue_buffer() >> and a check if image is already created to get_back_bo() to fix the >> above. > > This patch is: > > Reviewed-by: Eric Anholt > > But I noticed in review, it looks like droid_destroy_surface() could > also use an image destroy. Thanks for review! It already calls droid_window_cancel_buffer(), which in turns calls droid_window_enqueue_buffer() (typo in commit message...). Or you mean something else I didn't notice? Best regards, Tomasz ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 96943] [gallium] glCopyPixels is affected by enabled texture state
https://bugs.freedesktop.org/show_bug.cgi?id=96943 --- Comment #1 from Roland Scheidegger--- (In reply to Ilia Mirkin from comment #0) > The recently rewritten copy-pixels test has exposed some failures in > st/mesa. When there's an overlapping copy (among other conditions), the > operation becomes a fb read + draw of that texture with the current fragment > shader modified in the same way as glDrawPixels does it. (So this problem > might extend itself to glDrawPixels as well). > > Doing a glDisable(GL_TEXTURE_2D) before the glCopyPixels() call in the > piglit fixes the issue. Effectively that texture is being multiplied with > the copied data, whereas from what I can tell, it shouldn't be. I think the > multiplication comes from the ff-generated shader. > > [An alternative is that the piglit test and i965 are wrong and what gallium > is doing is correct. I don't think that's the case, since the only > disagreement is on the overlapped copy.] The piglit test is probably wrong (I didn't really look), at least different results based on enabled texturing don't surprise me. This is one of the more weird "features" of glCopyPixels(), glDrawPixels() and friends. >From the respective man pages: "Texture mapping, fog, and all the fragment operations are applied before the fragments are written to the frame buffer." So if you don't disable texturing, you'll get texturing on top of your copied pixels (which just represent the primary color), in whatever way the shader specified (albeit the texture coords should be constant IIRC). Near certainly this actually isn't what an app wants to do... And yes I'd be very surprised if mesa (or any other implementation) actually gets it right all the time. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/10] egl/android: Stop leaking DRI images
Tomasz Figawrites: > Current implementation of the DRI image loader does not free the images > created in get_back_bo() and so leaks memory. Moreover, it creates a new > image every time the DRI driver queries for buffers, even if the backing > native buffer has not changed. leaking memory again. > > This patch adds missing call to destroyImage() in droid_enqueue_buffer() > and a check if image is already created to get_back_bo() to fix the > above. This patch is: Reviewed-by: Eric Anholt But I noticed in review, it looks like droid_destroy_surface() could also use an image destroy. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] egl/android: Set EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT
[Adding Haixia to the thread.] On Sat, Jul 16, 2016 at 2:52 AM, Eric Anholtwrote: > Tomasz Figa writes: > >> From: Haixia Shi >> >> Set config attributes EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT to >> hard-coded non-zero values. These two attributes are required on Android. >> >> Signed-off-by: Tomasz Figa >> --- >> src/egl/drivers/dri2/platform_android.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/src/egl/drivers/dri2/platform_android.c >> b/src/egl/drivers/dri2/platform_android.c >> index b33f4e8..f42febc 100644 >> --- a/src/egl/drivers/dri2/platform_android.c >> +++ b/src/egl/drivers/dri2/platform_android.c >> @@ -655,6 +655,8 @@ droid_add_configs_for_visuals(_EGLDriver *drv, >> _EGLDisplay *dpy) >> EGL_NATIVE_VISUAL_TYPE, 0, >> EGL_FRAMEBUFFER_TARGET_ANDROID, EGL_TRUE, >> EGL_RECORDABLE_ANDROID, EGL_TRUE, >> + EGL_MAX_PBUFFER_WIDTH, 4096, >> + EGL_MAX_PBUFFER_HEIGHT, 4096, >> EGL_NONE > > It seems weird to me to pick a plausible value that hardware might have, > without actually asking the hardware for the value. Could we use some > MAX_INT-type value to make it obvious that we're just lying and leaving > it up to buffer creation time to error out? If I remember correctly, there are dEQP tests which attempt to use pbuffers bigger and bigger until reaching the limits and checking if they work properly. Haixia, what was the story behind hardcoding these values? I suppose the proper way would be to query the driver indeed... Best regards, Tomasz ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] anv: Handle VK_WHOLE_SIZE properly for buffer views
On Fri, Jul 15, 2016 at 9:57 AM, Nanley Cherywrote: > On Thu, Jul 14, 2016 at 09:20:08PM -0700, Jason Ekstrand wrote: > > The old calculation, which used view->offset, encorporated buffer->offset > > into the size calculation where it doesn't belong. This meant that, if > > buffer->offset > buffer->size, you would always get a negative size. > This > > fixes 170 dEQP-VK.renderpass.attachment.* Vulkan CTS tests on Haswell. > > > > Nice patch. > > > Signed-off-by: Jason Ekstrand > > Cc: "12.0" > > --- > > src/intel/vulkan/anv_image.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c > > index 23fdd93..fe5b124 100644 > > --- a/src/intel/vulkan/anv_image.c > > +++ b/src/intel/vulkan/anv_image.c > > @@ -631,7 +631,7 @@ void anv_buffer_view_init(struct anv_buffer_view > *view, > > view->bo = buffer->bo; > > view->offset = buffer->offset + pCreateInfo->offset; > > view->range = pCreateInfo->range == VK_WHOLE_SIZE ? > > - buffer->size - view->offset : pCreateInfo->range; > > + buffer->size - pCreateInfo->offset : > pCreateInfo->range; > > > > This is almost correct. The range member definition (11.2. Buffer Views) > has a corner case for VK_WHOLE_SIZE. It states that if > R = (buffer_size - buffer_view_offset) is not a multiple of > buffer_view_format_size, then you must set the range member to > the nearest smaller multiple of buffer_view_format_size. > Thanks for your care! I was not thinking of that corner-case. > Which is to say, > if (requested_range == VK_WHOLE_SIZE) > actual_range = ALIGN_DOWN(R, buffer_view_format_size); > That said, the hardware packet is in number of elements so we divide by the format size and round down in isl_buffer_fill_state so I think it's ok. --Jason > > - Nanley > > > if (buffer->usage & VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT) { > >view->surface_state = alloc_surface_state(device, cmd_buffer); > > -- > > 2.5.0.400.gff86faf > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/10] egl/android: Add some useful error messages
Tomasz Figawrites: > It is much easier to debug issues when the application gives some > meaningful error messages. This patch adds few to the EGL Android > platform backend. > > Signed-off-by: Tomasz Figa Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] egl/android: Set EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT
Tomasz Figawrites: > From: Haixia Shi > > Set config attributes EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT to > hard-coded non-zero values. These two attributes are required on Android. > > Signed-off-by: Tomasz Figa > --- > src/egl/drivers/dri2/platform_android.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/egl/drivers/dri2/platform_android.c > b/src/egl/drivers/dri2/platform_android.c > index b33f4e8..f42febc 100644 > --- a/src/egl/drivers/dri2/platform_android.c > +++ b/src/egl/drivers/dri2/platform_android.c > @@ -655,6 +655,8 @@ droid_add_configs_for_visuals(_EGLDriver *drv, > _EGLDisplay *dpy) > EGL_NATIVE_VISUAL_TYPE, 0, > EGL_FRAMEBUFFER_TARGET_ANDROID, EGL_TRUE, > EGL_RECORDABLE_ANDROID, EGL_TRUE, > + EGL_MAX_PBUFFER_WIDTH, 4096, > + EGL_MAX_PBUFFER_HEIGHT, 4096, > EGL_NONE It seems weird to me to pick a plausible value that hardware might have, without actually asking the hardware for the value. Could we use some MAX_INT-type value to make it obvious that we're just lying and leaving it up to buffer creation time to error out? signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/10] egl/android: Check return value of dri2_get_dri_config()
Tomasz Figawrites: > It might return NULL if specific config variant is unsupported. > > Signed-off-by: Tomasz Figa Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode
Zhang, Boyuan wrote: Hi Andy, Thanks for the testing. I will look into the memory issue. For the cbr test, what was the bitrate you set? And by saying testing high rates, how high was the rate approximately? Testing more shows that I get the same size file independent of framerate. An example inputting rawvideo and asking gstreamer for 30mbit with 500 frames 2560x1440 for both 25fps and 50fps produces 60M byte files for both. omx doesn't have this issue, for 30mbit the files produced are 53M and 26M. Also noted that omx takes 3.8 seconds and vaapi 13.8 for the same input. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/14] isl: Add support for HiZ surfaces
On Thu, Jul 14, 2016 at 04:18:33PM -0700, Jason Ekstrand wrote: > On Thu, Jul 14, 2016 at 4:13 PM, Nanley Cherywrote: > > > On Thu, Jul 14, 2016 at 03:57:09PM -0700, Jason Ekstrand wrote: > > > On Thu, Jul 14, 2016 at 3:45 PM, Nanley Chery > > wrote: > > > > > > > On Sat, Jul 09, 2016 at 12:17:28PM -0700, Jason Ekstrand wrote: > > > > > --- > > > > > src/intel/isl/isl.c | 11 +++ > > > > > src/intel/isl/isl.h | 17 + > > > > > src/intel/isl/isl_format_layout.csv | 1 + > > > > > src/intel/isl/isl_gen6.c| 8 > > > > > src/intel/isl/isl_gen7.c| 10 +- > > > > > src/intel/isl/isl_gen8.c| 3 ++- > > > > > 6 files changed, 48 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c > > > > > index 8c114a2..9ccdea2 100644 > > > > > --- a/src/intel/isl/isl.c > > > > > +++ b/src/intel/isl/isl.c > > > > > @@ -167,6 +167,16 @@ isl_tiling_get_info(const struct isl_device > > *dev, > > > > >break; > > > > > } > > > > > > > > > > + case ISL_TILING_HIZ: > > > > > + /* HiZ buffers are required to have ISL_FORMAT_HIZ which is > > an 8x4 > > > > > + * 128bpb format. The tiling has the same physical > > dimensions as > > > > > + * Y-tiling but actually has two HiZ columns per Y-tiled > > column. > > > > > + */ > > > > > + assert(bs == 16); > > > > > + logical_el = isl_extent2d(16, 16); > > > > > + phys_B = isl_extent2d(128, 32); > > > > > + break; > > > > > + > > > > > default: > > > > >unreachable("not reached"); > > > > > } /* end switch */ > > > > > @@ -221,6 +231,7 @@ isl_surf_choose_tiling(const struct isl_device > > *dev, > > > > >CHOOSE(ISL_TILING_LINEAR); > > > > > } > > > > > > > > > > + CHOOSE(ISL_TILING_HIZ); > > > > > CHOOSE(ISL_TILING_Ys); > > > > > CHOOSE(ISL_TILING_Yf); > > > > > CHOOSE(ISL_TILING_Y0); > > > > > diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h > > > > > index 85af2d1..9a60bbd 100644 > > > > > --- a/src/intel/isl/isl.h > > > > > +++ b/src/intel/isl/isl.h > > > > > @@ -345,6 +345,14 @@ enum isl_format { > > > > > ISL_FORMAT_ASTC_LDR_2D_12X10_FLT16 =638, > > > > > ISL_FORMAT_ASTC_LDR_2D_12X12_FLT16 =639, > > > > > > > > > > + /* The formats that follow are internal to ISL and as such don't > > > > have an > > > > > +* explicit number. We'll just let the C compiler assign it for > > > > us. Any > > > > > +* actual hardware formats *must* come before these in the list. > > > > > +*/ > > > > > + > > > > > + /* Formats for color compression surfaces */ > > > > > + ISL_FORMAT_HIZ, > > > > > > > > Why is HiZ a color compression surface instead of a depth compression > > > > surface? > > > > > > > > > > Aux surfaces then? It's not really "color" compression... > > > > > > > That works. > > > > > > > > > > > > > > + > > > > > /* Hardware doesn't understand this out-of-band value */ > > > > > ISL_FORMAT_UNSUPPORTED = UINT16_MAX, > > > > > }; > > > > > @@ -392,6 +400,9 @@ enum isl_txc { > > > > > ISL_TXC_ETC1, > > > > > ISL_TXC_ETC2, > > > > > ISL_TXC_ASTC, > > > > > + > > > > > + /* Used for auxiliary surface formats */ > > > > > + ISL_TXC_HIZ, > > > > > }; > > > > > > > > > > /** > > > > > @@ -410,6 +421,7 @@ enum isl_tiling { > > > > > ISL_TILING_Y0, /**< Legacy Y tiling */ > > > > > ISL_TILING_Yf, /**< Standard 4K tiling. The 'f' means "four". */ > > > > > ISL_TILING_Ys, /**< Standard 64K tiling. The 's' means > > "sixty-four". > > > > */ > > > > > + ISL_TILING_HIZ, /**< Tiling format for HiZ surfaces */ > > > > > }; > > > > > > > > > > /** > > > > > @@ -423,6 +435,7 @@ typedef uint32_t isl_tiling_flags_t; > > > > > #define ISL_TILING_Y0_BIT (1u << ISL_TILING_Y0) > > > > > #define ISL_TILING_Yf_BIT (1u << ISL_TILING_Yf) > > > > > #define ISL_TILING_Ys_BIT (1u << ISL_TILING_Ys) > > > > > +#define ISL_TILING_HIZ_BIT(1u << ISL_TILING_HIZ) > > > > > #define ISL_TILING_ANY_MASK (~0u) > > > > > #define ISL_TILING_NON_LINEAR_MASK(~ISL_TILING_LINEAR_BIT) > > > > > > > > > > @@ -505,6 +518,7 @@ typedef uint64_t isl_surf_usage_flags_t; > > > > > #define ISL_SURF_USAGE_DISPLAY_FLIP_X_BIT (1u << 10) > > > > > #define ISL_SURF_USAGE_DISPLAY_FLIP_Y_BIT (1u << 11) > > > > > #define ISL_SURF_USAGE_STORAGE_BIT (1u << 12) > > > > > +#define ISL_SURF_USAGE_HIZ_BIT (1u << 13) > > > > > /** @} */ > > > > > > > > > > /** > > > > > @@ -966,6 +980,9 @@ isl_format_has_bc_compression(enum isl_format > > fmt) > > > > > case ISL_TXC_ETC2: > > > > > case ISL_TXC_ASTC: > > > > >return false; > > > > > + > > > > > + case
[Mesa-dev] [PATCH 4/4] mesa: handle numLevels, numSamples in _mesa_test_proxy_teximage()
If numSamples > 0, we can compute the size of the whole mipmapped texture. That's the case for glTexStorage(GL_PROXY_TEXTURE_x). Also, multiply the texture size by numSamples for MSAA textures. --- src/mesa/main/teximage.c | 48 +--- 1 file changed, 45 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c index c75f605..0f13d61 100644 --- a/src/mesa/main/teximage.c +++ b/src/mesa/main/teximage.c @@ -40,6 +40,7 @@ #include "image.h" #include "imports.h" #include "macros.h" +#include "mipmap.h" #include "multisample.h" #include "pixelstore.h" #include "state.h" @@ -1268,12 +1269,53 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum target, mesa_format format, GLuint numSamples, GLint width, GLint height, GLint depth) { + uint64_t bytes, mbytes; + + assert(numSamples > 0); + + if (numLevels > 0) { + /* Compute total memory for a whole mipmap. This is the path + * taken for glTexStorage(GL_PROXY_TEXTURE_x). + */ + unsigned l; + + assert(level == 0); + + bytes = 0; + + for (l = 0; l < numLevels; l++) { + GLint nextWidth, nextHeight, nextDepth; + + /* XXX this doesn't yet account for multisampling */ + bytes += _mesa_format_image_size64(format, width, height, depth); + + if (_mesa_next_mipmap_level_size(target, 0, width, height, depth, + , , + )) { +width = nextWidth; +height = nextHeight; +depth = nextDepth; + } + else { +break; + } + } + } + else { + /* We just compute the size of one mipmap level. This is the path + * taken for glTexImage(GL_PROXY_TEXTURE_x). + */ + bytes = _mesa_format_image_size64(format, width, height, depth); + } + + bytes *= _mesa_num_tex_faces(target); + bytes *= numSamples; + + mbytes = bytes / (1024 * 1024); /* convert to MB */ + /* We just check if the image size is less than MaxTextureMbytes. * Some drivers may do more specific checks. */ - uint64_t bytes = _mesa_format_image_size64(format, width, height, depth); - uint64_t mbytes = bytes / (1024 * 1024); /* convert to MB */ - mbytes *= _mesa_num_tex_faces(target); return mbytes <= (uint64_t) ctx->Const.MaxTextureMbytes; } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] mesa: use _mesa_clear_texture_image() in clear_texture_fields()
This avoids a failed assert(img->_BaseFormat != -1) in init_teximage_fields_ms() because the internalFormat argument is GL_NONE. This was hit when using glTexStorage() to do a proxy texture test. Fixes a failure with the updated Piglit tex3d-maxsize test. Cc:--- src/mesa/main/texstorage.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c index f4a0760..72ed869 100644 --- a/src/mesa/main/texstorage.c +++ b/src/mesa/main/texstorage.c @@ -179,9 +179,7 @@ clear_texture_fields(struct gl_context *ctx, return; } - _mesa_init_teximage_fields(ctx, texImage, -0, 0, 0, 0, /* w, h, d, border */ -GL_NONE, MESA_FORMAT_NONE); + _mesa_clear_texture_image(ctx, texImage); } } } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] mesa: add proxy texture targets in _mesa_next_mipmap_level_size()
So we can use it for computing size of proxy textures. --- src/mesa/main/mipmap.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c index 5ff53f4..996e3f8 100644 --- a/src/mesa/main/mipmap.c +++ b/src/mesa/main/mipmap.c @@ -1777,7 +1777,8 @@ _mesa_next_mipmap_level_size(GLenum target, GLint border, } if ((srcHeight - 2 * border > 1) && - (target != GL_TEXTURE_1D_ARRAY_EXT)) { + target != GL_TEXTURE_1D_ARRAY_EXT && + target != GL_PROXY_TEXTURE_1D_ARRAY_EXT) { *dstHeight = (srcHeight - 2 * border) / 2 + 2 * border; } else { @@ -1785,8 +1786,10 @@ _mesa_next_mipmap_level_size(GLenum target, GLint border, } if ((srcDepth - 2 * border > 1) && - (target != GL_TEXTURE_2D_ARRAY_EXT && -target != GL_TEXTURE_CUBE_MAP_ARRAY)) { + target != GL_TEXTURE_2D_ARRAY_EXT && + target != GL_PROXY_TEXTURE_2D_ARRAY_EXT && + target != GL_TEXTURE_CUBE_MAP_ARRAY && + target != GL_PROXY_TEXTURE_CUBE_MAP_ARRAY) { *dstDepth = (srcDepth - 2 * border) / 2 + 2 * border; } else { -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] mesa: add numLevels, numSamples to Driver.TestProxyTexImage()
So that the function can work properly with glTexStorage(), where we know how many mipmap levels there are. And so we can compute storage for MSAA textures. Also, remove the obsolete texture border parameter. A subsequent patch will update _mesa_test_proxy_teximage() to use these new parameters. --- src/mesa/drivers/common/meta_copy_image.c | 6 +++--- src/mesa/main/dd.h| 5 +++-- src/mesa/main/teximage.c | 22 -- src/mesa/main/teximage.h | 7 --- src/mesa/main/texstorage.c| 4 ++-- src/mesa/main/textureview.c | 5 +++-- src/mesa/state_tracker/st_cb_texture.c| 19 --- 7 files changed, 39 insertions(+), 29 deletions(-) diff --git a/src/mesa/drivers/common/meta_copy_image.c b/src/mesa/drivers/common/meta_copy_image.c index ebea428..e1c90a3 100644 --- a/src/mesa/drivers/common/meta_copy_image.c +++ b/src/mesa/drivers/common/meta_copy_image.c @@ -101,9 +101,9 @@ make_view(struct gl_context *ctx, struct gl_texture_image *tex_image, 0, internal_format, GL_NONE, GL_NONE); - if (!ctx->Driver.TestProxyTexImage(ctx, tex_obj->Target, 0, tex_format, - tex_image->Width, tex_image->Height, - tex_image->Depth, 0)) { + if (!ctx->Driver.TestProxyTexImage(ctx, tex_obj->Target, 1, 0, tex_format, + 1, tex_image->Width, tex_image->Height, + tex_image->Depth)) { _mesa_DeleteTextures(1, view_tex_name); *view_tex_name = 0; return false; diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h index 4891e2a..114cbd2 100644 --- a/src/mesa/main/dd.h +++ b/src/mesa/main/dd.h @@ -308,9 +308,10 @@ struct dd_function_table { * \return GL_TRUE if the image is OK, GL_FALSE if too large */ GLboolean (*TestProxyTexImage)(struct gl_context *ctx, GLenum target, - GLint level, mesa_format format, + GLuint numLevels, GLint level, + mesa_format format, GLuint numSamples, GLint width, GLint height, - GLint depth, GLint border); + GLint depth); /*@}*/ diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c index 080bcbf..c75f605 100644 --- a/src/mesa/main/teximage.c +++ b/src/mesa/main/teximage.c @@ -1253,18 +1253,20 @@ error_check_subtexture_dimensions(struct gl_context *ctx, GLuint dims, * and texturing will effectively be disabled. * * \param target any texture target/type + * \param numLevels number of mipmap levels in the texture or 0 if not known * \param level as passed to glTexImage * \param format the MESA_FORMAT_x for the tex image + * \param numSamples number of samples per texel * \param width as passed to glTexImage * \param height as passed to glTexImage * \param depth as passed to glTexImage - * \param border as passed to glTexImage * \return GL_TRUE if the image is acceptable, GL_FALSE if not acceptable. */ GLboolean -_mesa_test_proxy_teximage(struct gl_context *ctx, GLenum target, GLint level, - mesa_format format, - GLint width, GLint height, GLint depth, GLint border) +_mesa_test_proxy_teximage(struct gl_context *ctx, GLenum target, + GLuint numLevels, GLint level, + mesa_format format, GLuint numSamples, + GLint width, GLint height, GLint depth) { /* We just check if the image size is less than MaxTextureMbytes. * Some drivers may do more specific checks. @@ -2949,8 +2951,8 @@ teximage(struct gl_context *ctx, GLboolean compressed, GLuint dims, /* check that the texture won't take too much memory, etc */ sizeOK = ctx->Driver.TestProxyTexImage(ctx, proxy_target(target), - level, texFormat, - width, height, depth, border); + 0, level, texFormat, 1, + width, height, depth); if (_mesa_is_proxy_texture(target)) { /* Proxy texture: just clear or set state depending on error checking */ @@ -3646,8 +3648,8 @@ copyteximage(struct gl_context *ctx, GLuint dims, assert(texFormat != MESA_FORMAT_NONE); if (!ctx->Driver.TestProxyTexImage(ctx, proxy_target(target), - level, texFormat, - width, height, 1, border)) { + 0, level, texFormat, 1, + width, height, 1)) { _mesa_error(ctx, GL_OUT_OF_MEMORY,
[Mesa-dev] [Bug 96943] [gallium] glCopyPixels is affected by enabled texture state
https://bugs.freedesktop.org/show_bug.cgi?id=96943 Bug ID: 96943 Summary: [gallium] glCopyPixels is affected by enabled texture state Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: imir...@alum.mit.edu QA Contact: mesa-dev@lists.freedesktop.org The recently rewritten copy-pixels test has exposed some failures in st/mesa. When there's an overlapping copy (among other conditions), the operation becomes a fb read + draw of that texture with the current fragment shader modified in the same way as glDrawPixels does it. (So this problem might extend itself to glDrawPixels as well). Doing a glDisable(GL_TEXTURE_2D) before the glCopyPixels() call in the piglit fixes the issue. Effectively that texture is being multiplied with the copied data, whereas from what I can tell, it shouldn't be. I think the multiplication comes from the ff-generated shader. [An alternative is that the piglit test and i965 are wrong and what gallium is doing is correct. I don't think that's the case, since the only disagreement is on the overlapped copy.] -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] anv: Handle VK_WHOLE_SIZE properly for buffer views
On Thu, Jul 14, 2016 at 09:20:08PM -0700, Jason Ekstrand wrote: > The old calculation, which used view->offset, encorporated buffer->offset > into the size calculation where it doesn't belong. This meant that, if > buffer->offset > buffer->size, you would always get a negative size. This > fixes 170 dEQP-VK.renderpass.attachment.* Vulkan CTS tests on Haswell. > Nice patch. > Signed-off-by: Jason Ekstrand> Cc: "12.0" > --- > src/intel/vulkan/anv_image.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c > index 23fdd93..fe5b124 100644 > --- a/src/intel/vulkan/anv_image.c > +++ b/src/intel/vulkan/anv_image.c > @@ -631,7 +631,7 @@ void anv_buffer_view_init(struct anv_buffer_view *view, > view->bo = buffer->bo; > view->offset = buffer->offset + pCreateInfo->offset; > view->range = pCreateInfo->range == VK_WHOLE_SIZE ? > - buffer->size - view->offset : pCreateInfo->range; > + buffer->size - pCreateInfo->offset : pCreateInfo->range; > This is almost correct. The range member definition (11.2. Buffer Views) has a corner case for VK_WHOLE_SIZE. It states that if R = (buffer_size - buffer_view_offset) is not a multiple of buffer_view_format_size, then you must set the range member to the nearest smaller multiple of buffer_view_format_size. Which is to say, if (requested_range == VK_WHOLE_SIZE) actual_range = ALIGN_DOWN(R, buffer_view_format_size); - Nanley > if (buffer->usage & VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT) { >view->surface_state = alloc_surface_state(device, cmd_buffer); > -- > 2.5.0.400.gff86faf > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] genxml: Make gen6-7 blending look more like gen8
On Fri, Jul 15, 2016 at 3:38 AM, Kenneth Graunkewrote: > On Thursday, July 14, 2016 9:20:05 PM PDT Jason Ekstrand wrote: > > This renames BLEND_STATE to BLEND_STATE_ENTRY and adds an new struct > > BLEND_STATE which is just an array of 8 BLEND_STATE_ENTRYs. This will > make > > it much easier to write gen-agnostic blend handling code. > > > > Signed-off-by: Jason Ekstrand > > Cc: "12.0" > > --- > > src/intel/genxml/gen6.xml| 8 +++- > > src/intel/genxml/gen7.xml| 8 +++- > > src/intel/genxml/gen75.xml | 8 +++- > > src/intel/vulkan/gen7_pipeline.c | 25 + > > 4 files changed, 34 insertions(+), 15 deletions(-) > > The series is: > Reviewed-by: Kenneth Graunke > > though my review on patch 4 is pretty light. > Thanks! I'm sure Nanley can take patch 4. I think he might have written that code after all. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode
Hi Andy, Thanks for the testing. I will look into the memory issue. For the cbr test, what was the bitrate you set? And by saying testing high rates, how high was the rate approximately? Regards, Boyuan -Original Message- From: Andy Furniss [mailto:adf.li...@gmail.com] Sent: July-15-16 9:42 AM To: Christian König; Zhang, Boyuan; mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode Christian König wrote: > Am 05.07.2016 um 13:17 schrieb Christian König: >> Am 01.07.2016 um 18:18 schrieb Andy Furniss: >>> Christian König wrote: Am 01.07.2016 um 18:02 schrieb Andy Furniss: > Christian König wrote: >> Am 01.07.2016 um 16:42 schrieb Andy Furniss: >>> Boyuan Zhang wrote: Signed-off-by: Boyuan Zhang>>> >>> Is this supposed to be the same functionally as the first version? >>> >>> I notice on Tonga that I previously got cabac, but don't now. >>> >>> I see the new options are now in radeon_vce_52.c whereas before >>> radeon_vce_40_2_2.c was changed - is this why? >> >> We wanted to keep the code for the old firmware versions as it >> is, because we otherwise would need to test them again. >> >> Because of this we moved all modifications into radeon_vce_52.c. > > Oh OK, I guess it's early days but cabac was one thing that seemed OK. > > There are many issued on Tonga using vaapi - but then I suppose > gstreamer and ffmpeg are not really set up for it yet. > > eg. worse first = gpu vm fault/lock with gstreamer but not ffmpeg. > > to provoke do > > gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12, > width=1920, height=1080, framerate=60/1 ! vaapih264enc | fakesink > > then flip away/back to another desktop soon will lock. > > Maybe I am too early eg. other patches needed? or does what you > say above mean that vaapienc shouldn't even be enabled for older chips? Tonga should be perfectly supported, you just need recent enough firmware. What does "dmesg | grep 'Found VCE firmware Version'" give you? >>> >>> Found VCE firmware Version: 50.17 Binary ID: 3 >> >> Mhm, well looks like we haven't released the right firmware for Tonga >> yet :( >> >> Going to leave you a note when we have everything together. > > The new firmware landed on Monday and the final patchset was released > yesterday night. > > Have fun testing it, Found VCE firmware Version: 52.4 Binary ID: 3 No luck I'm afraid. The above test will still hard lock me after about 30 seconds. I also notice it's eating memory 2.6 gig by the time I lock. Replace vaapih264enc with omxh264enc and all is OK, will run for ages no increasing memory usage. In fact I think this firmware & or kernel has fixed a powerplay omx issue - will update my bug for that when I have tested more. FWIW the above test would make cqp with a qp of 0 - testing cbr does also leak/lock, though specifying bitrates does sort of work, the result is much higher than requested (maybe some framerate assumption - I am testing high rates. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode
Christian König wrote: Am 05.07.2016 um 13:17 schrieb Christian König: Am 01.07.2016 um 18:18 schrieb Andy Furniss: Christian König wrote: Am 01.07.2016 um 18:02 schrieb Andy Furniss: Christian König wrote: Am 01.07.2016 um 16:42 schrieb Andy Furniss: Boyuan Zhang wrote: Signed-off-by: Boyuan ZhangIs this supposed to be the same functionally as the first version? I notice on Tonga that I previously got cabac, but don't now. I see the new options are now in radeon_vce_52.c whereas before radeon_vce_40_2_2.c was changed - is this why? We wanted to keep the code for the old firmware versions as it is, because we otherwise would need to test them again. Because of this we moved all modifications into radeon_vce_52.c. Oh OK, I guess it's early days but cabac was one thing that seemed OK. There are many issued on Tonga using vaapi - but then I suppose gstreamer and ffmpeg are not really set up for it yet. eg. worse first = gpu vm fault/lock with gstreamer but not ffmpeg. to provoke do gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12, width=1920, height=1080, framerate=60/1 ! vaapih264enc | fakesink then flip away/back to another desktop soon will lock. Maybe I am too early eg. other patches needed? or does what you say above mean that vaapienc shouldn't even be enabled for older chips? Tonga should be perfectly supported, you just need recent enough firmware. What does "dmesg | grep 'Found VCE firmware Version'" give you? Found VCE firmware Version: 50.17 Binary ID: 3 Mhm, well looks like we haven't released the right firmware for Tonga yet :( Going to leave you a note when we have everything together. The new firmware landed on Monday and the final patchset was released yesterday night. Have fun testing it, Found VCE firmware Version: 52.4 Binary ID: 3 No luck I'm afraid. The above test will still hard lock me after about 30 seconds. I also notice it's eating memory 2.6 gig by the time I lock. Replace vaapih264enc with omxh264enc and all is OK, will run for ages no increasing memory usage. In fact I think this firmware & or kernel has fixed a powerplay omx issue - will update my bug for that when I have tested more. FWIW the above test would make cqp with a qp of 0 - testing cbr does also leak/lock, though specifying bitrates does sort of work, the result is much higher than requested (maybe some framerate assumption - I am testing high rates. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/dri2: dri2_make_current: Make sure display is initialized before using it
On 15 July 2016 at 09:28, Nicolas Boichatwrote: > android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls > eglTerminate, followed by eglReleaseThread. In that case, the > display will not be initialized when eglReleaseThread calls > MakeCurrent with NULL parameters, to unbind the context, which > causes a a segfault in drv->API.MakeCurrent (dri2_make_current), > either in glFlush or in a latter call. > > A similar case is observed in this bug: > https://bugs.freedesktop.org/show_bug.cgi?id=69622, where the test > call eglTerminate, then eglMakeCurrent(dpy, NULL, NULL, NULL). > > This patch: > 1. Validates that the display is initialized, if ctx/dsurf/rsurf > are not all NULL. > 2. Does not call glFlush/unBindContext is there is no display. > 3. However, it still goes through the normal path as > drv->API.DestroyContext decrements the reference count on the > context, and frees the structure. > > Cc: "11.2 12.0" > Signed-off-by: Nicolas Boichat > --- > > I did not actually test the case reported on the bug, only the CTS > test, would be nice if someone can try it out (Rhys? Chad?). > > Applies after "egl/dri2: dri2_make_current: Set EGL error if bindContext > fails", but wanted to keep the 2 patches separate as they are different > problems and discussions. > > src/egl/drivers/dri2/egl_dri2.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c > index 2e97d85..3269e52 100644 > --- a/src/egl/drivers/dri2/egl_dri2.c > +++ b/src/egl/drivers/dri2/egl_dri2.c > @@ -1166,7 +1166,8 @@ dri2_destroy_context(_EGLDriver *drv, _EGLDisplay > *disp, _EGLContext *ctx) > struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp); > > if (_eglPutContext(ctx)) { > - dri2_dpy->core->destroyContext(dri2_ctx->dri_context); > + if (dri2_dpy) Not sure if this is the right place/we need this. When calling eglDestroyContext (after eglTerminate or not) this cannot happen since the _EGL_CHECK_CONTEXT macro will dive into the _eglCheck functions and will bail out since the since the dpy is no initialized. The only case we can reach this is from dri2_make_current. See below for more. > @@ -1189,6 +1190,10 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, > _EGLSurface *dsurf, > __DRIdrawable *ddraw, *rdraw; > __DRIcontext *cctx; > > + /* Check that the display is initialized */ > + if ((ctx != NULL || dsurf != NULL || rsurf != NULL) && !dri2_dpy) > + return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent error"); > + Was doing to say "the first few lines in eglMakeCurrent) should already handle these" only to realise that dri2_dpy doesn't wrap around/subclass the respective _EGLfoo type (_EGLDisplay), like the dri2_egl_{surface,context...} :-\ At the same time, dri2_make_current cannot (should not really) do anything in the !dri2_dpy case, since we cannot: - call unbind the old ctx bind the new one, or even restore/rebind the original ctx - free any of the ctx/surf resources. The latter should already be gone, as upon eglTerminate walk over the ctx/surf lists and tear them all down (see _eglReleaseDisplayResources). Thus something like the following should be fine imho. if (!dri2_dpy) /* copy/reword some my earlier comment in here */ return 0; > /* make new bindings */ > if (!_eglBindContext(ctx, dsurf, rsurf, _ctx, _dsurf, > _rsurf)) { >/* _eglBindContext already sets the EGL error (in > _eglCheckMakeCurrent) */ > @@ -1196,14 +1201,14 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, > _EGLSurface *dsurf, > } > > /* flush before context switch */ > - if (old_ctx && dri2_drv->glFlush) > + if (old_ctx && dri2_dpy && dri2_drv->glFlush) Mildly related: We might want to bail out in dri2_load on !dri2_drv->glFlush and drop the check here. If we cannot get glapi and/or glFlush symbol things are seriously stuffed and pretending to continue just won't work. > dri2_destroy_surface(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSurface *surf) > { > struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy); > + if (!dri2_dpy) > + return EGL_TRUE; Analogous to the ctx hunk, this shouldn't be needed. Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads
On Fri, 2016-07-15 at 21:20 +1000, Timothy Arceri wrote: > On Fri, 2016-07-15 at 13:16 +0200, Iago Toral wrote: > > > > On Fri, 2016-07-15 at 20:59 +1000, Timothy Arceri wrote: > > > > > > On Fri, 2016-07-15 at 11:04 +0200, Iago Toral Quiroga wrote: > > > > > > > > > > > > We totally ignored this before because there were no piglit > > > > tests > > > > for > > > > indirect loads in tessellation stages with doubles. > > > > > > > > Cc: "12.0"> > > > --- > > > > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86 > > > > > > > > 1 file changed, 64 insertions(+), 22 deletions(-) > > > > > > > > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > > > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > > > index 55383ff..7d5af78 100644 > > > > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > > > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > > > @@ -2926,31 +2926,73 @@ > > > > fs_visitor::nir_emit_tes_intrinsic(const > > > > fs_builder , > > > > } > > > > } else { > > > > /* Indirect indexing - use per-slot offsets as well. > > > > */ > > > > - const fs_reg srcs[] = { > > > > -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), > > > > -indirect_offset > > > > - }; > > > > - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); > > > > - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0); > > > > > > > > - if (first_component != 0) { > > > > -unsigned read_components = > > > > -instr->num_components + first_component; > > > > -fs_reg tmp = bld.vgrf(dest.type, read_components); > > > > -inst = > > > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, > > > > tmp, > > > > -payload); > > > > -inst->regs_written = read_components; > > > > -for (unsigned i = 0; i < instr->num_components; > > > > i++) > > > > { > > > > - bld.MOV(offset(dest, bld, i), > > > > - offset(tmp, bld, i + first_component)); > > > > + /* We can only read two double components with each > > > > URB > > > > read, so > > > > + * we send two read messages in that case, each one > > > > loading > > > > up to > > > > + * two double components. > > > > + */ > > > > + unsigned num_iterations = 1; > > > > + unsigned num_components = instr->num_components; > > > > + fs_reg orig_dest = dest; > > > > + if (type_sz(dest.type) == 8) { > > > Hi, > > > > > > Not your fault as its not currently enabled but can you add the > > > following here to allow component packing to work once it finally > > > gets > > > enabled: > > > > > > first_component = first_component / 2; > > > > > > I believe that should be enought to keep it working once the > > > other > > > patches land. > > I think this is already being done in master, right after the > > assignment to first_component. > Oh yes you are right. All looks good to me then :) great! > > > > > > > > > > Also I don't think this patch is going to apply cleanly to stable > > > as > > > the component packing cahnges only landed after branching. Aha, good point. In that case I think it is probably better to just drop Cc to stable. Thanks! Iago > > > Thanks, > > > Tim > > > > > > > > > > > > > > > +if (instr->num_components > 2) { > > > > + num_iterations = 2; > > > > + num_components = 2; > > > > +} > > > > +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4), > > > > dest.type); > > > > +dest = tmp; > > > > + } > > > > + > > > > + for (unsigned iter = 0; iter < num_iterations; > > > > iter++) > > > > { > > > > +const fs_reg srcs[] = { > > > > + retype(brw_vec1_grf(0, 0), > > > > BRW_REGISTER_TYPE_UD), > > > > + indirect_offset > > > > +}; > > > > +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, > > > > 2); > > > > +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), > > > > 0); > > > > + > > > > +if (first_component != 0) { > > > > + unsigned read_components = > > > > + num_components + first_component; > > > > + fs_reg tmp = bld.vgrf(dest.type, > > > > read_components); > > > > + inst = > > > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp, > > > > + payload); > > > > + for (unsigned i = 0; i < num_components; i++) { > > > > + bld.MOV(offset(dest, bld, i), > > > > + offset(tmp, bld, i + > > > > first_component)); > > > > + } > > > > +} else { > > > > + inst = > > > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest, > > > > +
Re: [Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads
On Fri, 2016-07-15 at 13:16 +0200, Iago Toral wrote: > On Fri, 2016-07-15 at 20:59 +1000, Timothy Arceri wrote: > > On Fri, 2016-07-15 at 11:04 +0200, Iago Toral Quiroga wrote: > > > > > > We totally ignored this before because there were no piglit tests > > > for > > > indirect loads in tessellation stages with doubles. > > > > > > Cc: "12.0"> > > --- > > > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86 > > > > > > 1 file changed, 64 insertions(+), 22 deletions(-) > > > > > > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > > index 55383ff..7d5af78 100644 > > > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > > @@ -2926,31 +2926,73 @@ fs_visitor::nir_emit_tes_intrinsic(const > > > fs_builder , > > > } > > > } else { > > > /* Indirect indexing - use per-slot offsets as well. */ > > > - const fs_reg srcs[] = { > > > -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), > > > -indirect_offset > > > - }; > > > - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); > > > - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0); > > > > > > - if (first_component != 0) { > > > -unsigned read_components = > > > -instr->num_components + first_component; > > > -fs_reg tmp = bld.vgrf(dest.type, read_components); > > > -inst = > > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, > > > tmp, > > > -payload); > > > -inst->regs_written = read_components; > > > -for (unsigned i = 0; i < instr->num_components; i++) > > > { > > > - bld.MOV(offset(dest, bld, i), > > > - offset(tmp, bld, i + first_component)); > > > + /* We can only read two double components with each URB > > > read, so > > > + * we send two read messages in that case, each one > > > loading > > > up to > > > + * two double components. > > > + */ > > > + unsigned num_iterations = 1; > > > + unsigned num_components = instr->num_components; > > > + fs_reg orig_dest = dest; > > > + if (type_sz(dest.type) == 8) { > > Hi, > > > > Not your fault as its not currently enabled but can you add the > > following here to allow component packing to work once it finally > > gets > > enabled: > > > > first_component = first_component / 2; > > > > I believe that should be enought to keep it working once the other > > patches land. > > I think this is already being done in master, right after the > assignment to first_component. Oh yes you are right. All looks good to me then :) > > > Also I don't think this patch is going to apply cleanly to stable > > as > > the component packing cahnges only landed after branching. > > > > Thanks, > > Tim > > > > > > > > +if (instr->num_components > 2) { > > > + num_iterations = 2; > > > + num_components = 2; > > > +} > > > +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4), > > > dest.type); > > > +dest = tmp; > > > + } > > > + > > > + for (unsigned iter = 0; iter < num_iterations; iter++) > > > { > > > +const fs_reg srcs[] = { > > > + retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), > > > + indirect_offset > > > +}; > > > +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); > > > +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), > > > 0); > > > + > > > +if (first_component != 0) { > > > + unsigned read_components = > > > + num_components + first_component; > > > + fs_reg tmp = bld.vgrf(dest.type, > > > read_components); > > > + inst = > > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp, > > > + payload); > > > + for (unsigned i = 0; i < num_components; i++) { > > > + bld.MOV(offset(dest, bld, i), > > > + offset(tmp, bld, i + > > > first_component)); > > > + } > > > +} else { > > > + inst = > > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest, > > > + payload); > > > +} > > > +inst->mlen = 2; > > > +inst->offset = imm_offset; > > > +inst->regs_written = > > > + ((num_components + first_component) * > > > type_sz(dest.type) / 4); > > > + > > > +/* If we are reading 64-bit data using 32-bit read > > > messages we need > > > + * build proper 64-bit data elements by shuffling > > > the > > > low and high > > > + * 32-bit components around like we do
Re: [Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads
On Fri, 2016-07-15 at 20:59 +1000, Timothy Arceri wrote: > On Fri, 2016-07-15 at 11:04 +0200, Iago Toral Quiroga wrote: > > > > We totally ignored this before because there were no piglit tests > > for > > indirect loads in tessellation stages with doubles. > > > > Cc: "12.0"> > --- > > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86 > > > > 1 file changed, 64 insertions(+), 22 deletions(-) > > > > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > index 55383ff..7d5af78 100644 > > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > @@ -2926,31 +2926,73 @@ fs_visitor::nir_emit_tes_intrinsic(const > > fs_builder , > > } > > } else { > > /* Indirect indexing - use per-slot offsets as well. */ > > - const fs_reg srcs[] = { > > -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), > > -indirect_offset > > - }; > > - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); > > - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0); > > > > - if (first_component != 0) { > > -unsigned read_components = > > -instr->num_components + first_component; > > -fs_reg tmp = bld.vgrf(dest.type, read_components); > > -inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, > > tmp, > > -payload); > > -inst->regs_written = read_components; > > -for (unsigned i = 0; i < instr->num_components; i++) { > > - bld.MOV(offset(dest, bld, i), > > - offset(tmp, bld, i + first_component)); > > + /* We can only read two double components with each URB > > read, so > > + * we send two read messages in that case, each one > > loading > > up to > > + * two double components. > > + */ > > + unsigned num_iterations = 1; > > + unsigned num_components = instr->num_components; > > + fs_reg orig_dest = dest; > > + if (type_sz(dest.type) == 8) { > Hi, > > Not your fault as its not currently enabled but can you add the > following here to allow component packing to work once it finally > gets > enabled: > > first_component = first_component / 2; > > I believe that should be enought to keep it working once the other > patches land. I think this is already being done in master, right after the assignment to first_component. > Also I don't think this patch is going to apply cleanly to stable as > the component packing cahnges only landed after branching. > > Thanks, > Tim > > > > > +if (instr->num_components > 2) { > > + num_iterations = 2; > > + num_components = 2; > > +} > > +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4), > > dest.type); > > +dest = tmp; > > + } > > + > > + for (unsigned iter = 0; iter < num_iterations; iter++) { > > +const fs_reg srcs[] = { > > + retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), > > + indirect_offset > > +}; > > +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); > > +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0); > > + > > +if (first_component != 0) { > > + unsigned read_components = > > + num_components + first_component; > > + fs_reg tmp = bld.vgrf(dest.type, read_components); > > + inst = > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp, > > + payload); > > + for (unsigned i = 0; i < num_components; i++) { > > + bld.MOV(offset(dest, bld, i), > > + offset(tmp, bld, i + first_component)); > > + } > > +} else { > > + inst = > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest, > > + payload); > > +} > > +inst->mlen = 2; > > +inst->offset = imm_offset; > > +inst->regs_written = > > + ((num_components + first_component) * > > type_sz(dest.type) / 4); > > + > > +/* If we are reading 64-bit data using 32-bit read > > messages we need > > + * build proper 64-bit data elements by shuffling the > > low and high > > + * 32-bit components around like we do for other > > things > > like UBOs > > + * or SSBOs. > > + */ > > +if (type_sz(dest.type) == 8) { > > + shuffle_32bit_load_result_to_64bit_data( > > + bld, dest, retype(dest, BRW_REGISTER_TYPE_F), > > num_components); > > + > > + for (unsigned c = 0; c < num_components; c++) { > > +
Re: [Mesa-dev] [PATCH] egl/dri2: dri2_make_current: Make sure display is initialized before using it
Whilst I don't know that code as well as I'd like. It does get my Tested-by: Rhys Kiddfor fixing that piglit on i965 ILK. Thanks for the two patches! On 15 July 2016 at 04:28, Nicolas Boichat wrote: > android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls > eglTerminate, followed by eglReleaseThread. In that case, the > display will not be initialized when eglReleaseThread calls > MakeCurrent with NULL parameters, to unbind the context, which > causes a a segfault in drv->API.MakeCurrent (dri2_make_current), > either in glFlush or in a latter call. > > A similar case is observed in this bug: > https://bugs.freedesktop.org/show_bug.cgi?id=69622, where the test > call eglTerminate, then eglMakeCurrent(dpy, NULL, NULL, NULL). > > This patch: > 1. Validates that the display is initialized, if ctx/dsurf/rsurf > are not all NULL. > 2. Does not call glFlush/unBindContext is there is no display. > 3. However, it still goes through the normal path as > drv->API.DestroyContext decrements the reference count on the > context, and frees the structure. > > Cc: "11.2 12.0" > Signed-off-by: Nicolas Boichat > --- > > I did not actually test the case reported on the bug, only the CTS > test, would be nice if someone can try it out (Rhys? Chad?). > > Applies after "egl/dri2: dri2_make_current: Set EGL error if bindContext > fails", but wanted to keep the 2 patches separate as they are different > problems and discussions. > > src/egl/drivers/dri2/egl_dri2.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/src/egl/drivers/dri2/egl_dri2.c > b/src/egl/drivers/dri2/egl_dri2.c > index 2e97d85..3269e52 100644 > --- a/src/egl/drivers/dri2/egl_dri2.c > +++ b/src/egl/drivers/dri2/egl_dri2.c > @@ -1166,7 +1166,8 @@ dri2_destroy_context(_EGLDriver *drv, _EGLDisplay > *disp, _EGLContext *ctx) > struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp); > > if (_eglPutContext(ctx)) { > - dri2_dpy->core->destroyContext(dri2_ctx->dri_context); > + if (dri2_dpy) > + dri2_dpy->core->destroyContext(dri2_ctx->dri_context); >free(dri2_ctx); > } > > @@ -1189,6 +1190,10 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay > *disp, _EGLSurface *dsurf, > __DRIdrawable *ddraw, *rdraw; > __DRIcontext *cctx; > > + /* Check that the display is initialized */ > + if ((ctx != NULL || dsurf != NULL || rsurf != NULL) && !dri2_dpy) > + return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent error"); > + > /* make new bindings */ > if (!_eglBindContext(ctx, dsurf, rsurf, _ctx, _dsurf, > _rsurf)) { >/* _eglBindContext already sets the EGL error (in > _eglCheckMakeCurrent) */ > @@ -1196,14 +1201,14 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay > *disp, _EGLSurface *dsurf, > } > > /* flush before context switch */ > - if (old_ctx && dri2_drv->glFlush) > + if (old_ctx && dri2_dpy && dri2_drv->glFlush) >dri2_drv->glFlush(); > > ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) : NULL; > rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) : NULL; > cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL; > > - if (old_ctx) { > + if (old_ctx && dri2_dpy) { >__DRIcontext *old_cctx = dri2_egl_context(old_ctx)->dri_context; >dri2_dpy->core->unbindContext(old_cctx); > } > @@ -1292,6 +1297,8 @@ static EGLBoolean > dri2_destroy_surface(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSurface *surf) > { > struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy); > + if (!dri2_dpy) > + return EGL_TRUE; > return dri2_dpy->vtbl->destroy_surface(drv, dpy, surf); > } > > -- > 2.8.0.rc3.226.g39d4020 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads
On Fri, 2016-07-15 at 20:59 +1000, Timothy Arceri wrote: > On Fri, 2016-07-15 at 11:04 +0200, Iago Toral Quiroga wrote: > > We totally ignored this before because there were no piglit tests > > for > > indirect loads in tessellation stages with doubles. > > > > Cc: "12.0"> > --- > > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86 > > > > 1 file changed, 64 insertions(+), 22 deletions(-) > > > > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > index 55383ff..7d5af78 100644 > > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > > @@ -2926,31 +2926,73 @@ fs_visitor::nir_emit_tes_intrinsic(const > > fs_builder , > > } > > } else { > > /* Indirect indexing - use per-slot offsets as well. */ > > - const fs_reg srcs[] = { > > -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), > > -indirect_offset > > - }; > > - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); > > - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0); > > > > - if (first_component != 0) { > > -unsigned read_components = > > -instr->num_components + first_component; > > -fs_reg tmp = bld.vgrf(dest.type, read_components); > > -inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, > > tmp, > > -payload); > > -inst->regs_written = read_components; > > -for (unsigned i = 0; i < instr->num_components; i++) { > > - bld.MOV(offset(dest, bld, i), > > - offset(tmp, bld, i + first_component)); > > + /* We can only read two double components with each URB > > read, so > > + * we send two read messages in that case, each one > > loading > > up to > > + * two double components. > > + */ > > + unsigned num_iterations = 1; > > + unsigned num_components = instr->num_components; > > + fs_reg orig_dest = dest; > > + if (type_sz(dest.type) == 8) { > > Hi, > > Not your fault as its not currently enabled but can you add the > following here to allow component packing to work once it finally > gets > enabled: > > first_component = first_component / 2; > > I believe that should be enought to keep it working once the other > patches land. > > Also I don't think this patch is going to apply cleanly to stable as > the component packing cahnges only landed after branching. > > Thanks, > Tim Also for what its worth both patches are: Reviewed-by: Timothy Arceri You may want to wait a little for feedback from others before pushing as I'm still fairly new to this code. > > > +if (instr->num_components > 2) { > > + num_iterations = 2; > > + num_components = 2; > > +} > > +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4), > > dest.type); > > +dest = tmp; > > + } > > + > > + for (unsigned iter = 0; iter < num_iterations; iter++) { > > +const fs_reg srcs[] = { > > + retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), > > + indirect_offset > > +}; > > +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); > > +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0); > > + > > +if (first_component != 0) { > > + unsigned read_components = > > + num_components + first_component; > > + fs_reg tmp = bld.vgrf(dest.type, read_components); > > + inst = > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp, > > + payload); > > + for (unsigned i = 0; i < num_components; i++) { > > + bld.MOV(offset(dest, bld, i), > > + offset(tmp, bld, i + first_component)); > > + } > > +} else { > > + inst = > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest, > > + payload); > > +} > > +inst->mlen = 2; > > +inst->offset = imm_offset; > > +inst->regs_written = > > + ((num_components + first_component) * > > type_sz(dest.type) / 4); > > + > > +/* If we are reading 64-bit data using 32-bit read > > messages we need > > + * build proper 64-bit data elements by shuffling the > > low and high > > + * 32-bit components around like we do for other > > things > > like UBOs > > + * or SSBOs. > > + */ > > +if (type_sz(dest.type) == 8) { > > + shuffle_32bit_load_result_to_64bit_data( > > + bld, dest, retype(dest, BRW_REGISTER_TYPE_F), > >
Re: [Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads
On Fri, 2016-07-15 at 11:04 +0200, Iago Toral Quiroga wrote: > We totally ignored this before because there were no piglit tests for > indirect loads in tessellation stages with doubles. > > Cc: "12.0"> --- > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86 > > 1 file changed, 64 insertions(+), 22 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > index 55383ff..7d5af78 100644 > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > @@ -2926,31 +2926,73 @@ fs_visitor::nir_emit_tes_intrinsic(const > fs_builder , > } > } else { > /* Indirect indexing - use per-slot offsets as well. */ > - const fs_reg srcs[] = { > -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), > -indirect_offset > - }; > - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); > - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0); > > - if (first_component != 0) { > -unsigned read_components = > -instr->num_components + first_component; > -fs_reg tmp = bld.vgrf(dest.type, read_components); > -inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, > tmp, > -payload); > -inst->regs_written = read_components; > -for (unsigned i = 0; i < instr->num_components; i++) { > - bld.MOV(offset(dest, bld, i), > - offset(tmp, bld, i + first_component)); > + /* We can only read two double components with each URB > read, so > + * we send two read messages in that case, each one loading > up to > + * two double components. > + */ > + unsigned num_iterations = 1; > + unsigned num_components = instr->num_components; > + fs_reg orig_dest = dest; > + if (type_sz(dest.type) == 8) { Hi, Not your fault as its not currently enabled but can you add the following here to allow component packing to work once it finally gets enabled: first_component = first_component / 2; I believe that should be enought to keep it working once the other patches land. Also I don't think this patch is going to apply cleanly to stable as the component packing cahnges only landed after branching. Thanks, Tim > +if (instr->num_components > 2) { > + num_iterations = 2; > + num_components = 2; > +} > +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4), dest.type); > +dest = tmp; > + } > + > + for (unsigned iter = 0; iter < num_iterations; iter++) { > +const fs_reg srcs[] = { > + retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), > + indirect_offset > +}; > +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); > +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0); > + > +if (first_component != 0) { > + unsigned read_components = > + num_components + first_component; > + fs_reg tmp = bld.vgrf(dest.type, read_components); > + inst = > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp, > + payload); > + for (unsigned i = 0; i < num_components; i++) { > + bld.MOV(offset(dest, bld, i), > + offset(tmp, bld, i + first_component)); > + } > +} else { > + inst = > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest, > + payload); > +} > +inst->mlen = 2; > +inst->offset = imm_offset; > +inst->regs_written = > + ((num_components + first_component) * > type_sz(dest.type) / 4); > + > +/* If we are reading 64-bit data using 32-bit read > messages we need > + * build proper 64-bit data elements by shuffling the > low and high > + * 32-bit components around like we do for other things > like UBOs > + * or SSBOs. > + */ > +if (type_sz(dest.type) == 8) { > + shuffle_32bit_load_result_to_64bit_data( > + bld, dest, retype(dest, BRW_REGISTER_TYPE_F), > num_components); > + > + for (unsigned c = 0; c < num_components; c++) { > + bld.MOV(offset(orig_dest, bld, iter * 2 + c), > + offset(dest, bld, c)); > + } > +} > + > +/* If we are loading double data and we need a second > read message > + * adjust the offset > + */ > +if (num_iterations > 1) { > + num_components = instr->num_components - 2; > + imm_offset++; >
Re: [Mesa-dev] [PATCH 1/4] genxml: Make gen6-7 blending look more like gen8
On Thursday, July 14, 2016 9:20:05 PM PDT Jason Ekstrand wrote: > This renames BLEND_STATE to BLEND_STATE_ENTRY and adds an new struct > BLEND_STATE which is just an array of 8 BLEND_STATE_ENTRYs. This will make > it much easier to write gen-agnostic blend handling code. > > Signed-off-by: Jason Ekstrand> Cc: "12.0" > --- > src/intel/genxml/gen6.xml| 8 +++- > src/intel/genxml/gen7.xml| 8 +++- > src/intel/genxml/gen75.xml | 8 +++- > src/intel/vulkan/gen7_pipeline.c | 25 + > 4 files changed, 34 insertions(+), 15 deletions(-) The series is: Reviewed-by: Kenneth Graunke though my review on patch 4 is pretty light. signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] VAAPI egl interop on radeon
Hi, I am developing an application which uses vaapi and egl. My goal is to use vaDeriveImage and vaAcquireBufferHandle to get the drm buffer id which then can be used to create a EGLImageKHR. My problem is, that on amd hardware (AMD GX-212ZC SOC with Radeon(TM) R1E Graphics and AMD GX-424CC SOC with Radeon(TM) R5E Graphics) vaDeriveImage fails with "invalid VASurfaceID" and when I do vaGetImage as a fallback to get the image vaAcquireBufferHandle fails with "invalid VABufferID". The same code works on Intel hardware. Mesa version: 11.2.2 - Should this work in general? - Is there any special setting needed? Kind regards Jan Burgmeier ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads
We totally ignored this before because there were no piglit tests for indirect loads in tessellation stages with doubles. Cc: "12.0"--- src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86 1 file changed, 64 insertions(+), 22 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp index 55383ff..7d5af78 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp @@ -2926,31 +2926,73 @@ fs_visitor::nir_emit_tes_intrinsic(const fs_builder , } } else { /* Indirect indexing - use per-slot offsets as well. */ - const fs_reg srcs[] = { -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), -indirect_offset - }; - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0); - if (first_component != 0) { -unsigned read_components = -instr->num_components + first_component; -fs_reg tmp = bld.vgrf(dest.type, read_components); -inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp, -payload); -inst->regs_written = read_components; -for (unsigned i = 0; i < instr->num_components; i++) { - bld.MOV(offset(dest, bld, i), - offset(tmp, bld, i + first_component)); + /* We can only read two double components with each URB read, so + * we send two read messages in that case, each one loading up to + * two double components. + */ + unsigned num_iterations = 1; + unsigned num_components = instr->num_components; + fs_reg orig_dest = dest; + if (type_sz(dest.type) == 8) { +if (instr->num_components > 2) { + num_iterations = 2; + num_components = 2; +} +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4), dest.type); +dest = tmp; + } + + for (unsigned iter = 0; iter < num_iterations; iter++) { +const fs_reg srcs[] = { + retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD), + indirect_offset +}; +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2); +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0); + +if (first_component != 0) { + unsigned read_components = + num_components + first_component; + fs_reg tmp = bld.vgrf(dest.type, read_components); + inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp, + payload); + for (unsigned i = 0; i < num_components; i++) { + bld.MOV(offset(dest, bld, i), + offset(tmp, bld, i + first_component)); + } +} else { + inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest, + payload); +} +inst->mlen = 2; +inst->offset = imm_offset; +inst->regs_written = + ((num_components + first_component) * type_sz(dest.type) / 4); + +/* If we are reading 64-bit data using 32-bit read messages we need + * build proper 64-bit data elements by shuffling the low and high + * 32-bit components around like we do for other things like UBOs + * or SSBOs. + */ +if (type_sz(dest.type) == 8) { + shuffle_32bit_load_result_to_64bit_data( + bld, dest, retype(dest, BRW_REGISTER_TYPE_F), num_components); + + for (unsigned c = 0; c < num_components; c++) { + bld.MOV(offset(orig_dest, bld, iter * 2 + c), + offset(dest, bld, c)); + } +} + +/* If we are loading double data and we need a second read message + * adjust the offset + */ +if (num_iterations > 1) { + num_components = instr->num_components - 2; + imm_offset++; } - } else { -inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest, -payload); -inst->regs_written = instr->num_components; } - inst->mlen = 2; - inst->offset = imm_offset; } break; } -- 2.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965/tcs/scalar: only update imm_offset for second message in 64bit input loads
Our indirect URB read messages take both a direct and an indirect offset so when we emit the second message for a 64-bit input load we can just always incremement the immediate offset, even for the indirect case. --- src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp index 129984a..55383ff 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp @@ -2507,13 +2507,7 @@ fs_visitor::nir_emit_tcs_intrinsic(const fs_builder , */ if (num_iterations > 1) { num_components = instr->num_components - 2; -if (indirect_offset.file == BAD_FILE) { - imm_offset++; -} else { - fs_reg new_indirect = bld.vgrf(BRW_REGISTER_TYPE_UD, 1); - bld.ADD(new_indirect, indirect_offset, brw_imm_ud(1u)); - indirect_offset = new_indirect; -} +imm_offset++; } } break; -- 2.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] main/shaderimage: image unit is invalid if texture is incomplete
From the OpenGL 4.3 Core Specification, section 8.25 ("Texture Image Loads and Stores"): "An access is considered invalid if: the texture bound to the selected image unit is incomplete;" This fixes: GL44-CTS.shader_image_load_store.incomplete_textures v2: use _mesa_is_texture_complete, maintain image-texture level checks (Curro) --- src/mesa/main/shaderimage.c | 9 + 1 file changed, 9 insertions(+) diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c index 90643c4..94bb1e4 100644 --- a/src/mesa/main/shaderimage.c +++ b/src/mesa/main/shaderimage.c @@ -469,6 +469,15 @@ _mesa_is_image_unit_valid(struct gl_context *ctx, struct gl_image_unit *u) if (!t->_BaseComplete && !t->_MipmapComplete) _mesa_test_texobj_completeness(ctx, t); + /* From the OpenGL 4.3 Core Specification, Chapter 8.25, Texture Image +* Loads and Stores: +* +* "An access is considered invalid if: +*the texture bound to the selected image unit is incomplete;" +*/ + if (!_mesa_is_texture_complete(t, >Sampler)) + return GL_FALSE; + if (u->Level < t->BaseLevel || u->Level > t->_MaxLevel || (u->Level == t->BaseLevel && !t->_BaseComplete) || -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] main/shaderimage: image unit invalid if texture is incomplete, independently of the level
On 14/07/16 21:24, Francisco Jerez wrote: > Alejandro Piñeirowrites: > >> Without this commit, a image is considered valid if the level of the >> texture bound to the image is complete, something we can check as mesa >> save independently if it is "base incomplete" of "mipmap incomplete". >> >> But, from the OpenGL 4.3 Core Specification, section 8.25 ("Texture >> Image Loads and Stores"): >> >> "An access is considered invalid if: >> the texture bound to the selected image unit is incomplete;" >> >> This implies that the access to the image unit is invalid if the >> texture is incomplete, no mattering details about the specific texture >> level bound to the image. >> >> This fixes: >> GL44-CTS.shader_image_load_store.incomplete_textures >> --- >> >> Current piglit test is not testing what this commit tries to fix. I >> will send a patch to piglit in short. >> >> src/mesa/main/shaderimage.c | 14 +++--- >> 1 file changed, 11 insertions(+), 3 deletions(-) >> >> diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c >> index 90643c4..d20cd90 100644 >> --- a/src/mesa/main/shaderimage.c >> +++ b/src/mesa/main/shaderimage.c >> @@ -469,10 +469,18 @@ _mesa_is_image_unit_valid(struct gl_context *ctx, >> struct gl_image_unit *u) >> if (!t->_BaseComplete && !t->_MipmapComplete) >> _mesa_test_texobj_completeness(ctx, t); >> >> + /* From the OpenGL 4.3 Core Specification, Chapter 8.25, Texture Image >> +* Loads and Stores: >> +* >> +* "An access is considered invalid if: >> +*the texture bound to the selected image unit is incomplete;" >> +*/ >> + if (!t->_BaseComplete || >> + !t->_MipmapComplete) >> + return GL_FALSE; > I don't think this is correct, AFAIUI a texture having _MipmapComplete > equal to false doesn't imply that the texture as a whole would be > considered incomplete according to the GL's definition of completeness. > Whether or not it's considered complete usually depends on the sampler > state while you're doing regular texture sampling: If the sampler a > texture object is used with has any of the mipmap filtering modes > enabled you need to check _MipmapComplete, otherwise you need to check > _BaseComplete. The problem when you attempt to carry over this > definition to shader images (as the spec implies) is that image units > have no sampler state as such, and that they can only ever access one > specified level of the texture at a time (potentially a texture level > other than the base). This patch makes image units behave like a > sampler unit with mipmap filtering enabled for the purpose of texture > completeness validation, which is almost definitely too strong. Yes, I didn't realize that _BaseComplete and _MipmapComplete were not checking the state at all. Thanks for pointing it. > An alternative would be to do something along the lines of: > > | if (!_mesa_is_texture_complete(t, >Sampler)) > |return GL_FALSE; Yes, that is what I wanted, to return false if the texture is incomplete. > > The problem is that you would then run into problems when some of the > non-base mipmap levels are missing but the sampler state baked into the > gl_texture_object says that you aren't mipmapping, so the GL spec would > normally consider the texture to be complete and > _mesa_is_texture_complete would return true accordingly, but still you > wouldn't be able to use any of the missing texture levels as shader > image if the application tried to bind them to an image unit (that's the > reason for the u->Level vs t->BaseLevel checks below you're removing). Ok, then if I understand correctly, the solution is not about replacing the level checks for _mesa_is_texture_complete, but keeping current checks, and add a _mesa_is_texture_complete check. Just checked and everything seems to work fine (except that now the behaviour is more strict, see below). I will send a patch in short. > Honestly I think the current definition of image unit completeness is > broken, because it considers the image unit state to be complete in > cases where the image unit state is unusable (because the target image > level may be missing even though the texture object itself is considered > complete), and because it considers it to be incomplete in cases where > you really have no reason to care (e.g. why should you care what the > filtering mode from the sampler state says if you aren't doing any > filtering at all, as long as the one level you've bound to the image > unit is present and complete). Well, yes in general the spec is being perhaps too strict. But I assume that if we want to follow the spec, we don't have any other option. FWIW, when testing the patch I mentioned before, some of the piglit tests start to fail. The reason is that with that patch everything is more strict, so the piglit tests need to set the filtering to NEAREST in order to not fail. I will send a piglit patch soon too. > >> + >> if
[Mesa-dev] [PATCH] egl/dri2: dri2_make_current: Make sure display is initialized before using it
android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls eglTerminate, followed by eglReleaseThread. In that case, the display will not be initialized when eglReleaseThread calls MakeCurrent with NULL parameters, to unbind the context, which causes a a segfault in drv->API.MakeCurrent (dri2_make_current), either in glFlush or in a latter call. A similar case is observed in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=69622, where the test call eglTerminate, then eglMakeCurrent(dpy, NULL, NULL, NULL). This patch: 1. Validates that the display is initialized, if ctx/dsurf/rsurf are not all NULL. 2. Does not call glFlush/unBindContext is there is no display. 3. However, it still goes through the normal path as drv->API.DestroyContext decrements the reference count on the context, and frees the structure. Cc: "11.2 12.0"Signed-off-by: Nicolas Boichat --- I did not actually test the case reported on the bug, only the CTS test, would be nice if someone can try it out (Rhys? Chad?). Applies after "egl/dri2: dri2_make_current: Set EGL error if bindContext fails", but wanted to keep the 2 patches separate as they are different problems and discussions. src/egl/drivers/dri2/egl_dri2.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index 2e97d85..3269e52 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -1166,7 +1166,8 @@ dri2_destroy_context(_EGLDriver *drv, _EGLDisplay *disp, _EGLContext *ctx) struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp); if (_eglPutContext(ctx)) { - dri2_dpy->core->destroyContext(dri2_ctx->dri_context); + if (dri2_dpy) + dri2_dpy->core->destroyContext(dri2_ctx->dri_context); free(dri2_ctx); } @@ -1189,6 +1190,10 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *dsurf, __DRIdrawable *ddraw, *rdraw; __DRIcontext *cctx; + /* Check that the display is initialized */ + if ((ctx != NULL || dsurf != NULL || rsurf != NULL) && !dri2_dpy) + return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent error"); + /* make new bindings */ if (!_eglBindContext(ctx, dsurf, rsurf, _ctx, _dsurf, _rsurf)) { /* _eglBindContext already sets the EGL error (in _eglCheckMakeCurrent) */ @@ -1196,14 +1201,14 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *dsurf, } /* flush before context switch */ - if (old_ctx && dri2_drv->glFlush) + if (old_ctx && dri2_dpy && dri2_drv->glFlush) dri2_drv->glFlush(); ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) : NULL; rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) : NULL; cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL; - if (old_ctx) { + if (old_ctx && dri2_dpy) { __DRIcontext *old_cctx = dri2_egl_context(old_ctx)->dri_context; dri2_dpy->core->unbindContext(old_cctx); } @@ -1292,6 +1297,8 @@ static EGLBoolean dri2_destroy_surface(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSurface *surf) { struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy); + if (!dri2_dpy) + return EGL_TRUE; return dri2_dpy->vtbl->destroy_surface(drv, dpy, surf); } -- 2.8.0.rc3.226.g39d4020 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] egl/dri2: dri2_make_current: Set EGL error if bindContext fails
From: Nicolas BoichatWithout this, if a configuration is, say, available only on GLES2/3, but not on GLES1, and is rejected by the dri module's bindContext call, eglMakeCurrent fails with error "EGL_SUCCESS". In this patch, we set error to EGL_BAD_MATCH, which is what CTS/dEQP dEQP-EGL.functional.surfaceless_context expect. Cc: "11.2 12.0" Signed-off-by: Nicolas Boichat --- Emil: Took the opportunity to at least document where eglError is set. I guess, in an ideal world, functions returning EGLBoolean should be annotated to tell if they set (or not) the EGL error, so that callers know what to do on error. src/egl/drivers/dri2/egl_dri2.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index bfde640..2e97d85 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -1190,8 +1190,10 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *dsurf, __DRIcontext *cctx; /* make new bindings */ - if (!_eglBindContext(ctx, dsurf, rsurf, _ctx, _dsurf, _rsurf)) + if (!_eglBindContext(ctx, dsurf, rsurf, _ctx, _dsurf, _rsurf)) { + /* _eglBindContext already sets the EGL error (in _eglCheckMakeCurrent) */ return EGL_FALSE; + } /* flush before context switch */ if (old_ctx && dri2_drv->glFlush) @@ -1231,7 +1233,11 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *dsurf, _eglPutSurface(old_rsurf); _eglPutContext(old_ctx); - return EGL_FALSE; + /* dri2_dpy->core->bindContext failed. We cannot tell for sure why, but + * setting the error to EGL_BAD_MATCH is surely better than leaving it + * as EGL_SUCCESS. + */ + return _eglError(EGL_BAD_MATCH, "eglMakeCurrent"); } } -- 2.8.0.rc3.226.g39d4020 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl/dri2: dri2_make_current: Set EGL error if bindContext fails
Please ignore this patch, I'll resend along with some slightly improved/annotated EGL error handling. On Thu, Jul 14, 2016 at 12:22 PM, Nicolas Boichatwrote: > From: Nicolas Boichat > > Without this, if a configuration is, say, available only on GLES2/3, but > not on GLES1, and is rejected by the dri module's bindContext call, > eglMakeCurrent fails with error "EGL_SUCCESS". > > In this patch, we set error to EGL_BAD_MATCH, which is what CTS/dEQP > dEQP-EGL.functional.surfaceless_context expect. > > Cc: "11.2 12.0" > Signed-off-by: Nicolas Boichat > Reviewed-by: Emil Velikov > --- > src/egl/drivers/dri2/egl_dri2.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c > index bfde640..3cbdd0a 100644 > --- a/src/egl/drivers/dri2/egl_dri2.c > +++ b/src/egl/drivers/dri2/egl_dri2.c > @@ -1231,6 +1231,7 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, > _EGLSurface *dsurf, >_eglPutSurface(old_rsurf); >_eglPutContext(old_ctx); > > + _eglError(EGL_BAD_MATCH, "eglMakeCurrent error"); I think you meant I should use "eglMakeCurrent" as error string. >return EGL_FALSE; > } > } > -- > 2.8.0.rc3.226.g39d4020 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/10] egl/android: Add fallback to kms_swrast driver
If no hardware driver is present, it is possible to fall back to the kms_swrast driver with any DRI node that supports dumb GEM create and mmap IOCTLs with softpipe/llvmpipe drivers. This patch makes the Android EGL platform code retry probe with kms_swrast if hardware-only probe fails. Signed-off-by: Tomasz Figa--- src/egl/drivers/dri2/platform_android.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/src/egl/drivers/dri2/platform_android.c b/src/egl/drivers/dri2/platform_android.c index 9c8156c..f0afca1 100644 --- a/src/egl/drivers/dri2/platform_android.c +++ b/src/egl/drivers/dri2/platform_android.c @@ -870,11 +870,14 @@ droid_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay *dpy) } static int -droid_probe_device(_EGLDisplay *dpy, int fd) +droid_probe_device(_EGLDisplay *dpy, int fd, int swrast) { struct dri2_egl_display *dri2_dpy = dpy->DriverData; - dri2_dpy->driver_name = loader_get_driver_for_fd(fd, 0); + if (swrast) + dri2_dpy->driver_name = strdup("kms_swrast"); + else + dri2_dpy->driver_name = loader_get_driver_for_fd(fd, 0); if (!dri2_dpy->driver_name) return -1; @@ -891,7 +894,7 @@ droid_probe_device(_EGLDisplay *dpy, int fd) #ifdef HAS_GRALLOC_DRM_HEADERS static int -droid_open_device(_EGLDisplay *dpy) +droid_open_device(_EGLDisplay *dpy, int swrast) { const hw_module_t *mod; int fd = -1, err; @@ -909,13 +912,13 @@ droid_open_device(_EGLDisplay *dpy) return -1; } - return droid_probe_device(dpy, fd); + return droid_probe_device(dpy, fd, swrast); } #else #define DRM_RENDER_DEV_NAME "%s/renderD%d" static int -droid_open_device(_EGLDisplay *dpy) +droid_open_device(_EGLDisplay *dpy, int swrast) { struct dri2_egl_display *dri2_dpy = dpy->DriverData; const int limit = 64; @@ -933,7 +936,7 @@ droid_open_device(_EGLDisplay *dpy) if (fd < 0) continue; - if (!droid_probe_device(dpy, fd)) + if (!droid_probe_device(dpy, fd, swrast)) return 0; } @@ -1015,9 +1018,11 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay *dpy) dpy->DriverData = (void *) dri2_dpy; - if (droid_open_device(dpy) < 0) { - err = "DRI2: failed to open device"; - goto cleanup_display; + if (droid_open_device(dpy, 0) < 0) { + if (droid_open_device(dpy, 1) < 0) { + err = "DRI2: failed to open device"; + goto cleanup_display; + } } dri2_dpy->is_render_node = drmGetNodeTypeFromFd(dri2_dpy->fd) == DRM_NODE_RENDER; -- 2.8.0.rc3.226.g39d4020 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/10] egl/android: Make drm_gralloc headers optional
We can support render nodes alone without any private headers, so let's make support for control nodes depend on presence of private drm_gralloc headers. Signed-off-by: Tomasz Figa--- src/egl/Android.mk | 1 + src/egl/drivers/dri2/egl_dri2.h | 2 + src/egl/drivers/dri2/platform_android.c | 194 ++-- 3 files changed, 138 insertions(+), 59 deletions(-) diff --git a/src/egl/Android.mk b/src/egl/Android.mk index bfd56a7..72ec02a 100644 --- a/src/egl/Android.mk +++ b/src/egl/Android.mk @@ -41,6 +41,7 @@ LOCAL_SRC_FILES := \ LOCAL_CFLAGS := \ -D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_ANDROID \ -D_EGL_BUILT_IN_DRIVER_DRI2 \ + -DHAS_GRALLOC_DRM_HEADERS \ -DHAVE_ANDROID_PLATFORM LOCAL_C_INCLUDES := \ diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h index 3ffc177..6f9623b 100644 --- a/src/egl/drivers/dri2/egl_dri2.h +++ b/src/egl/drivers/dri2/egl_dri2.h @@ -65,7 +65,9 @@ #endif #include +#ifdef HAS_GRALLOC_DRM_HEADERS #include +#endif #include #endif /* HAVE_ANDROID_PLATFORM */ diff --git a/src/egl/drivers/dri2/platform_android.c b/src/egl/drivers/dri2/platform_android.c index 0f707dd..4473400 100644 --- a/src/egl/drivers/dri2/platform_android.c +++ b/src/egl/drivers/dri2/platform_android.c @@ -38,7 +38,10 @@ #include "loader.h" #include "egl_dri2.h" #include "egl_dri2_fallbacks.h" + +#ifdef HAS_GRALLOC_DRM_HEADERS #include "gralloc_drm.h" +#endif static int get_format_bpp(int native) @@ -104,11 +107,13 @@ get_native_buffer_fd(struct ANativeWindowBuffer *buf) return (handle && handle->numFds) ? handle->data[0] : -1; } +#ifdef HAS_GRALLOC_DRM_HEADERS static int get_native_buffer_name(struct ANativeWindowBuffer *buf) { return gralloc_drm_get_gem_handle(buf->handle); } +#endif static EGLBoolean droid_window_dequeue_buffer(struct dri2_egl_surface *dri2_surf) @@ -210,6 +215,7 @@ droid_window_cancel_buffer(_EGLDisplay *disp, struct dri2_egl_surface *dri2_surf droid_window_enqueue_buffer(disp, dri2_surf); } +#ifdef HAS_GRALLOC_DRM_HEADERS static __DRIbuffer * droid_alloc_local_buffer(struct dri2_egl_surface *dri2_surf, unsigned int att, unsigned int format) @@ -228,6 +234,7 @@ droid_alloc_local_buffer(struct dri2_egl_surface *dri2_surf, return dri2_surf->local_buffers[att]; } +#endif static void droid_free_local_buffers(struct dri2_egl_surface *dri2_surf) @@ -509,53 +516,43 @@ droid_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *draw) } static _EGLImage * -dri2_create_image_android_native_buffer(_EGLDisplay *disp, -_EGLContext *ctx, -struct ANativeWindowBuffer *buf) +droid_create_image_from_prime_fd(_EGLDisplay *disp, _EGLContext *ctx, + struct ANativeWindowBuffer *buf) { - struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp); - struct dri2_egl_image *dri2_img; - int name, fd; - int format; - - if (ctx != NULL) { - /* From the EGL_ANDROID_image_native_buffer spec: - * - * * If is EGL_NATIVE_BUFFER_ANDROID and is not - * EGL_NO_CONTEXT, the error EGL_BAD_CONTEXT is generated. - */ - _eglError(EGL_BAD_CONTEXT, "eglCreateEGLImageKHR: for " -"EGL_NATIVE_BUFFER_ANDROID, the context must be " -"EGL_NO_CONTEXT"); - return NULL; - } - - if (!buf || buf->common.magic != ANDROID_NATIVE_BUFFER_MAGIC || - buf->common.version != sizeof(*buf)) { - _eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR"); - return NULL; - } + int fd; fd = get_native_buffer_fd(buf); - if (fd >= 0) { - const int fourcc = get_fourcc(get_format(buf->format)); - const int pitch = buf->stride * get_format_bpp(buf->format); + if (fd < 0) + return NULL; + + const int fourcc = get_fourcc(get_format(buf->format)); + const int pitch = buf->stride * get_format_bpp(buf->format); + + const EGLint attr_list[14] = { + EGL_WIDTH, buf->width, + EGL_HEIGHT, buf->height, + EGL_LINUX_DRM_FOURCC_EXT, fourcc, + EGL_DMA_BUF_PLANE0_FD_EXT, fd, + EGL_DMA_BUF_PLANE0_PITCH_EXT, pitch, + EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0, + EGL_NONE, 0 + }; - const EGLint attr_list[14] = { - EGL_WIDTH, buf->width, - EGL_HEIGHT, buf->height, - EGL_LINUX_DRM_FOURCC_EXT, fourcc, - EGL_DMA_BUF_PLANE0_FD_EXT, fd, - EGL_DMA_BUF_PLANE0_PITCH_EXT, pitch, - EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0, - EGL_NONE, 0 - }; + if (fourcc == -1 || pitch == 0) + return NULL; - if (fourcc == -1 || pitch == 0) - return NULL; + return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list); +} - return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list); - } +static _EGLImage *
[Mesa-dev] [PATCH 09/10] egl/android: Add support for YV12 pixel format
This patch adds support for YV12 pixel format to the Android platform backend. Only creating EGL images is supported, it is not added to the list of available visuals. Signed-off-by: Tomasz FigaSigned-off-by: Kalyan Kondapally --- src/egl/drivers/dri2/platform_android.c | 82 - 1 file changed, 70 insertions(+), 12 deletions(-) diff --git a/src/egl/drivers/dri2/platform_android.c b/src/egl/drivers/dri2/platform_android.c index 26d7b35..9c8156c 100644 --- a/src/egl/drivers/dri2/platform_android.c +++ b/src/egl/drivers/dri2/platform_android.c @@ -43,6 +43,8 @@ #include "gralloc_drm.h" #endif +#define ALIGN(val, align) (((val) + (align) - 1) & ~((align) - 1)) + static int get_format_bpp(int native) { @@ -60,6 +62,9 @@ get_format_bpp(int native) case HAL_PIXEL_FORMAT_RGB_565: bpp = 2; break; + case HAL_PIXEL_FORMAT_YV12: + bpp = 1; + break; default: bpp = 0; break; @@ -76,6 +81,7 @@ static int get_fourcc(int native) case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FOURCC_ARGB; case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FOURCC_ABGR; case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR; + case HAL_PIXEL_FORMAT_YV12: return __DRI_IMAGE_FOURCC_YVU420; default: _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", native); } @@ -523,6 +529,10 @@ static _EGLImage * droid_create_image_from_prime_fd(_EGLDisplay *disp, _EGLContext *ctx, struct ANativeWindowBuffer *buf) { + unsigned int offsets[3] = { 0, 0, 0 }; + unsigned int pitches[3] = { 0, 0, 0 }; + unsigned int total_planes = 1; + int p, index; int fd; fd = get_native_buffer_fd(buf); @@ -530,21 +540,69 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp, _EGLContext *ctx, return NULL; const int fourcc = get_fourcc(buf->format); - const int pitch = buf->stride * get_format_bpp(buf->format); - - const EGLint attr_list[14] = { - EGL_WIDTH, buf->width, - EGL_HEIGHT, buf->height, - EGL_LINUX_DRM_FOURCC_EXT, fourcc, - EGL_DMA_BUF_PLANE0_FD_EXT, fd, - EGL_DMA_BUF_PLANE0_PITCH_EXT, pitch, - EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0, - EGL_NONE, 0 - }; + pitches[0] = buf->stride * get_format_bpp(buf->format); - if (fourcc == -1 || pitch == 0) + if (fourcc == -1 || pitches[0] == 0) return NULL; + switch (buf->format) { + case HAL_PIXEL_FORMAT_YV12: + /* Y plane is at offset 0 and fds[0] is already set. */ + /* Cr plane is located after Y plane */ + offsets[1] = offsets[0] + pitches[0] * buf->height; + pitches[1] = ALIGN(pitches[0] / 2, 16); + /* Cb plane is located after Cr plane */ + offsets[2] = offsets[1] + pitches[1] * buf->height / 2; + pitches[2] = pitches[1]; + total_planes = 3; + break; + default: + break; + } + + /* TODO: Do we need to pass in the following or defaults suffice: +* EGL_YUV_COLOR_SPACE_HINT_EXT, +* EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT, +* EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT +*/ + EGLint plane_fd_attr[] = { + EGL_DMA_BUF_PLANE0_FD_EXT, + EGL_DMA_BUF_PLANE1_FD_EXT, + EGL_DMA_BUF_PLANE2_FD_EXT, + }; + + EGLint plane_pitch_attr[] = { + EGL_DMA_BUF_PLANE0_PITCH_EXT, + EGL_DMA_BUF_PLANE1_PITCH_EXT, + EGL_DMA_BUF_PLANE2_PITCH_EXT, + }; + + EGLint plane_offset_attr[] = { + EGL_DMA_BUF_PLANE0_OFFSET_EXT, + EGL_DMA_BUF_PLANE1_OFFSET_EXT, + EGL_DMA_BUF_PLANE2_OFFSET_EXT, + }; + + EGLint attr_list[25]; + attr_list[0] = EGL_WIDTH; + attr_list[1] = buf->width; + attr_list[2] = EGL_HEIGHT; + attr_list[3] = buf->height; + attr_list[4] = EGL_LINUX_DRM_FOURCC_EXT; + attr_list[5] = fourcc; + index = 5; + + for (p = 0; p < total_planes; ++p) { + attr_list[++index] = plane_fd_attr[p]; + attr_list[++index] = fd; + attr_list[++index] = plane_pitch_attr[p]; + attr_list[++index] = pitches[p]; + attr_list[++index] = plane_offset_attr[p]; + attr_list[++index] = offsets[p]; + } + + attr_list[++index] = EGL_NONE; + return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list); } -- 2.8.0.rc3.226.g39d4020 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/10] egl/android: Make get_fourcc() accept HAL formats
There are DRI_IMAGE_FOURCC macros, for which there are no corresponding DRI_IMAGE_FORMAT macros. To support such formats we need to make the lookup function take the native format directly. As a side effect, it simplifies all existing calls to this function, because they all called get_format() first to convert from native to DRI_IMAGE_FORMAT. Signed-off-by: Tomasz Figa--- src/egl/drivers/dri2/platform_android.c | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/src/egl/drivers/dri2/platform_android.c b/src/egl/drivers/dri2/platform_android.c index 4473400..26d7b35 100644 --- a/src/egl/drivers/dri2/platform_android.c +++ b/src/egl/drivers/dri2/platform_android.c @@ -69,18 +69,20 @@ get_format_bpp(int native) } /* createImageFromFds requires fourcc format */ -static int get_fourcc(int format) +static int get_fourcc(int native) { - switch(format) { - case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565; - case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB; - case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB; - case __DRI_IMAGE_FORMAT_ABGR: return __DRI_IMAGE_FOURCC_ABGR; - case __DRI_IMAGE_FORMAT_XBGR: return __DRI_IMAGE_FOURCC_XBGR; + switch (native) { + case HAL_PIXEL_FORMAT_RGB_565: return __DRI_IMAGE_FOURCC_RGB565; + case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FOURCC_ARGB; + case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FOURCC_ABGR; + case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR; + default: + _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", native); } return -1; } +#ifdef HAS_GRALLOC_DRM_HEADERS static int get_format(int format) { switch (format) { @@ -95,6 +97,8 @@ static int get_format(int format) } return -1; } +#endif + static int get_native_buffer_fd(struct ANativeWindowBuffer *buf) { @@ -435,7 +439,7 @@ get_back_bo(struct dri2_egl_surface *dri2_surf) return -1; } - fourcc = get_fourcc(get_format(dri2_surf->buffer->format)); + fourcc = get_fourcc(dri2_surf->buffer->format); pitch = dri2_surf->buffer->stride * get_format_bpp(dri2_surf->buffer->format); @@ -525,7 +529,7 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp, _EGLContext *ctx, if (fd < 0) return NULL; - const int fourcc = get_fourcc(get_format(buf->format)); + const int fourcc = get_fourcc(buf->format); const int pitch = buf->stride * get_format_bpp(buf->format); const EGLint attr_list[14] = { -- 2.8.0.rc3.226.g39d4020 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] egl/android: Fix support for pbuffers
From: Nicolas BoichatExisting image loader code supports creating images only for window surfaces. Moreover droid_create_surface() passes wrong surface type to dri2_get_dri_config(), resulting in incorrect configs being returned for pbuffers. This patch fixes these issues. In addition, the config generation code is fixed to include single buffered contexts required for pbuffers and make sure that generated configs support only surfaces which can handle their supported buffering modes. Signed-off-by: Nicolas Boichat Signed-off-by: Tomasz Figa --- src/egl/drivers/dri2/egl_dri2.h | 1 + src/egl/drivers/dri2/platform_android.c | 61 +++-- 2 files changed, 51 insertions(+), 11 deletions(-) diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h index 317de06..3ffc177 100644 --- a/src/egl/drivers/dri2/egl_dri2.h +++ b/src/egl/drivers/dri2/egl_dri2.h @@ -287,6 +287,7 @@ struct dri2_egl_surface struct ANativeWindow *window; struct ANativeWindowBuffer *buffer; __DRIimage *dri_image; + __DRIimage *dri_front_image; /* EGL-owned buffers */ __DRIbuffer *local_buffers[__DRI_BUFFER_COUNT]; diff --git a/src/egl/drivers/dri2/platform_android.c b/src/egl/drivers/dri2/platform_android.c index 7495445..0f707dd 100644 --- a/src/egl/drivers/dri2/platform_android.c +++ b/src/egl/drivers/dri2/platform_android.c @@ -286,7 +286,7 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp, EGLint type, window->query(window, NATIVE_WINDOW_HEIGHT, _surf->base.Height); } - config = dri2_get_dri_config(dri2_conf, EGL_WINDOW_BIT, + config = dri2_get_dri_config(dri2_conf, type, dri2_surf->base.GLColorspace); if (!config) goto cleanup_surface; @@ -347,6 +347,9 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *surf) dri2_surf->window->common.decRef(_surf->window->common); } + if (dri2_surf->dri_front_image) + dri2_dpy->image->destroyImage(dri2_surf->dri_front_image); + (*dri2_dpy->core->destroyDrawable)(dri2_surf->dri_drawable); free(dri2_surf); @@ -378,6 +381,29 @@ update_buffers(struct dri2_egl_surface *dri2_surf) } static int +get_front_bo(struct dri2_egl_surface *dri2_surf, unsigned int format) +{ + struct dri2_egl_display *dri2_dpy = + dri2_egl_display(dri2_surf->base.Resource.Display); + + if (dri2_surf->base.Type == EGL_WINDOW_BIT) { + _eglLog(_EGL_WARNING, "Front buffer is not supported for window surfaces"); + return -1; + } + + if (dri2_surf->dri_front_image) + return 0; + + dri2_surf->dri_front_image = + dri2_dpy->image->createImage(dri2_dpy->dri_screen, + dri2_surf->base.Width, + dri2_surf->base.Height, + format, 0, dri2_surf); + + return dri2_surf->dri_front_image ? 0 : -1; +} + +static int get_back_bo(struct dri2_egl_surface *dri2_surf) { struct dri2_egl_display *dri2_dpy = @@ -385,6 +411,11 @@ get_back_bo(struct dri2_egl_surface *dri2_surf) int fourcc, pitch; int offset = 0, fd; + if (dri2_surf->base.Type != EGL_WINDOW_BIT) { + _eglLog(_EGL_WARNING, "Back buffer is not supported for pbuffer surfaces"); + return -1; + } + if (dri2_surf->dri_image) return 0; @@ -440,8 +471,11 @@ droid_image_get_buffers(__DRIdrawable *driDrawable, return 0; if (buffer_mask & __DRI_IMAGE_BUFFER_FRONT) { - _eglLog(_EGL_WARNING, "Front buffer is not supported for window surfaces"); - return 0; + if (get_front_bo(dri2_surf, format) < 0) + return 0; + + images->front = dri2_surf->dri_front_image; + images->image_mask |= __DRI_IMAGE_BUFFER_FRONT; } if (buffer_mask & __DRI_IMAGE_BUFFER_BACK) { @@ -698,14 +732,6 @@ droid_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay *dpy) for (j = 0; dri2_dpy->driver_configs[j]; j++) { const EGLint surface_type = EGL_WINDOW_BIT | EGL_PBUFFER_BIT; struct dri2_egl_config *dri2_conf; - unsigned int double_buffered = 0; - - dri2_dpy->core->getConfigAttrib(dri2_dpy->driver_configs[j], -__DRI_ATTRIB_DOUBLE_BUFFER, _buffered); - - /* support only double buffered configs */ - if (!double_buffered) -continue; dri2_conf = dri2_add_config(dpy, dri2_dpy->driver_configs[j], count + 1, surface_type, config_attrs, visuals[i].rgba_masks); @@ -728,6 +754,19 @@ droid_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay *dpy) /* there is no front buffer so no OpenGL */ dri2_conf->base.RenderableType &= ~EGL_OPENGL_BIT; dri2_conf->base.Conformant &= ~EGL_OPENGL_BIT; + + for (j = 0; j < 2; j++) { + /* Unsupported color space variants should not affect surface
[Mesa-dev] [PATCH 01/10] egl/android: Set EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT
From: Haixia ShiSet config attributes EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT to hard-coded non-zero values. These two attributes are required on Android. Signed-off-by: Tomasz Figa --- src/egl/drivers/dri2/platform_android.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/egl/drivers/dri2/platform_android.c b/src/egl/drivers/dri2/platform_android.c index b33f4e8..f42febc 100644 --- a/src/egl/drivers/dri2/platform_android.c +++ b/src/egl/drivers/dri2/platform_android.c @@ -655,6 +655,8 @@ droid_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay *dpy) EGL_NATIVE_VISUAL_TYPE, 0, EGL_FRAMEBUFFER_TARGET_ANDROID, EGL_TRUE, EGL_RECORDABLE_ANDROID, EGL_TRUE, + EGL_MAX_PBUFFER_WIDTH, 4096, + EGL_MAX_PBUFFER_HEIGHT, 4096, EGL_NONE }; int count, i, j; -- 2.8.0.rc3.226.g39d4020 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev