This is desirable as the chromium port now uses this extension to
obtain pci vendor/device ids for use in feature/extension blacklists.
Prompted by a mail from byrnet@, tested on r600g by krw@
The newly added os_get_total_physical_memory() was passing the length of
a pointer rather than the type which made the sysctl call fail on
non 64 bit archs. And it was passing the wrong pointer for the result.
Fixes for these problems have been submitted back upstream.
Tested by matthieu@ mpi@ and myself. landry@ ran a ports bulk build.
kettenis@ tracked down the cause of an alignment fault on archs
that require strict eight byte pointer alignment.
libEGL against libgbm and libglapi.
The libgbm requirement comes from the drm EGL backend that was
enabled with the 10.2.3 update.
ok matthieu@ kettenis@
symbols from libgbm, and that breaks www/webkit (and probably all the 23
ports linking against EGL, which now probably need WANTLIB fixes..)
with/ok matthieu@
commit 749cb8909714fed57b0213f4ad92def3bb24f153
Author: Vinson Lee <vlee@freedesktop.org>
Date: Sun Nov 3 20:27:13 2013 -0800
gallivm: Remove llvm::DisablePrettyStackTrace for LLVM >= 3.4.
LLVM 3.4 r193971 removed llvm::DisablePrettyStackTrace and made the
pretty stack trace opt-in rather than opt-out.
The default value of DisablePrettyStackTrace has changed to true in LLVM
3.4 and newer.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60929
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
error on at least OpenBSD.
Problem originally found and fixed in libdrm by kettenis@
Dave Airlie pointed out that mesa has the same issue.
This change has already been merged in upstream mesa.
ok matthieu@ kettenis@
event that's not coming.
This unbreak clutter/cogl and probably other toolkits.
Upstream commit 25620eb1d277c6b80edb136eaeca12532fcfd3ce by Adam Jackson
ok ajacoutot@, jasper@, robert@
(but never made it into the 7.8 branch).
first:
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Apr 22 12:47:41 2010 -0700
DRI2: add config query extension
Add a new DRI2 configuration query extension. Allows for DRI2
client code to query for common DRI2 configuration options.
second:
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Apr 22 12:49:03 2010 -0700
DRI2/GLX: check for vblank_mode in DRI2 GLX code
Re-add support for the vblank_mode environment and configuration
variable. Useful for benchmarking and app control.
The final affect being that config and environment variables for
controlling swap mode work with dri2 now. which helps me a lot with
debugging.
ok matthieu@.
case libGL itself was dlopen()ed), it was using "libGL.so.1" (linux
convention, doesn't work on OpenBSD). Change it to "libGL.so" so it has
a hope in hell of working.
I finally wrote this patch when trying to port perl's OpenGL modules
ages ago and i finally decided that hacking each instance of dlopening
libGL to use RTLD_GLOBAL was dumb.
ok matthieu@
Since mesa changed some code, GL applications have been rather nasty to
the xserver, if they are unconstrained rendering wise they spam too many
requests at the xserver and make it slow as hell (even if the cpu is
fairly idle).
There is a throttling mechanism in the xserver (1.8 at least), but that
only really works if you are doing vblank syncing (which is turned off
in our intel driver right now for unrelated reasons), and even then an unsynced
client can cause the same problem.
While a proper fix is being worked on (I am in discussion with X
developers), comment out two conditionals in the intel mesa driver so
that even when using dri2 swapbuffers we wait on the swapbuffers before
last before rendeing more, this prevents almost DoSing the server.
Tested on ironlake, 855 and 965 by me (and my matthieu as well). ok
matthieu@
update mesa.
Specifically, we disallow in radeondrm for dri clients mapping
registers, so don't try and map them (and thus fail as we currently
were). for r300+ this was only used for falling back on old drm versions
(doesn't matter). For r100, the new BO abstraction used the SWI number
(in hardware scratch reg 3) for the buffer age, so use the newly added
getparam member to grab that info instead of trying to read the mapped
registers.
Update to the lastest kernel headers before you even think about
building this or trying to use a snapshot on r100/r200.
So now radeon works with mesa again, hoorah!
Tested on rv250 by Josh Elsasser, and on R420 (and x800) by myself.
