[Bug 217771] lang/beignet: update to 1.3.1

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Tue Mar 14 14:52:14 UTC 2017


--- Comment #9 from Jan Beich (mail not working) <jbeich at 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 find
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 stuck
with C++98.

-std=c++0x (and -std=c++11) is already used in CMakeLists.txt. Downstream that
provides beignet package also has new enough GCC version, newer than lang/gcc
on FreeBSD.


> 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/ upstream
some __FreeBSD__ checks would need to be dropped to avoid churn for other BSDs.

> 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 appropriate 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) usage,
etc. Porter's Handbook describes noise mainly in relation to "non-functional
whitespace changes", so I maybe wrong.


> What is inconsistent about the sorting?
> lib/beignet/b* < lib/beignet/l*

See where lib/beignet/beignet.pch is already placed, move *_20.* files there as

lib/beignet/b* < lib/beignet/i* < lib/beignet/l*

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-x11 mailing list