airlied airlied - Fri, 10 Jan 2014 01:24:40 GMT LiveJournal / airlied 5891031 personal airlied 80 68 Fri, 10 Jan 2014 01:24:40 GMT talk from LCA2014 - Virtio GPU Talked yesterday about virgil project, virtio based GPU and where its going.<br /><br />watch it here,<br /><a href='' rel='nofollow'></a> public 0 Tue, 17 Dec 2013 07:06:32 GMT adventures in EGL image buffer passing So I've been looking into how I can do some buffer passing with EGL and OpenGL with a view to solving my split renderer/viewer problem for qemu.<br /><br /><a href='' rel='nofollow'></a><br />contains the hacks I've been playing with so far.<br /><br />The idea is to have a rendernode + gbm using server side renderer, that creates textures and FBOs attached to them, renders into them, then sends them to a client side, which renders the contents to the screen using GL rendering.<br /><br />This code reuses keithp's fd passing demo code and some of dvdhrm's simple dma-buf code.<br /><br />Firstly the server uses GBM and rendernodes to create a texture, that it binds to a FBO. It generates an EGLImage from the texture using EGL_GL_TEXTURE_2D_KHR, then uses EGL_MESA_drm_image to get a handle for it, then uses libdrm drmPrimeHandleToFD to create an fd to pass to the server. It passes the fd using the fdpassing code. It then clears the texture, sends the texture info to the client, along with a dirty rect, clears it again, and sends another dirty rect.<br /><br />The client side, uses EGL + GLES2 with EXT_image_dma_buf_import to create an EGLImage from the dma-buf, then uses GL_OES_EGL_image to create a 2D texture from the EGLImage then just renders the texture to a window.<br /><br />Shortcomings I've noticed in the whole stack so far:<br />a) asymmetric interfaces abound:<br /> <br />1) we have an EGLImage importer for dma-buf EXT_image_dma_buf_import, but we have no EGLImage dma-buf exporter yet - hence the MESA_drm_image + libdrm hack.<br /><br />2) we have an EGLImage exported for Desktop OpenGL, EGL_KHR_gl_image works fine. But we only have EGLImage importers for GLES, GL_OES_EGL_image - hence why the client is using GLES2 to render not GL like I'd like.<br /><br />b) gallium is missing dma-buf importing via EXT_image_dma_buf_import, I have a quick patch, since we have the ability to import from fds just not from dma-bufs, I should send out my first hack on this.<br /><br />The demo also has color reversing issues I need to sort out, due to gallium code needing a few more changes I think, but I've gotten this to at least run on my machine with nouveau and the hacked up dma-buf importer patch. public 0 Tue, 10 Dec 2013 04:26:09 GMT disconnected VM operation and 3D So one of the stumbling blocks on my road to getting 3D emulation in a VM is how most people use qemu in deployed situations either via libvirt or GNOME boxes frontends.<br /><br />If you use are using libvirt and have VMs running they have no connection to the running user session or user X server, they run as the qemu user and are locked down on what they can access. You can restart your user session and the VM will keep trucking. All viewing off the VM is done using SPICE or VNC. GNOME Boxes is similar except it runs things as the user, but still not tied to the user session AFAIK (though I haven't confirmed).<br /><br />So why does 3D make this difficult?<br /><br />Well in order to have 3D we need to do two things.<br /><br />a) talk to the graphics card to render stuff<br />b) for local users, show the user the rendered stuff without reading it back into system RAM, and sticking it in a pipe like spice or vnc, remote users get readback and all the slowness it entails.<br /><br />No in order to do a), we face a couple of would like to have scenarios:<br /><br />1. user using open source GPU drivers via mesa stack<br />2. user using closed source binary drivers like NVIDIA or worse fglrx.<br /><br />How to access the graphics card normally is via OpenGL and its window APIs like GLX. However this requires a connection to your X server, if your X server dies your VM dies, if your session restarts your VM dies. <br /><br />For scenario 1, where we have open source kms based drivers, the upcoming render nodes support in the kernel will allow process outside the X server control to use the capabilities of the graphics card via the EGL API. This means we can render in a process offscreen. This mostly solves problem (a) how to talk to the graphics card at all.<br /><br />Now for scenario 2, so far NVIDIA has mostly got no EGL support for its desktop GPUs, so in this case we are kinda out in the cold, until they have at least EGL support, in terms of completely disconnecting the rendering process from the running user X server lifecycle.<br /><br />This leaves problem (b), how do we get the stuff rendered using EGL back to the user session to display it. My first initial hand-wave in this area involved EGL images and dma-buf, but I get the feeling on subsequent reads that this might not be sufficient enough for my requirements. It looks like something like the EGLStream extension might be more suitable, however EGLstream suffers from only being implemented in the nvidia tegra closed source drivers from what I can see. Another option floated was to somehow use an embedded wayland client/server somewhere in the mix, I really haven't figured out the architecture for this yet (i.e. which end has the compositor and which end is the client, perhaps we have both a wayland client and compositor in the qemu process, and then a remote client to display the compositor output, otherwise I wonder about lifetime and disconnect issues). So to properly solve the problem for open source drivers I need to either get EGLstream implemented in mesa, or figure out what the wayland hack looks like.<br /><br />Now I suppose I can assume at some stage nvidia will ship EGL support with the necessary bits for wayland on desktop x86 and I might not have to do anything special and it will all work, however I'm not really sure how to release anything in the stopgap zone.<br /><br />So I suspect initially I'll have to live with typing the VM lifecycle to the logged in user lifecycle, maybe putting the VM into suspend if the GPU goes away, but again figuring out to integrate that with the libvirt/boxes style interfaces is quite tricky. I've done most of my development using qemu SDL and GTK+ support for direct running VMs without virt-manager etc. This just looks ugly, though I suppose you could have an SDL window outside the virt-manager screen and virt-manager could still use spice to show you the VM contents slower, but again it seems sucky. Another crazy idea I had was to have the remote viewer open a socket to the X server and pass it through another socket to the qemu process, which would build an X connection on top of the pre opened socket,<br />therefore avoiding it having to have direct access to the local X server. Again this seems like it could be a largely ugly hack, though it might also work on the nvidia binary drivers as well.<br /><br />Also as a side-note I discovered SDL2 has OpenGL support and EGL support, however it won't use EGL to give you OpenGL only GLES2, it expects you to use GLX for OPENGL, this is kinda fail since EGL with desktop OpenGL should work fine, so that might be another thing to fix! public 9 Thu, 03 Oct 2013 05:17:46 GMT virgil3d: an update Okay its been a while, so where is virgil3d up to now I hear you ask?<br /><br />Initially I wrote a qemu device and a set of guest kernel drivers in order to construct a research platform on which to investigate and develop the virgil protocol, renderer and guest mesa drivers based on Gallium3D and TGSI. Once I got the 3D renderer and guest driver talking I mostly left the pile of hacks in qemu and kernel alone. So with this in mind I've split development into two streams moving forward:<br /><br />1) the virgil3d renderer and 3D development:<br />This is about keeping development of the renderer and guest driver continuing, getting piglit tests passing and apps running. I've been mostly focused on this so far, and there has been some big issues to solve that have taken a lot of the time, but as of today I got xonotic to play inside the VM, and I've gotten the weston compositor to render the right way up. Along with passing ~5100/5400 piglit gpu.tests.<br /><br />The biggest issues in the renderer development have been<br />a) viewport setup - gallium and OpenGL have different viewport directions, and you can see lots of info on Y=0=TOP and Y=0=BOTTOM in the mesa state tracker, essentially this was more than my feeble brain could process so I spent 2 days with a whiteboard, and I think I solved it. This also has interactions with GL extensions like GL_ARB_fragment_coord_conventions, and FBOs vs standard GL backbuffer rendering.<br /><br />b) Conditional rendering - due to the way the GL interface for this extension works I had to revisit my assumption that the renderer could be done with a single GL context, I had to rewrite things to use a GL context per guest context in order to give conditional rendering any chance of working. The main problem was using multiple GL queries for one guest query didn't work at all with the cond rendering interface provided by GL.<br /><br />c) point sprites - these involved doing shader rewrites to stick gl_PointCoord in the right places, messy, but the renderer now has shader variants, however it needs some better reference counting and probably leaks like a sieve for long running contexts.<br /><br />2) a new virtio-gpu device<br /><br />The plan is to create a simple virtio based GPU, that can layer onto a PCI device like the other virtio devices, along with another layer for a virtio-vga device. This virtio based gpu would provide a simple indirect multi-headed modesetting interface for use by any qemu guests, and allow the guest to upload/download data from the host side scanouts. The idea would be then to give this device capabilities that the host can enable when it detects the 3d renderer is available and qemu is started correctly. So then the guest can use the virtio gpu as a simple GPU with no 3D, then when things are ready the capability is signalled and it can enable 3D. This seems like the best upstreaming plan for this work, and I've written the guts of it.<br /><br />In order to test the virtio-gpu stuff I've had to start looking at porting qemu to SDL 2.0 as SDL 1.2 can't do multi-window and can't do argb cursors, but SDL 2.0 can. So I'm hoping with SDL 2.0 and virtio-gpu you can have multiple outputs per the vgpu show up in multiple SDL windows.<br /><br />I'll be speaking about virgil3d at the KVM Forum in Edinburgh in a couple of weeks and also be attending Kernel Summit. public 3 Mon, 23 Sep 2013 07:13:02 GMT glamor Xv support (gsoc in a day) So had a GSOC project to implement Xv support in glamor, but the candidate got a better offer to do something more interesting, so I was bit sleep deprived (sick kid) and didn't want to face my current virgl task and I'm interested in using glamor potentially for virgil so I took a learning day :-)<br /><br />So I spent the day writing Xv support for glamor for no good reason,<br /><br /><a href='' rel='nofollow'></a><br />git:// xv-support<br /><br />git:// glamor-xv-support<br /><br />contains the result of my day, the glamor repo may not be public yet, its waiting on fd.o cgit crawler.<br /><br />Xv works for YV12 planar videos, I suspect to do packed video support I'd need a GL extension to expose the hw formats for doing packed video, this probably wouldn't be a major extension and maybe someone might do it sometime.<br /><br />The code supports, brightness, contrast, hue and saturation controls using the code ported from the radeon driver.<br /><br />I've tested it with mplayer on evergreen card of some variant, and it seems to work fine with the one video I used :-) public 2 Fri, 26 Jul 2013 04:06:50 GMT virgil3d: design document and sorta build instructions I've published on Google docs a bit more of a technical document on how virgil3d is designed.<br /><br /><a href='' rel='nofollow'></a><br /><br />I'm hoping to flesh it out a bit more, and of course I'll probably never keep it up to date, but it should be close enough :-)<br /><br />I've also put up some build instructions here:<br /><a href='' rel='nofollow'></a><br /><br />They are messy and incomplete, any don't go packaging anything. public 0 Thu, 18 Jul 2013 03:51:13 GMT Introducing Virgil - 3D virtual GPU for qemu Virgil is a research project I've been working on at Red Hat for a few months now and I think is ready for at least announcing upstream and seeing if there is any developer interest in the community in trying to help out.<br /><br />The project is to create a 3D capable virtual GPU for qemu that can be used by Linux and eventually Windows guests to provide OpenGL/Direct3D support inside the guest. It uses an interface based on Gallium/TGSI along with virtio to communicate between guest and host, and it goal is to provided an OpenGL renderer along with a complete Linux driver stack for the guest.<br /><br />The website is here with links to some videos:<br /><a href='' rel='nofollow'></a><br /><br />some badly formatted Questions/Answers (I fail at github):<br /><a href='' rel='nofollow'></a><br /><br />Just a note and I can't stress this strongly enough, this isn't end user ready, not even close, it isn't even bleeding edge user ready, or advanced tester usage ready, its not ready for distro packaging, there is no roadmap or commitment to finishing it. I don't need you to install it and run it on your machine and report bugs.<br /><br />I'm announcing it because there maybe other developers interested or other companies interested and I'd like to allow them to get on board at the design/investigation stage, before I have to solidify the APIs etc. I also don't like single company projects and if I can announcing early can help avoid that then so be it!<br /><br />If you are a developer interested in working on an open source virtual 3D GPU, or you work for a company who is interested in developing something in this area, then get in touch with me, but if you just want to kick the tyres, I don't have time for this yet. public 11 Sat, 30 Mar 2013 08:08:58 GMT on open source development and disagreements So I've been involved in a recent dispute on the wayland project, with a person I'd classify as a poisonous person. Basically a contributor who was doing more damage than good, and was causing unneeded disturbances. I won't comment any further on that here, but just setting the scene for writing this.<br /><br />So everytime something like this happens in a project, there emerges from the woodwork, people who claim that having public discussions about these sort of things is bad for open source, or makes us look like a crowd of juvenile developers, also how you never see this thing on closed sourced projects, or with open-source projects developer in-house and thrown over the wall. I've also recently seen this crop up when Linus flamed people, and everyone wondered why he didn't do it on some sort of private list or something.<br /><br />Now I can only think these people are one of:<br /><br />a) never worked in a company on a major closed source project.<br /><br />b) if they have, its been top down development, where managers are telling them what to do, and maybe some architect dude has drawn a load of pretty pictures and docs. Of course the architect is never wrong, but its above your pay grade to talk to someone of such authority, so when you find problems with the architecture you hack around them instead of growing a pair and standing your ground, or else you aren't good enough to notice anything wrong. <br /><br />I've seen plenty of companies where developers leave due to in-fighting or transfer to a different department, this stuff never comes out and you all are none the wiser.<br /><br />So open source doesn't have top-down development, its all bottom up, most contributors to major projects do so with some ideas of what they want, but they aren't been driven by a management chain. However it means that there is generally nobody to force someone into their views, and when two people collide (or in this case, one person and everyone else), something has to give, and its best to give in public, so nobody can say it was some sort of cabal or closed decision.<br /><br />Now open-source is about seeing the sausage making process, you get to see all the bits of stuff you don't want to think go into the sausages, you have to face a lot more truth, and you have to be willing to stand up against things without mummy manager to back you up. You can't have all the nice benefits of open-source development without having the bad side, the public blowups and discussion, it just can't work like that. If we take all those discussions to private lists or emails, where do you draw the line, are the people on that private list some sort of shadowy cabal overlords? Do you want an open-source development model that isn't public?<br /><br />I'm sure people will say why can't we all just get along? and why can't everyone act mature? well a) we are human, b) there is no HR department frontend blocking the people at the gate, there's no interview process to weed out undesirable traits before they join the project. So when someone submits patches that work you generally accept them as a contributor, and it can take a while before you realise they are doing more harm than good, at which point its going to be public. public 10 Tue, 05 Mar 2013 08:32:30 GMT its a bird, is it a space station? no its a display server [update: Mir page removed most of the reasons Wayland wasn't suitable, so why did they not use wayland again?]<br />[update: still my opinion, really, nobody is making me say shit, lwn commenters really like to believe I've got a hand up my ass]<br /><br />Okay I'm going to write a short piece on why I believe Mir isn't a good idea. If you don't know what mir is then don't bother reading the rest of this until you do.<br /><br />So lets take a look at Mir from a cynical pov (I'm good at that): Say this is nothing more than a shallow power play by Canonical to try and control parts of the graphics infrastructure on Linux. It must be really frustrating to have poured so much money into a company and not have 100% control over all the code the company produces and have the upstream community continually ignore your "leadership". This would leave you wanting to exert control where you can and making decisions on what spaces you can do that in internally.<br /><br />So in order to justify the requirement that Mir is required by the community at large above the current project in the space, Wayland, it is necessary to bash wayland in order that your community can learn the lines so they can repeat them right or wrong across the Internet. So you post a page like this<br /><a href='' rel='nofollow'></a><br />and a section called "Why Not Wayland / Weston?".<br /><br />Now I've been reliably informed by people who know, that nothing in that section makes any sense for anyone who studied wayland for longer than 5 mins a year or two ago, especially the main points about the input handling. Nobody from Canonical has ever posted any questions to wayland mailing lists or contacted Wayland developers asking to support a different direction.<br /><br />So maybe I'm being too cynical and Hanlon's razor applies, "Never attribute to malice that which is adequately explained by stupidity".<br /><br />Now the question becomes do you want the display server that you are going to base the future of the Linux desktop and possible mobile spaces on a server written by people too stupid to understand the current open source project in the space?<br /><br />The thing is putting stuff on the screen really isn't the hard part of display servers, getting input to where it needs to go is, and making it secure. Input methods are hard, input is hard, guess what they haven't even contemplated implementing yet?<br /><br />Valve? NVIDIA? AMD? I'd be treading carefully :-)<br /><br />(all my own opinion, not speaking for my employer or anyone really). Probably should comment on the g+ threads or lwn or somewhere cool. public 2 Mon, 07 Jan 2013 06:02:07 GMT reverse optimus implementation So I took some time today to try and code up a thing I call reverse optimus.<br /><br />Optimus laptops come in a lot of flavours, but one annoying one is where the LVDS/eDP panel is only connected to the Intel and the outputs are only connected to the nvidia GPU.<br /><br />Under Windows, either the intel is rendering the compositor and the nvidia GPU is only used for offloads (when no monitors are plugged in), but when a monitor is plugged in, generally the nvidia takes over the compositor rendering, and just gives the Intel GPU a pixmap to put on the LVDS/eDP screen.<br /><br />Now under Linux the first case mostly works OOTB on F18 with intel/nouveau, but switching compositors on the fly is going to take a lot more work, particularly with compositor writers, and I haven't see much jumping up on down on the client side to lead the way.<br /><br />So I hacked up a thing I called reverse optimus, it kinda sucks, but it might be a decent stop gap.<br /><br />The intel still renders the compositor, however it can use the nvidia to output slaved pixmaps. This is totally the opposite of how the technology was meant to be used, and it introduces another copy. So the intel driver now copies from its tiled rendering to a shared linear rendering (just like with USB GPUs), however since we don't want nouveau scanning out of system RAM, the nouveau driver then copies the rendering from the shared pixmap into the nvidia VRAM object. So we get a double copy, and we chew lots of power, but hey you can see stuff. Also the slave output stuff sucks for synchronisation so far, so you will also get tearing and other crappyness.<br /><br />There is also a secondary problem with the output configuration. Some laptops (Lenovo I have at least), connect DDC lines to the Intel GPU for outputs which are only connected to the nvidia GPU, so when I enable the nvidia as a slave, I get some cases of double monitor reporting. This probably requires parsing ACPI tables properly like Windows does, in order to make it not do that. However I suppose having two outputs is better than none :-)<br /><br />So I've gotten this working today with two intel/nvidia laptops, and I'm contemplating how to upstream it, so far I've just done some hackery to nouveau, that along with some fixes in intel driver master, and patch to the X server (or Fedora koji 1.13.1-2 server) makes it just work,<br /><br /><a href='' rel='nofollow'></a><br /><br />I really dislike this solution, but it seems that it might be the best stopgap until I can sort out the compositor side issues, (GL being the main problem).<br /><br />update: I've pushed reverse-prime branches to my X server and -ati repo. public 6 Wed, 24 Oct 2012 20:51:21 GMT raspberry pi drivers are NOT useful So I awake to find an announcement that the userspace drivers for the rPI have been released, lots of people cheering, but really what they've released is totally useless to anyone who uses or develops this stuff.<br /><br />(libv commented on their thread: <a href='' rel='nofollow'></a><br />maybe he'll follow up with a blog post at some point).<br /><br />So to start the GLES implementation is on the GPU via a firmware. It provides a high level GLES RPC interface. The newly opened source code just does some marshalling and shoves it over the RPC.<br /><br />Why is this bad?<br />You cannot make any improvements to their GLES implementation, you cannot add any new extensions, you can't fix any bugs, you can't do anything with it. You can't write a Mesa/Gallium driver for it. In other words you just can't.<br /><br />Why is this not like other firmware (AMD/NVIDIA etc)?<br />The firmware we ship on AMD and nvidia via nouveau isn't directly controlling the GPU shader cores. It mostly does ancillary tasks like power management and CPU offloading. There are some firmwares for video decoding that would start to fall into the same category as this stuff. So if you want to add a new 3D feature to the AMD gpu driver you can just write code to do it, not so with the rPI driver stack.<br /><br />Will this mean the broadcom kernel driver will get merged?<br />No.<br /><br />This is like Ethernet cards with TCP offload, where the full TCP/IP stack is run on the Ethernet card firmware. These cards seem like a good plan until you find bugs in their firmware stack or find out their TCP/IP implementation isn't actually any good. The same problem will occur with this. I would take bets the GLES implementation sucks, because they all do, but the whole point of open sourcing something is to allow other to improve it something that can't be done in this case.<br /><br />So really Rasberry Pi and Broadcom - get a big FAIL for even bothering to make a press release for this, if they'd just stuck the code out there and gone on with things it would have been fine, nobody would have been any happier, but some idiot thought this crappy shim layer deserved a press release, pointless. (and really phoronix, you suck even more than usual at journalism). public 23 Tue, 19 Jun 2012 13:36:42 GMT randr 1.5 demo videos Two videoes on youtube:<br /><br />Randr 1.5 GPU offload:<br /><a href='' rel='nofollow'></a><br /><br />Randr 1.5 USB hotplug<br /><a href='' rel='nofollow'></a> public 0 Mon, 14 May 2012 17:05:58 GMT ripping the X server a new driver API So I've been slowly writing the hotplug support v3 in between all the real jobs I have to do.<br /><br />[side note: When I started out on hotplug. one of my goals was to avoid changing the server API/ABI too much so I could continue side by side testing.]<br /><br />how did I get to v3?<br />v0.1: was called dynerama it failed miserably and proved that using Xinerama as the plugging layer was a bad plan.<br />v1: was the first time I decided to use an impedance layer between some server objects and driver objects.<br />v2: was the a major rebase of v1.<br /><br />v2 was trucking along nicely and I managed to get the design to the stage where PRIME offloading intel/nouveau worked, USB device hotplug with udl worked, and GPU switch worked between two drivers. However v2 duplicated a lot of code and invented a whole new set of API objects called DrvXRec, so DrvScreenRec, DrvPixmapRec, DrvGCRec etc, this lead me to looking at the pain of merging this into the drivers and the server, and my goals of avoiding changing the API/ABI was getting in my way.<br /><br />So before starting v3 I decided to rework some of the server "APIs".<br /><br />The X server has two main bodies of code, one called DIX, and one called DDX. The DIX (device independent X) code and the DDX (Device dependent X code). In the tree the dix lives up in the top level dirs, and for server the DDX lives in hw/xfree86. The main object with info about protocol screens and GPUs is called ScreenRec in the DDX and ScrnInfoRec in the DIX. These are stored in two arrays, screenInfo.screens in the DIX and xf86Screens in the DDX, when code wants to convert between these it can do one of a few things.<br /><br />a) lookup by index, both structs have an index value, so to go from ScrnInfo to Screen you look at screenInfo.screens[scrninfo-&gt;scrnIndex] and other way is xf86Screens[screen-&gt;myNum]. This is like the I didn't try and make an API, I just exposed everything.<br /><br />b) ScrnInfo has a ScreenPtr in it, so some code can do ScrnInfo-&gt;pScreen to get the pointer to the dix struct. But this pointer is initialised after a bunch of code is called, so you really can't guarantee this pointer is going to be useful for you.<br /><br />c) XF86SCRNINFO uses the DIX private subsystem to lookup the Scrn in the Screen's privates. This is the least used and probably slowest method.<br /><br />So also screenInfo.screens contains the protocol screens we exposed to the clients, so this array cannot really change or move around. So I'd like to add screeninfo.gpuscreens and xf86GPUScreens and not have drivers know which set of info they are working on, however (a) totally screws this idea, since the indices are always looked up directly in the global arrays.<br /><br />Now lots of the Screen/ScrnInfo APIs exposed to the drivers pass an int index as the first parameter, the function in the driver then goes and looks up the global arrays.<br /><br />So my first API changes introduce some standard conversion functions xf86ScreenToScrn and xf86ScrnToScreen, and converts a lot of the server to use those. Yay an API. The second set of changes then changes all of the index passing APIs to pass ScrnInfoPtr or ScreenPtr, so the drivers don't go poking into global arrays. Now this is a major API change, it will involve slightly messy code in drivers that want to work with both servers, but I can't see a nicer way to do it. I've done a compat header file that will hopefully allows to cover a lot of this stuff where we don't see it.<br /><br />I've ono other API introduction on the list, Glyph Pictures are another global array indexed by screen index, I've gone and added an accessor function so that drivers don't use the index anymore to get at the array contents directly.<br /><br />Once this stuff lands in the server, a team of people will go forward and port the drivers to the new APIs (who am I kidding). public 2 Thu, 22 Dec 2011 17:28:41 GMT update on hotplug server No new videos yet, need to fix some more rendering bugs so it looks nicer :)<br /><br />So I've been working towards 3 setups:<br /><br />a) intel rendering + nouveau offload<br />b) nouveau rendering + DVI output + intel LVDS output<br />c) hotplug USB with either intel or nvidia rendering.<br /><br />Categorisation of devices roles:<br />I've identified 4 devices roles so far:<br />preferred master: the device is happy to be master<br />reluctant master: the device can be a master but would rather not be<br />offload slave: device can be used as an additional DRI2 renderer for a master<br />output slave: device can be used an additional output for a master<br /><br />For the 3 setups above:<br />a) intel would be preferred master, nvidia would be offload slave<br />b) nvidia would be preferred master, intel would be output slave<br />c) usb devices would be output slaves, however if no master exists, usb device would be reluctant master.<br /><br />I've rebased the prime work[1] on top of the dma-buf upstream work, and worked through most of the lifetime problems. Some locking issues still exist, and I'll have to get back to them. But the code works and doesn't oops randomly which is good.<br /><br />prime is the kernel magic needed for this work, as it allows sharing of a buffer between two drm drivers, so for (a) it shares the dri2 front pixmap between devices, for (b/c) it shares a pixmap that the rendering gpu copies dirty updates to and the output slaves use as their scanout pixmap.<br /><br />So I've done nearly all the work to share between intel and nouveau and I've done the kernel driver work for udl, but I haven't done the last piece in userspace for (c), which is to use the shared pixmap as usb scanout via the modesetting driver.<br /><br />Today I hacked in a switch on the first randr command, so I can start the X server with intel as master and nouveau in offload mode. I can run gears on intel or nouveau, then after the randr command and another randr command to set a mode, the X server migrates everything to the nouveau driver, puts it in master mode, and places the intel driver into output slave mode. It seems to render my xterm + metacity content fine.<br /><br />So the current short-term TODO is:<br />fix some issues with my nouveau/exa port rendering<br />fix some issues with xcompmgr<br />add usb output slave support.<br /><br />Medium-term TODO:<br />worked out how to control this stuff, via randr protocol. How much information do we need to expose to clients about GPUs, and how do we control them. Open issues with atomicity of updates to avoid major uglys. Switching from intel master to nvidia master + intel outputs, means we have to reconfigure the Intel output to point at the new pixmap, but the more steps we put in there for clients to do, the more ugly and flashing we'll see on screen, however we probably want a lot of this to be client driven (i.e. gnome-settings-daemon).<br /><br />Longer term TODO:<br />Get GLX_ARB_robustness done, now that Ian has done the context creation stuff, this should be a lot more trivial. (so trivial someone else could do it :)<br /><br />[1] <a href='' rel='nofollow'></a> public 5 Fri, 21 Oct 2011 11:15:25 GMT hotplug demo video (teaching new tricks). So today I managed to see something on screen doing hotplug work. So I present to you live plugging.<br /><br /><a href='' rel='nofollow'></a><br /><br />Pretty much is a laptop running xf86-video-modesetting driver, with my server, an xterm + metacity. Plug in a USB displaylink device, with a kernel drm driver I wrote for it. (Sneaky xrefresh in the background). and the USB device displays the xterm and metacity.<br /><br />So what actually happens?<br /><br />The X server at the start had loaded drivers using udev, and the a new driver ABI. It exports one X protocol screen and plugs an internal DrvScreen into it.<br /><br />When the hotplug happens, the server inits another DrvScreen for the new device, and plugs it into the single protocol screen. It also copies all the driver level pixmaps/pictures/GCs into the new driver. The single protocol screen at the bottom layer multiplexes across the plugged in drvscreens.<br /><br />This is like Xinerama pushed down a lot further in the stack, so instead of doing iterations at the protocol level, we do it down at the acceleration level. Also I have randr code hooked up so all the outputs appear no matter what GPU they are from.<br /><br />This isn't exactly what I want for USB hotplug, ideally we'd use the main GPU to render stuff and only scanout using the USB device, but this is step one. I also need the ability to add/remove drvscreens and all the associated data in order to support dynamic GPU switching.<br /><br />The real solution is a still a long ways off, but this is just a small light in a long tunnel, I've been hacking on this on/off for over a year now, so its nice to see something visible for the first time. public 9 Tue, 19 Jul 2011 10:00:08 GMT first impression of google plus If you've seen the social network, you know when he launches "The Facebook" the first time he needs his friend with the non-nerd contacts email list, I get the feeling that google plus never got this step.<br /><br />When I joined facebook it was because my mother sent me an invite.<br /><br />The thing is finding out what my nerd friends are doing is easy, they are always on irc or mailing lists or twittering. I'm not sure what google+ adds to this. public 0 Wed, 11 May 2011 07:56:32 GMT glibc - inconsistent interfaces due to arrogance To start off, I don't actually mind arrogant people as long as they back their attitude up with some semblance of sanity, however arrogance without ability pisses me off, and it seems that its the number 1 trait to be a maintainer of glibc.<br /><br />Today someone pointed out F_SETOWN_EX to me which I can use to fix a problem in the X server, however trying to use gettid made me realise why these guys are considered such fuckwits.<br /><br /><a href='' rel='nofollow'></a><br /><br />WTF? glibc exposes 3 interfaces that need the result of gettid passed to them and internally relies on gettid to implement raise properly and it won't expose the interface. Notice in the bug he never addresses the problems, just closes it with "CLOSED ARROGANCE".<br /><br />Other recent glibc fuckwittery includes the whole overlapping memcpy issues in F14 breaking flash for everyone, and trying to remove the rpc implementation a week before the F15 final release freeze, so that if the package had gotten in and packages that needed a rebuild for say a security fix would mean linking the fixed package against a different RPC library than the original which could cause untold pains.<br /><br />So really if glibc could DIACF already thanks. public 19 Tue, 29 Mar 2011 00:11:55 GMT upgraded + planet software to venus This is a test post hidden in an informational post.<br /><br />I've upgraded the planet generator software for and to the latest venus codebase.<br /><br />This was mainly due to the older planet software running p.fd.o taking down the webserver once or twice this week.<br /><br />Hopefully it doesn't do any damage. public 0 Sun, 23 Jan 2011 23:25:19 GMT LCA 2011 First day of LCA 2011 at Kelvin Grove QUT Brisbane.<br /><br />I'll be organising the Southern Plumbers mini conference today, and will be speaking on Thursday at 11:30 AM about graphics drivers (who'd have guessed). public 0 Tue, 07 Dec 2010 04:42:55 GMT working t410s intel/nvidia basic switching git repo:<br /><a href='' rel='nofollow'></a><br />branch: drm-nvidia-switch<br /><br />So I have a T410s with an LVDS panel and switchable graphics between intel and nvidia. I've gotten the basic switching support just like we have on the intel/amd combination.<br /><br />The code is a start towards generic nvidia/nvidia and intel/nvidia switching but its missing some bits. The MUX switch on some GPUs relies on passing a parameter to the WMI function that we aren't passing, luckily the lenovo doesn't need this parameter at the moment so it works fine. Other laptops in this range may require the parameter.<br /><br />I'll try and get some more info on the magic value we need to pass on other systems to make it work better, other systems like the Sony Vaios have a number of muxable outputs listed in a table, that the intel acpi code prints out at drm.debug=0x4. Again the lenovo doesn't have this table.<br /><br />Other issues:<br />once switched and powered off the Intel, we get log spam from the IPS driver about the MCP limits.<br />nouveau gets a 1024x768 console since we can't detect the LVDS panel at startup.<br /><br />also, this only works with open source drivers, i915 and nouveau. public 24 Tue, 09 Nov 2010 01:09:27 GMT some info on intel/nvidia switchable Okay I sat down for a few hours last week with a switchable Intel/NVidia GPU laptop, and at least worked out some more info. I'm going to braindump it here.<br /><br />Firstly in intel_acpi.c jbarnes has worked out some of the values for outputs in the ACPI tables esp around what is and isn't MUXed.<br /><br />Now we had suspected that one of the nvidia GPU DSM methods (method 5) might actually do something, but a deeper investigation along with mjg59 made us realise it isn't the mux control, so we started looking elsewhere.<br /><br />So we tracked down the MXDS method which is attached to the ACPI outputs per GPU, there is one on the LVDS for the internal GPU and one on the LVDS for the external GPU. So it appears that this is the mux switching object. Looking further up it appears that this is called via a WMI interface, so to do this all properly it looks like we need to write a WMI driver to call the mux switching, instead of just banging on ACPI methods.<br /><br />So going forward a WMI driver needs to be written to which you pass the ACPI output IDs to the WMI MXDS method, and it should switch the mux.<br /><br />Now despite this we didn't actually get the switching to happen, nouveau never got an auxch connection to the panel on the laptop, so I'd really like to see if anyone is useful enough to take this knowledge and make it do something on an LVDS laptop, all I have locally are a big pile of hacks.<br /><br />Thanks to Jesse Barnes for the laptop, and Matthew Garrett for the ACPI decoding.<br /><br />[update: one commentor asked about Macs, they have a non-WMI, non-ACPI method of handling things, sidolin on #nouveau at one stage mostly reverse engineering the mux, which was just reading/writing some memory mapped I/O ports to do the switch, not sure how far he is from pushing some patches out]. public 8 Sat, 25 Sep 2010 03:29:40 GMT Southern Plumbers Miniconf CFP (LCA 2011 - Brisbane) As part of LCA 2011, we are organising a mini-conference to provide a place for low-level system developers to gather and discuss interesting aspects of the kernel and lowlevel userspace. This miniconf is aimed at a similar audience to the Linux Plumbers Conference.<br /><br />We'd really like to have talks that are entry points to open floor discussions and interactive sessions, though if a talk is interesting enough it will be considered depending on the quality of other submissions.<br /><br />Areas of interest:<br /> - Linux kernel<br /> - / Mesa<br /> - toolchain/gdb (not deep compiler stuff, more system interactions)<br /> - udev/u*/*Kit/hal replacements<br /> - systemd/upstart/sysvinit<br /> - virtualisation<br /><br />The Southern Plumbers mini-conference is planned for Monday 24th Jan 2011.<br /><br />Please send all submissions to Submissions will close on Friday, October 29th (when I leave for the real Linux Plumbers Conference), though I may accept submission over the week of LPC as well if I can drum up interest.<br /><br />CFP available at <a href='' rel='nofollow'></a><br /><br />--<br />Dave Airlie and Matthew Wilcox. public 0 Sat, 03 Jul 2010 01:28:52 GMT embedded GPU : what are they hiding? So to follow on from my posting stating my position wrt kernel drivers for closed source userspace drivers, lets take a look at the embedded GPU industry and Linux kernel relationship.<br /><br />What does the embedded industry get from Linux?<br /><br />They get a kernel which is royalty free, with 1000s of man-years of development experience and resources. Before Linux these vendors either sourced an OS on a royalty basis from some closed-shop, or rolled their own in-house one.<br /><br />Now people might say "but the embedded GPU industry has to support Windows as well", but take one look at NVIDIA Tegra One and you can see the embedded windows marketplace is less than important, NVIDIA Tegra Two is all about the Linux, whereas they were pretty much only talking to MS on Tegra one.<br /><br />So Linux is a great boon for this industry, and means they can produce higher quality products for a lower cost (or lower quality products at a lower cost in some cases). So really there are probably two games in town for these embedded vendors, selling into Apple or selling into Linux centric developments, like Android, Meego, Linaro.<br /><br />So what are they actually hiding in userspace?<br /><br />The main thing they seem to be hiding is shader compilers and their GPU assembler code, things that convert from GLES into the assembler code for their GPUs. This stuff isn't rocket science but it probably is where most of their speed up and tricks are hidden. <br /><br />So why do they think it valuable?<br /><br />I think all 3D IP vendors dream of becoming Imagination Technologies, they need to learn there is already one Imagination Technologies and the only way to easily disrupt their revenue stream and sell into other SOCs is to be disruptive, not just follow the herd. They also probably had to spend a lot of money writing a decent GPU compiler from scratch, whereas most embedded firmware is a lot more trivial, so they probably think they need to directly recoup the costs from this development instead of giving it away. The thing is they are hw vendors, the sw is a sunk cost, opening it would actually make future maintenance easier. HW companies never do well at SW and they would be best to just open it and try and involve some community development around it.<br /><br />Is the value of this IP more valuable than what the receive from Linux?<br /><br />This is the crux of my issue with these vendors, they are receiving the Linux kernel for free, but don't want to contribute anything back. They know they can't sell into any where else except Linux driven products, but they insist on keeping their development methodologies from the days of Windows and their own in-house OSes. Those days are gone, but they cling to the idea that for some reason they can produce a better GPU stack on their own than they could in collaboration with other, despite the fact that the kernel that forms the basis for their sales was developed in this fashion. They also all use gcc as the compiler for their CPUs again proving the insanity.<br /><br />Isn't it up to them what they do?<br /><br />Totally, but its also up to the Linux community to push back against them. The thing is they'd never have opened any code if it wasn't for the GPL making them at least open the kernel portions, they don't care about freedom or GPL, they care about their bottom line, and doing the least amount of work to remain legal and make money. Now they are getting all this wonderful software for free, Linux phone sales are driving their bottom line, but they still don't want to play the game by the rules of the kernel. They want to have their cake and eat it too. (the cake is a lie). Hence they spend their time creating their own solutions in private, releasing what they have to comply with legalese but never actually allowing people the freedom to use their devices.<br /><br />So shouldn't we give a little?<br /><br />The thing is two major vendors have been pushing Imagination Technologies for years to open something, these guys are aiming to sell thousands-&gt;millions of devices, we have gotten the ugliest kernel shim in the world in 4 years of trying. All the other vendors are only willing to give that little. I don't personally think any of them want to open this stuff and will hide behind IP excuses for ever.<br /><br />What will make them change their minds?<br /><br />a) money and lots of it. If google or olpc can demand open driver commitments (in contracts, not handwaving agreements) then I suspect these vendors will quickly realise the value of their IP is dwarved by the value of sales. This probably means a major chance for one of the vendors to control a lot of the space in the Linux world.<br /><br />b) disruptive vendor, one vendor realises before the others that opening their IP will lead to more sales than keeping it closed and also lead to the chance of more people optimising their technology and leveraging other work in the industry.<br /><br />So are you saying they should drop all their in-house developed solutions?<br /><br />No I'm saying that the driver for their hardware is a single entity, and if the whole entity isn't open, then none of it is truly open. So if they don't want to release an open userspace, then they don't get to merge their open kernel bits to support the closed userspace. We have to keep the maintenance burden on them, so it keeps costing them money to track newer kernels, and they don't get community support from other vendors who have committed to doing things right.<br /><br />So why should they re-write drivers?<br /><br />This happens in Linux the whole time, with nearly every new technology. Wireless, RAID, SATA for example, all have had vendors trying to push complete stacks of their own writing, you'll notice over time the drivers that are actually written to the current stacks work best, an the crazy vendors drivers are often horror shows. <br /><br />What would be nice to happen?<br /><br />It would be great if there was a hero with time/funding and involvement in the ARM GPU community to take over being maintainer of these solutions, from kernel all the way to userspace. Vendor driver writers could ask this person for advice, and they could have some sort of working group where they develop a stack based around current Linux technologies, like GEM/TTM/DRI2/Mesa/Gallium3D. If you take a look at the mesa stack lately, there has been a lot of work on making it work as an EGL/GLES stack as well as a classic GL stack. Then vendors would supply open drivers compliant with this stack, and just sell lots of chips.<br /><br />What would be most likely negative solution?<br /><br />We get what we have now, they maintain the 5-6 GPU stacks in their own world, and never talk to each other, and it costs them more and more money going forward to maintain. Some hero reverse engineers one or two of the GPU architecture, maybe some hero writes a open driver stack from docs under NDA or with open docs.<br /><br />I may update this post as I have more thoughts ;-) public 15 Thu, 01 Jul 2010 23:42:14 GMT open source kernel bits with closed source userspaces [I posted this to lkml earlier - discussion should happen there not in comments here, but its nice to have somewhere easy to point people at].<br /><br />Now this is just my opinion as maintainer of the drm, and doesn't<br />reflect anyone or any official policy, I've also no idea if Linus<br />agrees or not.<br /><br />We are going to start to see a number of companies in the embedded<br />space submitting 3D drivers for mobile devices to the kernel. I'd like<br />to clarify my position once so they don't all come asking the same<br />questions.<br /><br />If you aren't going to create an open userspace driver (either MIT or<br />LGPL) then don't waste time submitting a kernel driver to me.<br /><br />My reasons are as follows, the thing is you can probably excuse some<br />of these on a point by point basis, but you need to justify why closed<br />userspace on all points.<br /><br />a) licensing, Alan Cox pointed this out before, if you wrote a GPL<br />kernel driver, then wrote a closed userspace on top, you open up a<br />while world of derived work issues. Can the userspace operate on a<br />non-GPL kernel without major modifications etc. This is a can of worms<br />I'd rather not enter into, and there are a few workarounds.<br /><br />b) verifying the sanity of the userspace API.<br />1. Security: GPUs can do a lot of damage if left at home alone, since<br />mostly you are submitting command streams unverified into the GPU and<br />won't tell us what they mean, there is little way we can work out if<br />the GPU is going to over-write my passwd file to get 5 fps more in<br />quake. Now newer GPUs have at least started having MMUs, but again<br />we've no idea if that is the only way they work without docs or a lot<br />of trust.<br /><br />2. General API suitability and versioning. How do we check that API is<br />sane wrt to userspace, if we can't verify the userspace. What happens<br />if the API has lots of 32/64 compat issues or things like that, and<br />when we fix them the binary userspace breaks? How do we know, how do<br />we test etc. What happens if a security issue forces us to break the<br />userspace API? how do we fix the userspace driver and test to confirm?<br /><br />c) supplying docs in lieu of an open userspace<br />If you were to fully document the GPU so we could verify the<br />security/api aspects it leaves us in the position of writing our own<br />driver. Now writing that driver on top of the current kernel driver<br />would probably limit any innovation, and most people would want to<br />write a new kernel driver from scratch. Now we end up with two drivers<br />fighting, how do we pick which one to load at boot? can we ever do a<br />generic distro kernel for that device (assuming ARM ever solves that<br />issue).<br /><br />I've also noticed a trend to just reinvent the whole wheel instead of<br />writing a drm/kms driver and having that as the API, again maintainer<br />nightmares are made of this.<br /><br />d) you are placing the maintenance burden in the wrong place<br /><br />So you've upstreamed the kernel bits, kept the good userspace bits to<br />yourselfs, are stroking them on your lap like some sort of Dr Evil,<br />now why should the upstream kernel maintainers take the burden when<br />you won't actually give them the stuff to really make their hardware<br />work? This goes for nvidia type situations as well, the whole point is<br />to place the maintainer burden at the feet of the people causing the<br />problems in an effort to make them change. Allowing even an hour of<br />that burden to be transferred upstream, means more profit for them,<br />but nothing in return for us. public 3 Tue, 04 May 2010 23:30:46 GMT lolbuntu Ted with the smackdown:<br /><br /><a href='' rel='nofollow'></a><br /><br />Update:<br />when you can't fix bugs in your "enterprise distro" file them against someone elses community distro:<br /><a href='' rel='nofollow'></a> public 0