svn commit: r46540 - head/en_US.ISO8859-1/htdocs/news/status
Benjamin Kaduk <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
Author: bjk
Date: Tue Apr 14 21:33:46 2015
New Revision: 46540
URL: https://svnweb.freebsd.org/changeset/doc/46540
Log:
Add report from the graphics team
Approved by: hrs (mentor, implicit)
Modified:
head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml
Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml
==============================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml Tue Apr 14 21:13:41 2015 (r46539)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml Tue Apr 14 21:33:46 2015 (r46540)
@@ -965,4 +965,120 @@ WITHOUT_FORTH=y</pre>
</help>
</project>
+ <project cat='ports'>
+ <title>The Graphics stack on FreeBSD</title>
+
+ <contact>
+ <person>
+ <name>&os; Graphics team</name>
+ <email>[email protected]</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/Graphics">Graphics stack roadmap and supported hardware matrix</url>
+ <url href="http://blogs.freebsdish.org/graphics/">Graphics stack team blog</url>
+ <url href="https://github.com/freebsd/freebsd-ports-graphics">Ports development tree on GitHub</url>
+ </links>
+
+ <body>
+ <p>In the official Ports tree, the Mesa ports
+ (<tt>libglapi</tt>, <tt>libGL</tt>, <tt>libEGL</tt>,
+ <tt>libglesv2</tt>, <tt>gbm</tt>, <tt>dri</tt>) are kept close
+ to the latest Mesa 10.4.x release.</p>
+
+ <p>In the development tree (see the GitHub link), the update
+ to Mesa 10.5 came along with several improvements and cleanup to
+ the ports themselves. Now, all ports share the same configure
+ flags and build dependencies. As Mesa is built from scratch for
+ each port, this ensures that all libraries and drivers are
+ consistent with each other. This fixes at least two
+ problems:</p>
+
+ <ul>
+ <li>A long standing bug: the <tt>drm</tt> EGL platform is now
+ functional, meaning we will be able to enable Glamor (the 2D
+ acceleration engine based on OpenGL) in the X.Org server. This is
+ required to provide 2D acceleration for Radeon HD 7000 and later
+ GPUs for instance.</li>
+ <li>Clover, the Mesa OpenCL implementation, now works; see the next
+ paragraph.</li>
+ </ul>
+
+ <p>The downside of this unification is that all ports will depend on
+ LLVM. This work is happening in the <tt>mesa-10.5</tt> branch.</p>
+
+ <p>Progress has been made on OpenCL, thanks to help from
+ Johannes Dieterich. Clover (Mesa's implementation) and Beignet
+ (Intel's implementation) were added as ports to the development
+ tree. They were tested successfully on Radeon and Intel GPUs, but
+ see the wiki for an up-to-date status. Initially developed in
+ the <tt>opencl</tt> branch, everything has now been merged into the
+ <tt>mesa-10.5</tt> branch. This cannot go into the official
+ Ports tree yet because it requires the unification explained
+ above.</p>
+
+ <p>A new port, <tt>drm-kmod</tt> was added to the official
+ Ports tree. It provides updated <tt>drm2</tt>, <tt>i915kms</tt>
+ and <tt>radeonkms</tt> kernel modules for FreeBSD 9.3-RELEASE
+ and 9.3-STABLE. The only difference from the vanilla modules is
+ the addition of hardware context support to the i915 driver.
+ The <tt>xf86-video-radeon</tt> and <tt>xf86-video-intel</tt>
+ drivers were patched to use the <tt>drm-kmod</tt> port on these
+ versions of FreeBSD. This will allow us to remove the duality
+ of the Mesa ports (<tt>libGL</tt>/<tt>libEGL</tt>/<tt>dri</tt>)
+ and only support one version (as is already the case in the
+ <tt>mesa-10.5</tt> branch where Mesa 9.1.7 is gone). There is
+ no ETA yet for when this last part will happen.</p>
+
+ <p>In the development Ports tree, the <tt>xserver-next</tt>
+ branch was updated from xorg-server 1.16 to be tracking 1.17.
+ Again, this depends on the previous step: the removal of Mesa
+ 9.1.7.</p>
+
+ <p>Work is finishing up on an update of miscellaneous X.Org
+ components. Apart from updates to several X.Org ports, this
+ update also removes the use of <tt>.la</tt> files from the X.Org
+ libraries that still have them. Also, the
+ <tt>xf86-video-intel</tt> driver will receive patches to allow
+ it to compile against a newer xorg-server than 1.14. Most of
+ the X.Org component updates were submitted by Matthew Rezny.</p>
+
+ <p>The location where fonts get installed was overhauled and
+ the way to handle fonts from the plist got simplified. Now all
+ fonts are installed in <tt>/usr/local/share/fonts</tt> as
+ required by the XDG rules. Furthermore, making a port for fonts
+ should be easier: more aspects, such as calling fc-cache(1), are
+ handled by the Ports framework. Therefore, the font ports'
+ consistency was greatly improved.</p>
+
+ <p>In the kernel, the DRM device-independent code was
+ updated to match Linux 3.8. A merge to 10-STABLE is pending.
+ The i915kms kernel driver received an update too, which is
+ already merged to 10-STABLE.</p>
+
+ <p>Having both updates in place enables work on a
+ second update of the i915 driver: this time it will be
+ synchronized with Linux 3.8, like the rest of the DRM subsystem,
+ and bring Haswell support. This was started recently. Our hope
+ is that it will be ready in time for FreeBSD 10.2-RELEASE.</p>
+
+ <p>During Q2, we are going to work with the GNOME team on
+ porting libinput and testing Wayland. Currently we know that
+ GTK+3 and GNOME 3 have full support for Wayland. We also need
+ to test Xwayland from xorg-server 1.16+ to support X
+ applications on Wayland desktops. If you know of more software
+ that uses Wayland, we would like to hear about them. At this point
+ there are no plans to port the Weston reference implementation
+ of a Wayland compositor.</p>
+ </body>
+
+ <help>
+ <task>
+ <p>See the "Graphics" wiki page for up-to-date
+ information.</p>
+ </task>
+ </help>
+ </project>
+
</report>
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"