Date: Tue, 14 Mar 2017 14:52:14 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 217771] lang/beignet: update to 1.3.1 Message-ID: <bug-217771-7141-4pEUSSRmin@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-217771-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-217771-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217771 --- Comment #9 from Jan Beich (mail not working) <jbeich@FreeBSD.org> --- (In reply to Matthew Rezny from comment #8) > The LLVM requirement was bumped to 3.9 during the prior update to > 1.3.0 and we have had an up to date libdrm long enough that should > be no concern either. libdrm was updated just ~2 months ago. Once 2017Q2 is branched users may fi= nd OpenCL 2.0 is auto-disabled during build. Partial upgrades were never supported, so this can be ignored. > That is something that will need to be tested. Given that the only > Intel box I have has a chipset with "Gen3" GPU, I cannot test any > OpenCL on Intel. Removing OPENCL20 option makes 1.2 vs. 2.0 troubleshooting harder. Neither beignet port exposes debugging support (vendor optimization gets in the way) nor ports framework provides packages with debugging symbols to help distinguish crash fingerprints from already reported. > need the correct -std passed since GCC defaults to gnu++98. Not necessarily. GCC switched from C89 to C11 since 5.0 and from C++98 to C= ++14 since 6.0. Clang switched from C99 to C11 in 3.6 but as of 4.0 is still stu= ck with C++98. -std=3Dc++0x (and -std=3Dc++11) is already used in CMakeLists.txt. Downstre= am that provides beignet package also has new enough GCC version, newer than lang/g= cc on FreeBSD. https://repology.org/metapackage/beignet/versions https://repology.org/metapackage/gcc/versions > multiple of sizeof(void *) memalign and aligned_alloc don't have such a restriction. Upstream already = uses posix_memalign in other places, so I'm giving up. When pushing files/ upstr= eam some __FreeBSD__ checks would need to be dropped to avoid churn for other B= SDs. > copy and paste from the browser doesn't preserve the tabs, and that > particular section had excess whitespace that would need to be > removed, so retyping was the fastest solution Firefox and Chromium on X11 platforms preserve tabs just fine both via clipboard or primary selection. > I had previously been advised to use makepatch when adding and changing > patches. Is there a more strict set of criteria for when it is appropriat= e than > I am aware of? "make makepatch" (like "make makeplist") output isn't supposed to be used as is. It can accidentally merge separate patch files, incorporate sed(1) usag= e, etc. Porter's Handbook describes noise mainly in relation to "non-functional whitespace changes", so I maybe wrong. https://www.freebsd.org/doc/en/books/porters-handbook/slow-patch.html > What is inconsistent about the sorting? > lib/beignet/b* < lib/beignet/l* See where lib/beignet/beignet.pch is already placed, move *_20.* files ther= e as well. lib/beignet/b* < lib/beignet/i* < lib/beignet/l* --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217771-7141-4pEUSSRmin>