| Hardware MPEG2 Slice decoding added to unichrome driver. |
[Nov. 4th, 2009|10:24 pm] |
I just pushed out code which adds MPEG2 slice decoding to my graphics driver. It is based on XvMC, but unlike "standard" XvMC implementations, it sends MPEG slices over to the graphics driver over the X protocol.
The base idea is the following: The MPEG engine gets MPEG slices, and outputs to a buffer. This buffer needs to then be displayed by the overlay engine. So, we need to spend most of our time managing the communication and syncing of those engines. We already have the other video engines implemented nicely, so, why not stick the MPEG code next to that and have a nice and clean implementation?
The XvMC protocol, X-wise, is mostly about telling the driver that the MPEG hardware is in use, and subsequently claiming buffers in the framebuffer, managed by the X driver. Everything else is expected to happen in the client library. For what reason, i do not know, but part of it could be that, this way, X is not seen to eat any CPU cycles. In any case, this makes it a very weird protocol, with things spread all over the stack.
Things were made worse with the advent of the XvMC wrapper. Instead of expanding the XvMC protocol slightly to provide the name of the XvMC client library to be loaded, DRI is abused for this purpose. So... a pointless hard dependency on DRI is added, and now, no working DRI means no working XvMC... Curious. Makes the pointless dependency on Shm look harmless.
So what i did now is send all the data over the X protocol, over a tiny X extenstion, so that it could be fed into the hardware and synced inside the X driver. An XvPutImage with a longword buffer containing the mpeg buffer id then makes sure that everything gets displayed correctly. And while the overlay is being set up, the mpeg engine can finish its work, and at the very last minute, the overlay code waits for the mpeg engine to finish, and then the overlay gets told to display the new image.
Other XvMC implementations went and completely reimplemented the overlay in the client library, and even involved 2d acceleration to be able to send mpeg slices to the hw a bit faster. A syncing nightmare. Another advantage is that my implementation can implement the newer mpeg2 engines in just a few hundred highly hardware specific lines.
Of course, sending this data over the X protocol in tiny bits does incur some more cpu cycles, and i also am not feeding mpeg data into the hardware over the command buffers. Because of this, my code uses about 30-35% for a normal DVD (write a comment if you guessed which :)) on a VIA C3 Samuel2 (yes, half speed FPU, not quite PPro compatible) at 600Mhz, while openchrome uses 20-25%, roughly 2/3rds. But the performance of my code is still very good, good enough to not bother with speeding things up just yet.
As usual, it is easy to get this new code. It builds and runs against all Xorg versions that are common, and the debian package build system has also been updated for the xvmc code.
For xine there is one caveat, due to the horrible implementation of video_out_xxmc. We need to fool xine into thinking that we do support subpictures (we don't as it the xxmc way of implementing things didn't even get close to how the hardware implemented it). For that, the following option needs to be set:
Option "XvMCBrokenXine" "True"
in the device section of xorg.conf.
Enjoy! |
|
|
| Surely i am not the only one seeing this... |
[Sep. 14th, 2009|06:28 pm] |
| [ | Tags | | | icaza, novell, ximian | ] |
| [ | Current Location |
| | couch | ] |
| [ | mood |
| |  surprised | ] |
| [ | music |
| | Lack of Afro - Press on - Wait a minute | ] |
I just scrolled over planetsuse. The art of scrolling over blog aggregators is mostly in filtering out all the information and retaining quick impressions and then reading that what triggers something.
And what triggered my synapses was the logo of monotouch. Here is a screenshot:
Is novell really selling enterprise versions at 1k usd of a product with a mis-designed logo which gives you the finger?
Guessing from the side-thingie off what most people will see as the middle finger, the real intention was not to make a rude gesture. Also, there are some projects for which the finger might be a good logo, but i am sure that anything involving mono just isn't suited for that.
So i am assuming that the following is was what the logo was supposed to look like.
Small change, significant difference.
Oops. |
|
|
| Libv, the tale of a missionary. |
[Aug. 7th, 2009|04:29 am] |
Tonight there was some random guy sitting at the bar in our thursday hang-out, downtown, with a t-shirt reading "League of gentlemen" and a rather clueless logo to go with it. As a fan of good British humour, I stepped up to him and this is the conversation that ensued.
"Excuse me, that t-shirt that you are wearing, is it in any way related to the magnificent BBC TV/Radio Show?"
The guy managed the following in his best english: "Eh? It is some brotherhood from Nuernberg"
"Oh, so it is a local brotherhood, for local people?"
"Yeah! That's it exactly!" is what he answered enthusiastically.
I think i have created another convert ;) |
|
|
| Coreboot native VGA support. |
[Jul. 23rd, 2009|02:51 pm] |
I didn't exactly intend to time this in the middle of Novell's Hackweek, as my personal hackweek pretty much started the day after FOSDEM. But oh well, it finally did happen and it happened just now. And it was much overdue, since it was mostly written in the months before i even joined SuSE. And when i was at SUSE it got pushed aside while we were freeing AMD graphics hardware and were busy fixing bugs in X.org so that it could still ship with new openSUSE/SLED releases.
On the other hand, this very week, it has been 6 years since i got the EPIA-M board that got me started on graphics driver development. This might not seem that important to you, and some people have worked hard to minimalise the importance of this too; but this board has quite significantly changed the world of free graphics drivers.
Anyway, here it is, finally; Coreboot native VGA textmode!
For those who don't know Coreboot; Coreboot provides the basic HW initialisation needed to bring up a motherboard so that an operating system or other payloads can be loaded. It was called LinuxBIOS until 2008, when everyone agreed that LinuxBIOS was too much of a misnomer. Now if you want to rid yourself of proprietary/closed source software properly, then replacing your machines BIOS with coreboot (and a payload) is the way to go.
Until now, if you wanted working graphics with coreboot, you were still tied to the PCI option rom of your graphics card. This code i just pushed out makes even this last vestige of non-free software disappear.
So if you happen to have a VIA motherboard with a K8M890 Northbridge (AMD PCI-Express) with a Chrome 9 IGP, that is supported by coreboot; then you can have native VGA textmode today.
Introducing the Asus M2V-MX SE: a nice little micro-atx motherboard with AM2 support, DDR2, VIA Chrome 9 IGP. It has absolutely stellar coreboot support, and it can be often seen at trade shows, showing off working suspend/resume and even windows 7 booting. Now if you do not want something like windows 7 booting, then you can get rid of the VGA BIOS completely and get a nice working text console with, for instance, linux.
Don't ask me what sort of fancy modes you can set with this. What you get here is just 80x25 VGA textmode. Yeah, that's right; proper old-style VGA textmode, the sort that everything PC out there supports. The sort that, when things go slightly awry, you are always happy to see. The sort that has saved you so often.
It should be clear that my intention with this was not to re-invent some BIOS infrastructure to do modesetting, or to provide an INT10 or VESA implementation. To me, having fought BIOSes for graphics for the best part of this decade, that sounds pretty pointless. And as you might remember, my unichrome driver has been able to bring up un-posted hardware without issues for quite a while. What I wanted here is the basic infrastructure to see what is going wrong with a booting system, before a proper driver has kicked in, and be able to fix it without having to rely on a serial console.
This code achieves just that goal, and it consists of two parts.
First of all, there is the general, standard part, that any IBM PC compatible graphics adapter from the last 20 years should be able to use: the VGA side of things; vga io routines, and an actual VGA 80x25 modeset complete with cursor and font handling. This code was already committed late May in the hope that my EPIA-M would stop fighting back soon, and partly thanks to the font included, it was quite a big blob of code that got pushed into coreboot then.
The second part, is the K8M890/Chrome 9 specific part: initialising the hw in such a way that a full VGA modeset can use the hw happily. This is barely a few hundred lines of code.
Why just a few hundred lines? Well, this is IGP hardware, so the gpu is sitting off the northbridge, and has a (in this case, semi-)direct route to the systems main RAM and uses part of that for its framebuffer. There is also little of this running-things-on-the-absolute-edge nonsense that is so common on discrete cards. Coreboot sets up the ram for us, it sets up the BARs and io/irq routing for us; all we have to do is set up a vga mode, and fill in the bit in between.
On a board as well supported as the Asus M2V-MX SE this bring-up was a walk in the park, it basically took the best part of yesterday morning. And this exercise is very reproducable for the other unichromes as well. But the first one after this should still be my 6y old Epia-m board into shape with coreboot still (ints and VT8235 IDE *rolls eyes*), this board deserves nothing less.
Oh, one more thing; if you have an M2V-MX SE and wish to try this code, then i would like to advice you to hold off a bit. We need to still shore up the cmos settings and make it more foolproof. I seriously doubt that people enjoy having their machines stop during RAM initialisation because they tried to change the default framebuffer size. This is due to other settings in a badly initialized CMOS getting validated when the videoram size setting fixes the checksum. It shouldn't take long to fix this, and then, running coreboot on this board shouldn't be that scary for even the less experienced hacker. |
|
|
| bios_extract, the tool for all, err, some of your bios extraction needs. |
[Jul. 13th, 2009|12:06 pm] |
As everyone by now knows, i dislike bioses, for a variety of well-founded technical reasons that i am not going to repeat yet again. Not only have i been fighting BIOS based modesetting for ages, but i am also involved with coreboot and flashrom, doing (hopefully) my part on freeing hw.
But, legacy bioses are chock-full of often very important information that chip or board makers are unable or unwilling to give you, even if it is just to be able to tie 2-and-2 together so that datasheets make sense. So, being able to find what you need to know from a legacy bios is an important skill to have, even though it often resembles sticking ones hand up a drainpipe and rummaging around in the muck.
Now, you often cannot just point a disassembler to a legacy BIOS image, because, in order to save space, much of the important code is to be found in compressed modules within this larger image. At boot, these modules are decompressed as soon as some memory has been set up. And while some of this code survives long after booting in the upper segments, parts of this code gets overwritten soon after being run.
There are a few utilities around to go and extract these modules from legacy bios images into individual files, but they were not always easy to get, build or use. Plus, the code wasn't always that nice, and each tool was made for one vendor and they re-used some version of the same lh5 extraction routine over and over again.
So, using some of the very valuable information and code from these utilities, i created bios_extract, with a cleaner structure, cleaner code and a very simple interface. It currently handles AMI, award (and thus also asus) and phoenix (non-trustedbios) BIOSes, and can be expanded easily to support other BIOS types.
You can find it in my fd.o git, from which it should be easy to build, as it requires nothing but glibc. And you just point it to a BIOS image, and it will happily clutter up your working directory for you.
As usual, if it isn't working as expected for you, feel free to poke me wherever you find me :)
And of course, another nice use of this utility is extracting PCI Expansion ROMs from onboard devices, like IGP graphics, raid controllers, nic boot roms, etc, for inclusion in a coreboot image. Even though for IGP devices, i am working on getting rid of this at least for unichrome.
In any case, have fun rummaging around! |
|
|
| Congratulations to ATIs John Bridgman... |
[May. 18th, 2009|02:51 pm] |
| [ | Tags | | | ati | ] |
| [ | Current Location |
| | couch | ] |
| [ | mood |
| | amused | ] |
| [ | music |
| | Metallica - Master of puppets 02 - Master of puppets (1986) | ] |
... for becoming the second most frequent poster on the phoronix forums. You've finally beaten the Phoronix Newsbot. With a total average per day posting rate of ~4.5 and a rate of more than 8 for the last 100 posts, this is an amazing effort and i am certain that AMD appreciates the time you spend on this.
According to my quick calculations, at your current sustained rate, it will only take until June next year until you become the number 1 poster, beating Michael Larabel, the person who runs phoronix, himself.
Keep up the good work! |
|
|
| Last preparations for the X.org DevRoom at FOSDEM. |
[Feb. 5th, 2009|04:04 pm] |
| [ | Tags | | | fosdem, x | ] |
| [ | Current Location |
| | office | ] |
| [ | mood |
| |  sleepy | ] |
| [ | music |
| | Fingathing - You fly me | ] |
Tomorrow morning, notlocalhorst and i will fill up the car with our stuff, and then we will head off to FOSDEM, and we're destined to arrive somewhere in the early evening, if cologne isn't too big of a traffic mess.
Since the kind organisers of FOSDEM gave X.org the H.1309 room for our DevRoom, we have massive capacity this year: 150 seats! I just went to a local DIY store to pick up some more 10x powerbars. I'll be spreading 7 of those bars around our DevRoom on saturday so that those that need power in the era of 7h battery life netbooks, can still get it :)
Next to that, i'm mostly occupied by printing nametags, some posters, some schedules i can put on doors/walls; the standard stuff that happens in the last day before a DevRoom :)
So tomorrow is travelling to brussels, checking into our hotel, and then heading to the grand place to meet some other X folks for supper.
On saturday at 13:00 we'll be busy setting up the room, and at 14:00 Matthias Hopf will start of with talking about the new features in RandR 1.3. At 15:00 Keith Packard will talk about recent achievements with GEM, KMS and DRI2 in "The rebuilt linux desktop". This is followed by Stephane Marchesin giving us an update on the state of the nouveau driver at 16:00. Then Eric Anholt will talk at 17:00 about intel's graphics projects for the next year.
On sunday things will start off with Helge Bahmann at 11:00; Multimedia processing extensions for the X Window System. Next up is Matthew Garrett talking about power management. At 14:00 Matthias Hopf is up, again, but this time talking about R600_demo. At 15:00 we get Marcheu again, as well, but now talking about LLVM and Gallium3D. Then our DevRoom gets cleared out proactively by Jerome Glisse, and he will be talking about some common algorithms for shader optimisation.
After that, it's tearing down the devroom, clearing out the trash, loading up the car, and then driving back to Nue. The latter should promise to be interesting, as we will have another burgerking versus macdonalds struggle :)
Anyway, we will have another packed DevRoom at FOSDEM, make sure you don't miss it! |
|
|
| X.org DevRoom at FOSDEM 2009. |
[Dec. 3rd, 2008|02:15 pm] |
| [ | Tags | | | fosdem, x | ] |
| [ | Current Location |
| | office | ] |
| [ | mood |
| | excited | ] |
| [ | music |
| | Fingathing - You fly me | ] |
I am saddened to have to announce to you that that we have yet another abominable and boring X.org DevRoom at this little known and unimportant event called FOSDEM. Terrible! Why do such horrible things keep on happening?
Maybe because the Xorg DevRoom is simply one of the biggest, most interesting and definitely one of the hottest DevRooms at the most important and most well known European free software event of the year?
I'm sure none of you need to be explained what FOSDEM is anymore, all you really need to know is when it will happen this year: the weekend of the 7th and 8th of February.
This is the fourth year running that we have a DevRoom there, and the next big X event is in the late summer/early fall in the US, so the DevRoom promises to be bigger and better than ever before :)
Check out the fosdem2009 page on our own X.org wiki for the latest information, and for the planned talks and the schedule as it materialises.
The usual suspects will be there as, so expect some interesting talks and discussions, and Michael Larabel will be recording the talks again.
But in order to get a packed schedule, we still need more speakers! We have about 13 slots maximally available. Talks of about 45 minutes, about something X related, and please don't shy away from highly technical stuff.
If you have something to talk about, please contact me as soon as possible. A FOSDEM DevRoom is one of the most ideal places to reach a large and interested audience.
But everyone, mark the 7th and 8th of February in your calendars, and start arranging travel to Brussels already! And keep on checking our wiki page for updates |
|
|
| The truth behind what happened at Lenz... |
[Nov. 19th, 2008|12:39 am] |
| [ | Tags | | | lenz | ] |
| [ | mood |
| | amused | ] |
| [ | music |
| | Norman Greenbaum - Spirit in the sky | ] |
@The Daemon: Well... I was late, as always, so i missed this scene, and i also missed Judas, as he left already so he could talk to security people quicker :p
But remind me; who was it again who blessed the bread he got with his papardelle, and who subsequently passed that bread around that table?
@The Daemon, again: It's not size that matters; it's what you do with it! In this case; actually drinking it instead of waiting for it to die first, you sloth :)
But, to answer the question: the one which isn't being touched by an X developer, of whom you never know where he has been, and the one which was paid for by a friendly toolchain developer! |
|
|
| Now in radeonhd: CS and HDMI Audio. |
[Oct. 27th, 2008|09:58 pm] |
| [ | Tags | | | x radeonhd ati amd | ] |
| [ | Current Location |
| | office | ] |
| [ | mood |
| | accomplished | ] |
| [ | music |
| | Sneaker Pimps - Splinter - Destroying Angel | ] |
Two weeks ago, i pushed CS into the radeonhd master tree. CS stands for Command Submission, a unified way of putting high volume register and packet writes into the radeon HDs various hardware engines.
Even though this meant a massive change to the code base (dropping close to 7k and making the lot much more manage-able and handle-able.) the fall-out of it was rather limited. One recently introduced build issue, one oversight with the rewritten engine state tracking (missed because i was too busy chasing a stupid hardlock). But all in all, quite succesful.
What does this code gain us? Well, our driver is clean again, with all subsystems kept separate as much as possible. And, it gives us an easy path for adding new CS back-ends. Changes to the drm? Direct hw support, like CP ringbuffer in framebuffer (do you want some EXA render accel or textured video without drm, then this is it)? No problem, in a few hundred lines we have a whole new back-end now. So while CS might seem boring, it makes good coding sense :)
Now today i finally managed to successfully test something else: Christian Koenig's excellent HDMI Audio code. Putting this into master was long overdue, especially since Christian's code is very high quality and fuses in with radeonhd perfectly.
The Dell 3008WFP monitor we had here has not been very helpful in testing this code, but we stole a proper TV from the SUSE playroom and got this code tested that way. I pissed off a few wii players and the facility guy in the process (shouldn't you guys be doing this thing that's called work btw?), but now Christian's code finally got libv's stamp of approval ;)
So, get the current git, and either enjoy the new CS infrastructure (r5xx) or the fantastic HDMI Audio (r6xx and up) or both (rs690). And of course, if you do run into issues, tell us asap!
Oh, and to Yaloki and Henne who made it to the openSUSE board: congrats! Now where are the celebratory beers? |
|
|
| Belgian expat life-saver. |
[Oct. 9th, 2008|10:32 am] |
| [ | Tags | | | belgium | ] |
| [ | Current Location |
| | couch | ] |
| [ | mood |
| | chipper | ] |
| [ | music |
| | Dave Brubeck - Take five | ] |
When i was still in belgium, i was tracking news quite heavily, i made sure i caught at least one daily journal of the VRT (first channel of belgian national TV) and one Terzake on Canvas (a more in-depth program on three important topics of the day of the second channel of belgian national TV). This was an easy thing to do, as both were repeated throughout the night, and at one point during the night, whenever i was tired of hacking, whenever i woke up, or whenever i was hungry, i would just spend an hour in front of the TV watching these programs, and stay right up to date and very informed, even though i was pretty much living like a hermite.
But ever since i started working for SuSE, and ever since i moved to Nürnberg, i have been completely without such news. This for instance, made me miss all the fun and games after the June 10 2007 belgian national election, and the wannabe PM singing the marseillaise. Finding out about such in incident months later was rather saddening for me, as i tend to enjoy seeing what games the politicians are up to in this "interesting" little country. Reading through the fragments on the belgian TVs website is not fun at all, and i have been spending more and more time reading articles on the BBC world website now.
Now yesterday, i was reading through planet.grep.be and stumbled over Frank Goossens's blog entry about automatically re-assembling the broken-up bits of these programs that are spread all over the website of the belgian national TV. I then watched the news as part of my pre-bedtime ritual, and just now watched terzake as part of my breakfast ritual. It was fantastic! Sure, the video-stream is not the greatest. Sure, there are some sound issues going from one clip to the other. But those are minor details and don't diminish the informational value of this at all.
Thanks a bunch, Frank, this means a lot to me. |
|
|
| Updated hackergotchi. |
[Oct. 6th, 2008|05:08 pm] |
| [ | Tags | | | hair! | ] |
| [ | Current Location |
| | office | ] |
| [ | mood |
| | accomplished | ] |
| [ | music |
| | Van Morrison - Brown eyed girl | ] |
Just spent 12 days in malta, on a holiday that included a lot of eating, drinking (cocktails and Cisk lager), talking tons of nonsense (as per usual) with equally interesting people, a lot of swimming, some culture (mostly churches :(), and even some hiking.
Being in a mediterranean climate in early autumn has some effect on a persons appearance...
Ordinarily, since i ride a bicycle or fly gliders on the weekend, my skin colour is two-toned, as i don't tend to expose much of my geeky white body to sunlight directly. But now, after a lot of swimming and wearing shorts and some sunbathing, i am somewhat more evenly coloured.
I also lost my long hair. For about half my life, i wore my hair very long. I had stopped wearing it in a ponytail about 5 years ago and have been thinking about cutting it off for a few months now. But now the salt water and the direct sunlight made my hair very unruly and uncontrollable. So the decision was made, and it got the axe there and then. As usual, i either do all or nothing, so i went from shoulder-length (for those bits that still wanted to go that far) to about 7mm all over.
So far, I've received an "Oh Gott", a few "who are you and what have you done to libv"s, a few nervous giggles and a lot of surprised looks, but overall, after the shock has worn off, impressions seem to be very positive. Especially today is a bit interesting, now that i'm in the office again :)
In any case, i needed to spend half an hour with the southpark generator, as my previous hackergotchi was kind of out of touch with reality:
And no, that is not a peace sign i am making, it's a secret hand-symbol that only a select few will understand :) |
|
|
| Radeonhd CS branch! now with exa compositing! |
[Aug. 4th, 2008|11:00 pm] |
I've finished porting over the 3d engine initialization and EXA composite code from master to the CS infrastructure. Since no buffer mangling was done by this code, the conversion was actually rather painless. The codefiles from master/quick_and_dirty_2d have been mostly kept, and just some macro work was provided to make it run on top of CS plus some voodoo to make it build as standalone files.
I have had no chance yet to test this on direct CP on r5xx, and this code sadly will not work on MMIO, so you will have to have a working drm for now if you want to get some performance out of EXA :)
The most time-consuming work here was actually further cleaning up the CS infrastructure, splitting it further from r5xx_accel code. Now CS is so clean that i am considering putting it in horribly styled spray-cans so i can pester people with irritating tv commercials with really nasty overdubbing :)
Anyway, give it a whirl, and let me know ASAP if this doesn't shine your tuppence in 12 seconds flat :) |
|
|
| The RadeonHD Command Submission (CS) branch. |
[Jul. 30th, 2008|11:44 am] |
| [ | Tags | | | x radeonhd ati amd | ] |
| [ | Current Location |
| | office | ] |
| [ | mood |
| | content | ] |
| [ | music |
| | Amon Tobin - Supermodified 02 - Four ton mantis | ] |
As you all might have noticed Tuesday last week, I pushed a new branch into the radeonhd driver: CS, which stands Command Submission.
In the true spirit of the radeonhd driver, this separates out all the muck and yuckiness of feeding commands, be them register writes or CP (command processor) command packets, into the hardware's various engines.
CS has become an infrastructure which does command buffer handling and (command) engine maintainance in a clean way, for both MMIO and DRM CP. MMIO means only register writes to the MMIO aperture. With DRM CP, we use the command processor by feeding it (indirect) command buffers through the DRM.
So now we have both XAA and EXA acceleration running on top of the CS infrastructure. XAA is the existing radeonhd "MMIO-only" code now working on top of DRM CP as well. For EXA, i now also added faster Up/Downloads.
When developing CS, i first went for a clean implementation and making sure the code was well-structured and as nicely condensed as possible. Once this was achieved, i ran benchmarks and optimised the code. When doing so I noticed that our code was running 10x slower on OpenSuSE 10.3 (old, i know) with inline functions compared to macros. After talking to the GCC people here, they confirmed that this was still often the case for the gcc version included in OpenSuSE 10.3, and that it was fixed for the gcc version in OpenSuSE 11. Since our driver needs to give a decent user-experience on a wide variety of systems, i therefor was left with no other option but to turn the calls used in the XAA callbacks (Grab, Write/RegWrite, Advance, all of which are used _very_ often) into macro's. Nasty, but some things cannot be avoided :(
But even so, the macros themselves are small and readable, as the underlying code is nice and condensed, and the we get really good performance out of them :)
So, now that we have the radeonhd acceleration code working when DRI is enabled, we can start working on adding the remaining r5xx acceleration, like EXA Render and Textured Video. After that, new CS back-ends (like direct CP) can be added in.
With Direct CP we are setting up and handling the CP directly from the X driver. Without the kernel to depend on (where we currently fall back to MMIO), we have no other option than to stick the CPs main command buffer into the graphics cards memory. Thanks to the memory virtualisation in the hardware, the command processor knows no different, even though we are not as fast writing into this buffer as when going through the GART :)
The advantage of having a working CP is that we can use command packets, and for our hardware this means that we can have Textured Video and EXA Render acceleration (as the MMIO path there is broken), and we then can, eventually, get rid of the MMIO path completely and further optimize the CS infrastructure.
For R5xx direct CP works, but for rs690, i am running into issues still. I know that the main commandbuffer in the framebuffer on this IGP hardware is in itself ok as high speed memory writes to unbuffered registers are perfectly ok, but as soon as buffered registers are written, one of the FIFOs loses count :(
In the short term, i am going to push out the code and enable it just for R5xx, and keep MMIO around for rs690, but this kind of beats the purpose of Direct CP, as that was getting rid of MMIO in the first place :)
When trying to get rs690 going, the CS really showed its power. I coded up the two other options for stuffing commands into the CP (indirect buffers and stuffing the CSQ directly, as opposed to using the main ringbuffer directly) in a matter of hours. Neither were successful as they showed the exact same issue as when using the main buffer, but it was nice to see how adaptable the CS infrastructure was.
But the ability to easily add different back-ends is important for more than direct CP.
Jerome Glisse has been working on cleaning up/adding to the DRM drivers ioctls to provide cleaner handling of the CP. The cleanup of the drm driver here is much overdue, there are many issues with this code (CP IDLE on a modern CPU is a good example), and it's fantastic that Jerome is working on it. The work does sometimes resembles archeology more than software development, so bear with him :)
Once Jerome's code is working, a new back-end can be written up for radeonhd in a few hundred lines, and we can take full advantage of his work almost immediately. It will ease the burden on Jerome for testing, and it will give us a faster and cleaner DRM CP right away.
So after some hard labour on creating the infrastructure and fitting it into the driver nicely, we are reaping the rewards already :) |
|
|
| X.org FOSDEM devroom aftermath. |
[Feb. 26th, 2008|04:03 pm] |
| [ | Tags | | | xorg fosdem | ] |
| [ | Current Location |
| | office | ] |
| [ | mood |
| | accomplished | ] |
| [ | music |
| | The 5.6.7.8's - Woo hoo | ] |
It's over, and we're all still alive, even though some of us got slightly cooked.
The lack of ventilation is purely an issue with the ULB. It was clear that there was some installation present to achieve this, but the ULB claimed that this was purely there for heating, not for ventilation. Juergen Weigert, who recorded the openSUSE devroom last year, is certain it was providing fresh air last year, but the ULB staff refused to believe the FOSDEM organizers... Really terrible...
Apart from that, things went surprisingly well.
Personally, even though i lost a few kgs, i wasn't as horribly broken afterwards as i was two years ago. I didn't do the insane running back and forth to the cemetery square all the time like i did two years ago, and therefor saved myself a lot of grief. But there are plenty of things that should still be optimized, and i hope i will have at least those ironed out next year.
I'd like to thank Michael Larabel from Phoronix for reporting live from our DevRoom and for recording the talks. Some people don't seem to realize what great effort this was, and instead prefer to complain endlessly about the quality, a missing link or even about the lack of subtitles (WTF?). Please realize that if it wasn't for Michael doing this for us, there wouldn't have been anything to complain about in the first place.
I also would like to thank Alexander Campo for reserving the restaurant for us, and Keith Packard and Egbert Eich for deciding, there and then, that the X.org Foundation would pick up the tab this year. Like last year, the food at Mirabelle was fantastic, while the price was very democratic. And from judging the volume that was produced by our long table holding 21, it was a very successful social event too :)
Also a big thank you to DanielS, for bringing in a handful of bottles on saturday (which triggered me to run over to Colruyt for some more while this supermarket was still open), and for providing 12 more liters on sunday afternoon. I had decided not to provide any refreshments this year, due to the organizational overhead and because it had proven to not be necessary the previous years, but the heat made it an absolute necessity this year round.
Then i would like to thank the speakers for making this the most crowded X.org DevRoom on FOSDEM so far. At one point (for Gallium3D), when our DevRoom was already at full capacity at the start of a talk, one wall got completely covered with people, and people were blocking the airflow through our single door... So i guess about 125 people were in the DevRoom at that point, and i had to refuse entrance for at least 30... Usually our DevRoom held at least 80 people, all enduring unbearable temperatures and humidity... Just fantastic :)
And i do not care what other DevRooms claim... Ours was definitely the hottest, and it had only one door!
To the organizers of FOSDEM; whatever you do, don't change, just optimize. And tame that pesky ULB ;)
We'll be having another Xorg DevRoom next year, and we will try to better this years DevRoom. It's going to be hard to better, but we'll give it our best shot!
Oh, and Localhorst: thursday, downtown, beer, teddy bears ;) |
|
|
| Leaving for FOSDEM |
[Feb. 22nd, 2008|10:56 am] |
We're packing things up for fosdem now and will be heading off to brussels in about half an hour... Hope the traffic isn't too bad, because then we will make it to our hotel before 18:00...
So, hopefully see you tonight... And hopefully we can organize something for dinner tonight... |
|
|
| X Developers Room at FOSDEM: Be there! |
[Feb. 19th, 2008|03:04 am] |
| [ | Tags | | | fosdem, x | ] |
| [ | Current Location |
| | Office... Still... | ] |
| [ | mood |
| |  anxious | ] |
| [ | music |
| | U.N.K.L.E. Featuring Ian Brown - Be There - Be There (1999) | ] |
FOSDEM is drawing very near now, just 4 days left...
Our Xorg DevRoom is jam-packed with smashing talks, here is the schedule:
Saturday:
* 14.30: John Bridgman - Open sourcing ATI.
* 15.30: Egbert Eich - The RadeonHD Project.
* 16.30: Stephane Marchesin - Nouveau : Cooking an Open Source Nvidia driver.
Sunday:
* 10.30: Helge Bahmann - XAudio.
* 11.00: Remi Cardona - Bringing Metisse and X.org together.
* 12.00: Daniel Stone - Fixing X input: the beer coaster roadmap to success.
* 13.00: Lunch break.
* 14.00: Michael Meeuwisse - Project VGA.
* 15.00: Keith Whitwell - Update on Gallium3D.
* 16.00: Jerome Glisse - Radeon, from DRM to Gallium.
* 17.00: Keith Packard - Roadmap to recovery - pain and redemption in X driver development.
Surely, nobody can resist a schedule like that, and there can be no excuse to not be there.
Well... Maybe if you're not into free software, and if maybe you don't care about X and graphical user interfaces at all, and maybe if you live on antarctica, and an ice-bear is about to eat your family... But only then. |
|
|
| RadeonHD: Basic R5xx XAA/EXA support pushed. |
[Jan. 29th, 2008|11:53 pm] |
| [ | Tags | | | amd, ati, x | ] |
| [ | mood |
| | accomplished | ] |
| [ | music |
| | The Doors - Love her madly | ] |
Yes, you are reading this correctly, you should be able to do away with shadowFB on radeonhd on R5xx already.
I expect some issues of course, as this adds more than 2.5klocs, all in all, and i at least know that i haven't been able to test it on PPC.
Plus, it is not as fast as it can be yet, we do not use the command processor yet, nor do we have working DMA, but all of this will happen.
I also now got to adding Joachim Deguarra's patch to add HD3870 X2 support. From a driver pov, with us not doing anything 3d and not support crossfire, this really looks like an rv670. So HD3870 X2 is no lie, it's just that on linux at the moment, the powerusage of HD3870 X1 makes it a better buy than the X2 :)
So now i'm going to deal with the fallout of these commits and in between try to help egbert out with adding rv620/rv635 support :) |
|
|
| Pleased to meet you, hope you guess my name. |
[Jan. 28th, 2008|10:42 pm] |
| [ | Tags | | | ati, x | ] |
| [ | music |
| | The Rolling Stones - Picture Disc 08 - Sympathy for the devil (1979) | ] |
A lot of effort is being made to re-market AtomBIOS.
For instance, AtomBIOS function tables are being actively and consistently referred to as "scripts".
Wikipedia tells us that: "... [scripting languages] are distinct from the core code of the application, which is usually written in a different language, and by being accessible to the end user they enable the behavior of the application to be adapted to the user's needs."
At no point do AtomBIOS functions come close to fitting the definition of script, at least not as we get them. It might start life as "scripts", but what we get is the bytecode, stuck into the ROM of our graphics cards or our mainboard.
The tools to generate this bytecode can now of course be written, but such tools are currently not available, nor is anybody planning on writing them. There are also no tools to replace functions in our existing vga BIOS images, or tools to generate brand new images. But none of this matters as ATI doesn't want us to flash our graphics cards ROMs in the first place.
Then there is the warped use of "legacy", another sign of advanced marketing. In the radeon driver, all the code that directly programs the modesetting of r1xx-r3xx (and rs4xx) radeons has now been moved to files starting with "legacy".
Once again, wikipedia provides some clarity: "A legacy system is an old computer system or application program that continues to be used because the user (typically an organisation) does not want to replace or redesign it."
So C code, that sets up hardware directly, and that can be evolved as driver frameworks and modesetting models evolve, is being labelled "legacy". Yet it is exactly this C code that recently got completely restructured to support RandR1.2.
And then AtomBIOS... Bytecode that cannot be replaced, with a seemingly fixed (but surreptitiously moving) API, which enforces a given way of working to the driver developer... That stuff is not legacy... Right?
So MIT licensed C code is "legacy", and untouchable bytecode is "scripts".
I'm sure that if this is repeated enough, people might actually start believing it. |
|
|
| X@FOSDEM2008: We have a devroom! |
[Nov. 28th, 2007|07:12 pm] |
| [ | Tags | | | xorg | ] |
| [ | Current Location |
| | office | ] |
| [ | music |
| | Elmer Bernstein - Theme from "The Great Escape" | ] |
Yup, we have one, and a bigger one too, so we can honestly state that we are bigger than ever!
The wiki page for this is set up here.
We will hopefully have a hothouse beforehand, but of course, this is just an intention so far.
What i would like to know ASAP is the following:
* First: anyone interested in speaking at the devroom? I think i can poke people for at least more than half of the 11 slots already, but if you do want to have a talk at the Xorg Devroom at FOSDEM2008, get in touch ASAP. The deadline for speakers for Xorg is 31st january 2008.
* Secondly, i would like to hear from X developers whether they are interested in coming to the hothouse on friday, and whether they would also come on thursday. If you do not know what a hothouse is please, visit the above wikipage again.
So... 23 and 24 of February 2008, in brussels, at the ULB Solbosch campus. Xorg DevRoom. Be there. |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| [ |
go |
| |
earlier |
] |
| |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
libv's journal