i965 Compiler Architecture from 2015 Farewell Intel Graphics

WIP

After 8 years of doing graphics driver development in i915, i965, and misc for Intel, I have decided to take on other things. I will remain at Intel, and be working on… FreeBSD development. It’s a pretty vague gig at the moment, so I’d be happy to hear of areas in FreeBSD that you think are lacking. Primarily I’d like to focus on the kernel, but let me know what you got, and don’t say GRAPHICS

Working on graphics has been an extremely rewarding adventure and I wish all the best to my friends and colleagues that continue to push the boundaries. I’ll take a moment to remind you where Intel graphics was in 2010 when I started, and you know, if you want to give me some credit for that, I wouldn’t mind so much.

With that, I thought I’d dump the last of my graphics blogs in flight. I had a compiler post from 2015 that I never posted because NIR sort of ruined that plan. The text is long gone, but I still have the images I created. Maybe they’re useful to someone.

WIP
WIP
End of Pipe
Compilation and Linking
data transformation through compilation

And as usual, the SVGs:
backend3.svg
high-backend.svg
compile_and_link.svg
overview_compilation_steps.svg

Download PDF

23 thoughts on “i965 Compiler Architecture from 2015 Farewell Intel Graphics

  1. Hi Ben,

    first thanks for all your work on opensource.

    One suggestion on Intel related work on the kernel side: Intel Wireless drivers

    Intel wired network drivers are excellent, Intel wireless drivers have mostly been the work of Adrian Chadd and he could really benefit from your support and knowledge.

    1. FreeBSD has ACPI S1 and S3 STR support already, but unfortunately there’s all sorts of caveats with various hardware devices and/or their detach/attach (like TPM chips/headers, add-in cards, and the like) that can mean that it actually only functions on a percentage of machines where developers have used those machines (or machines that are significantly enough alike) and have therefore been able to troubleshoot and debug those device-specific issues.
      Worse yet, very often these issues are fixed in the Windows driver, but not properly documented – so everyone else has to reverse-engineer those fixes manually for each bit of problematic hardware.

      1. Yeah. At my comment it was implicit that the suspend/resume contributions i was talking about was Intel processors and some hacking on those corner cases. Forgive me if i was to blunt 🙂

  2. It’d be in the loader (and linker) rather than the kernel but I’d like to see direct binding of symbols like Solaris has. This is not just about performance but because it solves some issues that come up with symbol naming and upgrading libraries. It also seems much cleaner than linux prelinking.

  3. I would suggest you start using a PC(or laptop if you want the real challenge:) running FreeBSD on intel hardware and you will see the gaps. You need to use this for your day to day activities.

    For example, the lack of wireless drivers for 802.11ac Intel wireless hardware, vt breaking with intel graphics, older graphics stack on FreeBSD, suspend/hibernate not working etc.

    1. +1

      GPU passthrough for bhyve or however the kernel offers such services to the userland would be so sweet. In my lowly user point of view this would make FreeBSD a “run everything” OS. 🙂

      This might be too close to the graphics part though. 😐

  4. A replacement framework for ALTQ that supports SMP and works with the new network interface so all network drivers can do traffic shaping in supported by pf and ipfw would be highly appreciated.

  5. One big missing point is the 802.11 AC support. This lack is not limited to Intel cards. Adrian Chadd have done awesome work with the current wireless stack, but it’s not a one man project, and mostly these jobs was done by Adrian.

    Other area would be a native graphics drivers without the linuxpki, but as you mentioned, you not want to work on this area.

    S3 almost works on freebsd, but there is a complete lack of S4 (hibernation).

    The unification of the sys/i386 and sys/amd64 to sys/x86 would be another good starting point, where possible.

    Bhyve improvements, exploit mitigations, performance improvements, etc…

  6. Hey Ben, so sorry to see you leaving the graphics work in the driver, I hope you enjoy hacking on FreeBSD though and that we a chance to meet again in some conference somewhere.

    By the way, it is a pity that you didn’t get to finish more of these blogs posts, to this date I still forward people to your excellent post describing the way the URB works, it is a pity that we don’t have more of those!

    1. Hi Iago. Thank you so much for the kind words. I’ve been absolutely floored by the work you’ve done and posts on your blog 🙂

  7. The unification of the sys/i386 and sys/amd64 to sys/x86 would be
    another good starting point, where possible.

    I know Linux did this quite some time ago. Can you provide any tangible benefit to doing this – like examples of where problems have cropped up by not being unified?

    1. The best example would be the trap.c, it’s almost the same. And sometimes fixes are forgotten from one of them.

      If you want more relevant info from the x86 part of freebsd, ask kib@ or emaste@.

    1. Hi Abi. Earlier, this was mentioned (it’s called S4). It’s already on my list of possibilities, though I do sort of wonder how useful S4 is. I haven’t used it myself in many years and my experience in both Linux and Windows is it’s never entirely stable.

  8. Glad to hear someone from Intel is giving some love to FreeBSD, one area in dire need of some work is cpufreq. I have never, ever gotten Turbo Boost to actually work on any intel system… and I’ve tried very hard. Kernel simply doesn’t see any of the turbo frequencies and even the ones it does see are pretty limited compared to what you’d see if it was running on Linux. I’ve got a Atom C2750 system that I spent many days messing with it trying to take pieces of cpufreq out of Linux in hopes of making it more usable but eventually gave up.

Leave a Reply

Your email address will not be published.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax

This site uses Akismet to reduce spam. Learn how your comment data is processed.