Bug 97951

Summary: piglit_drm_dma_buf.c:142:7: error: ‘DRM_FORMAT_R8’ undeclared (first use in this function)
Product: piglit Reporter: Vinson Lee <vlee>
Component: testsAssignee: Piglit Mailing List <piglit>
Status: RESOLVED FIXED QA Contact: Piglit Mailing List <piglit>
Severity: normal    
Priority: medium CC: eric, krh, robclark
Version: unspecifiedKeywords: bisected, regression
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Vinson Lee 2016-09-27 16:30:41 UTC
piglit: 0222f5db00fd47fb745402514a6d8cf2747f8434 (master)

tests/util/piglit-framework-gl/piglit_drm_dma_buf.c: In function ‘piglit_intel_buf_create’:
tests/util/piglit-framework-gl/piglit_drm_dma_buf.c:142:7: error: ‘DRM_FORMAT_R8’ undeclared (first use in this function)
  case DRM_FORMAT_R8:
       ^
tests/util/piglit-framework-gl/piglit_drm_dma_buf.c:142:7: note: each undeclared identifier is reported only once for each function it appears in
tests/util/piglit-framework-gl/piglit_drm_dma_buf.c:145:7: error: ‘DRM_FORMAT_GR88’ undeclared (first use in this function)
  case DRM_FORMAT_GR88:
       ^
tests/util/piglit-framework-gl/piglit_drm_dma_buf.c:146:7: error: ‘DRM_FORMAT_RG88’ undeclared (first use in this function)
  case DRM_FORMAT_RG88:
       ^


0222f5db00fd47fb745402514a6d8cf2747f8434 is the first bad commit
commit 0222f5db00fd47fb745402514a6d8cf2747f8434
Author: Rob Clark <robdclark@gmail.com>
Date:   Sat Sep 3 15:16:31 2016 -0400

    dmabuf: fix YUV tests for drivers other than intel
    
    Ok, so the basic problem with the YUV tests is that they currently
    completely ignore driver/hw pitch requirements, since the code that
    allocates the buffer doesn't know the pixel format, only the 'cpp'.
    
    The yuv test creates a small 4x4 yuv eglimage.  If, say, the hardware
    requires the pitch to be aligned to, say, 32pixels, everything is fine
    for the Y plane, but the subsampled U/V or U+V plane has half as many
    pixels.  (This did help me catch a bug in driver, not rejecting the
    dmabuf import with invalid pitch, but that doesn't help to get the
    piglit tests running.)
    
    The best approach I could come up with to fix this is to pass the
    fourcc all the way down to the code that creates the dmabuf (and copies
    src data into the dmabuf).  Unfortunately this makes the patch a bit
    bigger than I was hoping, and not really sure a good way to split it
    up.
    
    This is tested on i965 (with the intel dma-buf backend) and freedreno
    (with the gbm dma-buf backend).  In the gbm case, it requires new
    gbm format values for R8 and GR88, which is on mesa master as of
    this morning.  (So I bumped the gbm version dependency to 12.1.)
    
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

:100644 100644 ce7f3f8aabc4884550b4d62ae738b8ed49a13131 4002fe9bf741e43377221021ade5faa51c3dea60 M	CMakeLists.txt
:040000 040000 1cb176b53c8e3ed014824612b498e64c1fb393fc 7730a34ffac6886e43c48bd6b8df7ae3bb700d4b M	tests
bisect run success
Comment 1 Dylan Baker 2016-09-27 17:57:15 UTC
This commit compiles fine in our CI against mesa master, what driver or version
of mesa are you testing against?
Comment 2 Vinson Lee 2016-09-27 18:15:02 UTC
I get the build failure on Ubuntu 16.04 with 11.2.0-1ubuntu2.2.
Comment 3 Rob Clark 2016-09-27 18:21:06 UTC
(In reply to Vinson Lee from comment #2)
> I get the build failure on Ubuntu 16.04 with 11.2.0-1ubuntu2.2.

this actually needs a newer mesa, since the R8 and GR88 formats were recent additions to mesa.  See: b4e88b500c93d9728d2a3e30f6b0365bcb224b88
Comment 4 Dylan Baker 2016-09-27 19:08:32 UTC
Vinson, are you testing on Intel hardware?
Comment 5 Rob Clark 2016-09-27 19:31:59 UTC
(In reply to Dylan Baker from comment #4)
> Vinson, are you testing on Intel hardware?

I guess the problem is he is building mesa against an older mesa master, so the test for mesa/gbm 12.1 to enable gbm dmabuf backend passes, even though it isn't a new-enough 12.1.

short version, if building piglit against master, use more recent master.  The problem will solve itself once 12.1 release branch is cut.
Comment 6 Dylan Baker 2016-09-27 19:46:11 UTC
Well, we check for a gbm 12.0 (which I think is correct), and for intel_libdrm of some version, which I think is incorrect now.

He's building against 11.x, so I would expect it to fail the 12.0 check, but if he's on intel then that libdrm check may be tripping things up.
Comment 7 Rob Clark 2016-09-27 19:50:37 UTC
hmm, well, this hunk was supposed to make it not build that code unless you have 12.1.. although it's possible my cmake-fu was lacking somehow..

---
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ce7f3f8..4002fe9 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -141,7 +141,7 @@ IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
 	if(GBM_FOUND)
 		set(PIGLIT_HAS_GBM True)
 		add_definitions(-DPIGLIT_HAS_GBM)
-		if (GBM_VERSION VERSION_EQUAL "12.0" OR GBM_VERSION VERSION_GREATER "12.0")
+		if (GBM_VERSION VERSION_EQUAL "12.1" OR GBM_VERSION VERSION_GREATER "12.1")
 			set(PIGLIT_HAS_GBM_BO_MAP True)
 			add_definitions(-DPIGLIT_HAS_GBM_BO_MAP)
 		endif()
Comment 8 Dylan Baker 2016-09-27 19:55:40 UTC

I think the problem is further down:

if(LIBDRM_FOUND AND XCB_DRI2_FOUND AND
   ((LIBDRM_INTEL_VERSION VERSION_GREATER "2.4.37") OR
     PIGLIT_HAS_GBM_BO_MAP))
	set(PIGLIT_BUILD_DMA_BUF_TESTS_IS_VALID true)
else()
	set(PIGLIT_BUILD_DMA_BUF_TESTS_IS_VALID false)
endif()

This will do what you expect on every piece of hardware, except Intel, where if the GBM version is new enough it will still turn it on if the DRM_INTEL version is also new enough.

I think we just need to remove that LIBDRM_INTEL check (or modify it).
Comment 9 Dylan Baker 2016-09-27 20:35:22 UTC

Err, that should be "if the GBM version is *not* new enough"
Comment 10 Rob Clark 2016-09-27 21:49:42 UTC
(In reply to Dylan Baker from comment #9)
> 
> Err, that should be "if the GBM version is *not* new enough"

(In reply to Dylan Baker from comment #8)
> 
> I think the problem is further down:
> 
> if(LIBDRM_FOUND AND XCB_DRI2_FOUND AND
>    ((LIBDRM_INTEL_VERSION VERSION_GREATER "2.4.37") OR
>      PIGLIT_HAS_GBM_BO_MAP))
> 	set(PIGLIT_BUILD_DMA_BUF_TESTS_IS_VALID true)
> else()
> 	set(PIGLIT_BUILD_DMA_BUF_TESTS_IS_VALID false)
> endif()
> 
> This will do what you expect on every piece of hardware, except Intel, where
> if the GBM version is new enough it will still turn it on if the DRM_INTEL
> version is also new enough.
> 
> I think we just need to remove that LIBDRM_INTEL check (or modify it).

oh, my bad.. I read the error message too quickly, as GBM_FORMAT_R8/etc.. not DRM_FORMAT_xyz.  So that part won't be built unless you have -DPIGLIT_HAS_GBM_BO_MAP, so existing check is fine.

The problem is actually that he has too old drm_fourcc.h I guess?  Not sure what the best way to check for that would be..
Comment 11 Dylan Baker 2016-09-27 22:05:15 UTC

I think that we just need to update the check on intel, those formats were added in this commit from danvet (268ae7cae5afd76462c3ef14ed9021a2d40c2e57). I'll send a patch.
Comment 12 Vinson Lee 2016-09-29 21:26:21 UTC
Now I'm getting this build error.

tests/spec/ext_image_dma_buf_import/transcode-nv12-as-r8-gr88.c: In function ‘create_textures’:
tests/spec/ext_image_dma_buf_import/transcode-nv12-as-r8-gr88.c:178:7: error: ‘DRM_FORMAT_R8’ undeclared (first use in this function)
       DRM_FORMAT_R8, r8_pixels);
       ^
Comment 13 Vinson Lee 2016-10-03 22:59:14 UTC
commit 5a87c57f9ba6581f2c091d7065c3c2cc1b001f2a
Author: Vinson Lee <vlee@freedesktop.org>
Date:   Mon Oct 3 14:34:23 2016 -0700

    utils: Move DRM_FORMATS defines to piglit_drm_dma_buf.h.
    
    This patch fixes this build error.
    
    transcode-nv12-as-r8-gr88.c: In function ‘create_textures’:
    transcode-nv12-as-r8-gr88.c:178:7: error: ‘DRM_FORMAT_R8’ undeclared (first use in this function)
           DRM_FORMAT_R8, r8_pixels);
           ^
    
    Fixes: 0222f5db00fd ("dmabuf: fix YUV tests for drivers other than intel")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97951
    Signed-off-by: Vinson Lee <vlee@freedesktop.org>
    Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.