Bug 96850 - Crucible tests fail for 32bit mesa
Summary: Crucible tests fail for 32bit mesa
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Nanley Chery
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 98335
  Show dependency treegraph
 
Reported: 2016-07-07 19:51 UTC by Mark Janes
Modified: 2016-10-24 21:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Mark Janes 2016-07-07 19:51:52 UTC
The following tests fail on 32 bit platforms:
func.first
func.desc.dynamic.storage-buffer
func.desc.dynamic.uniform-buffer

Nanley has investigated this and is working on Mesa and Crucible fixes.  This bug tracks that work.
Comment 1 Nanley Chery 2016-08-12 21:59:30 UTC
With the patches just pushed to master, the following tests should be fixed:
func.desc.dynamic.storage-buffer
func.desc.dynamic.uniform-buffer

The 5-patch series that fixes the test ends with

commit d826afba1f06d32acefda883ec3f536c11f6c130
Author: Nanley Chery <nanley.g.chery@intel.com>
Date:   Tue Jul 12 11:57:50 2016 -0700

    func.desc.dynamic: Use a correct reference image
    
    Commit 17685f385bad0f7e79772e2e5990e2e2572b6897 changed the uniform buffer
    test's reference image although the test logic would have generated the
    same image if it didn't have the bugs that commit introduced. Restore the
    original image.
    
    Since storage test's output is equivalent to that of the uniform test,
    remove its custom image and reference the uniform buffer test's image.
    
    Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
                   
I'll look into func.first once I setup a 32-bit system.
Comment 2 Nanley Chery 2016-10-24 21:58:45 UTC
Thanks to some help from Jason I was able to get a 32-bit build of crucible on my 64-bit system with the following command:

 ./configure CC="gcc -m32" --build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu

It seems that func.first started passing with the following commit:

commit fa714ad88e1392909e767a622c6fd1ea4febccbf
Author: Nanley Chery <nanley.g.chery@intel.com>
Date:   Thu Jul 7 16:03:57 2016 -0700

    Conform to Vulkan Specification 1.0.20

    I used the Vulkan Validation layers to determine the areas of
    non-conformance.

    Changes:
     * Provide required fields:
       - VkFramebufferCreateInfo::renderPass
       - VkSubmitInfo::sType
       - VkDeviceQueueCreateInfo::sType
       - VkDeviceQueueCreateInfo::pQueuePriorities
     * Assign the right bit to VkDescriptorPoolCreateInfo::flags for the
       freeing which occurs during cleanup.
     * Use the correct VkDescriptorPoolCreateInfo::poolSizeCount value.
       This fixes a bug in DescriptorPool creation in which DescriptorTypes
       after STORAGE_TEXEL_BUFFER were not being added to the pool.
     * Set VkGraphicsPipelineCreateInfo::pDynamicState to NULL if
       VkPipelineDynamicStateCreateInfo::dynamicStateCount is zero

    Signed-off-by: Nanley Chery <nanley.g.chery@intel.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.