My Google Summer of Code proposal
I've been involved with X.Org for a few months now. I want to increase my involvement, and at the same time learn the ropes. I also need something to do this summer–and that's why I've applied to the Google Summer of Code.
Also available at the SoC website.
KMS for Permedia3/4 as a method for Documenting the KMS driver writing process
Abstract
The current trend in X11 graphics is to move mode-setting code into the kernel, allowing for faster and more graphical boots with fewer flickers. Only the big three drivers, Radeon, Intel, and Nouveau, support KMS, but there are many more X11 drivers that could benefit as well. Unfortunately, the big three drivers are large (smallest is 26,000 lines, largest is 65,000 lines) and complex, and is there no official documentation for writing KMS drivers. This project aims to provide the community with both documentation for writing KMS drivers and a basic, unaccelerated, reference KMS driver for Permedia3-series hardware.
Benefits to the Community
With a small reference KMS implementation and clear and detailed documentation, written from the perspective of a student not fluent in the world and process of writing graphics drivers, others should be able to write KMS drivers for other hardware much more easily and therefore improve the experience of users with such hardware.
Project Tasks
- Implement a shell driver that claims the hardware. Get my hands dirty with kernel code. Once this is completed,
- Implement basic mode-setting for the Permedia3. Although the Permedia4 (and Permedia2) are very similar, the mode-setting code on each chip could have its own bugs and headaches, so I am limiting the scope to only Permedia3.
- Implement basic memory management using TTM. Study the TTM API, documenting relevant parts. Once the memory manager is completed, polish the code into something others can read and follow. This stage will be complete when X11 can run on the KMS driver using fbdev.
- Write Documentation and Programming Guides for KMS, TTM, and other DRM interfaces.
Optional Tasks
- Implement some form of Command Submission.
- Implement system for submitting commands to the kernel
- Implement system for knowing when the commands have been completed
- Improve the memory manager to handle command buffers
- Using command submission, accelerate some tasks of the KMS driver such as copy area and rectangle fills.
- Make the existing xf86-video-glint DDX capable of operating with the KMS driver.
- Make the existing xf86-video-glint DDX capable of making use of the memory manager.
Deliverables
- Shell driver that claims the hardware (1 week)
- Implement basic mode-setting (3 weeks)
- Implement basic memory management using TTM (3 weeks)
- Bug Fixes and polish - basic, unaccelerated KMS driver capable of providing fbdev with linear VRAM access. (2 weeks)
- Document the process, finish Documentation and Guides for writing KMS drivers (2~3 weeks)
Optional Tasks
- Command Submission (3 weeks, if time allows)
- Accelerated KMS driver (1 week, if time allows)
Eventual Tasks, outside the scope of GSoC
- Make xf86-video-glint run with KMS driver
- Make xf86-video-glint capable of making use of memory manager
Related Work
Jesse Barnes proposed a work-in-progress patch to includes documentation that "provid[es] basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure."
Existing Permedia2/3 framebuffer drivers exist in the Linux Kernel, drivers/video/pm{2,3}fb.c.
Biographical Information
I am a senior at Lenoir-Rhyne University, with a major in Physics and minors in Mathematics and Computer Science. I work for the school's marketing department doing PHP/Drupal web development.
I'm a contributor to X.Org, the Linux Kernel, and Alpha/Linux (where I'm the de facto glibc maintainer).
For this summer, I plan to have a part-time internship, mostly unrelated to programming.
Skills and Qualifications
I'm experienced programming in C and x86/Alpha assembly. I'm also quite persistent and do not give up easily.
I've made close to 30 commits to the X server, for changes to between 1500 and 2000 lines of code. I've also made minor changes to the xf86-video-ati and xf86-video-intel drivers.
On the Kernel side, I run the alpha-2.6 git tree for collecting and funneling DEC Alpha patches that I and others write to Linus. I've made minor commits to the DRM kernel code.
I also maintain the AlphaLinux.Org Wiki, a community site documenting Alpha hardware, software, and the latest developments in open source affecting Alpha/Linux users.
– Tags: glint gsoc kms linux xorg
My Daily WTF moment
I read The Daily WTF from time to time in amazement. I've never had a WTF moment even relatively worthy of their site, until today...
<?php if (isset($secondary_links)) : ?>
<?php print theme('links', $secondary_links, array('class' => 'links secondary-links')) ?>
<?php
endif;
?>
This is exactly how the code appears, spacing included. Fixing up the spacing only makes you wonder why-tf anyone would write PHP in this style.
<?php if (isset($secondary_links)): ?>
<?php print theme('links', $secondary_links, array('class' => 'links secondary-links')) ?>
<?php endif; ?>
So what's wrong with this code?
- Spacing–the author had to try to make it this atrocious
- Opening and closing <?php for consecutive lines–what gives, really?
- Wonky if(): endif; syntax–are we in 1998 again
By the way, writing unreadable code does not help your job security if you have to ship it to customers.
Socket 754 Turion ML-34 works in an ABIT NV8
My current desktop has served me quite well for nearly four years. Its Sempron 2800+ certainly doesn't compete with Phenoms or Core 2's in terms of performance, but what really bothered me about it was its lack of power management support. By some arbitrary decision, AMD chose to disable Cool'n'Quiet on Semprons <3000+. I've been vaguely interested in upgrading the processor for a while, but options are rather limited. It's not worth it to upgrade to a faster Sempron. Socket 754 Athlon 64s use quite a bit more power and mobile Athlon 64s still cost well over one hundred dollars. Socket 754 Turions exist, but I couldn't find any mention of compatibility with my ABIT NV8. I figured for eight dollars it was well worth the gamble, and bought a mobile Turion ML-34 on eBay to give it a try and to give my desktop a final upgrade.
So the specifications of the two processors are
| Sempron 2800+ | Turion ML-34 | |
| Frequency | 1.6 GHz | 1.8 GHz |
| L2 cache | 256 KiB | 1024 KiB |
| Power consumption | 62 W | 35 W |
| Power management | No | Yes |
Being mobile processors, Socket 754 Turions don't have a heatspreader separating the die from the heatsink. To allow my Scythe Ninja heatsink to make contact directly with the core, I removed the black heatsink mounting equipment from the motherboard and shaved down about 2 millimeters from the bottom. After some adjustment it fit, and the heatsink made good contact. Once this was set, I fired it up. The BIOS even recognizes the Turion by name.
No benchmarks unfortunately, nor have I had a chance to test power consumption with my Kill-a-Watt. I can say that the CPU runs about 5 ℃ cooler. Linux also is able to change the CPU frequency on the fly between 1.8 GHz, 1.6 GHz and 800 MHz.
So I can confirm to any Socket 754 users left out there that Turions do work in the ABIT NV8. It's probably the most satisfying upgrade Socket 754 users as well.
– Tags: hardware
IRIX for x86 and the 700MHz O2
As I was testing Radeon Kernel Mode-setting on Alpha, I casually started a conversation with Jesse Barnes, an Intel Graphics developer. I recalled that he was an ex-SGI employee, and being interested in SGI computers myself decided to ask him a question or two. What I learned about SGI absolutely floored me.
When Chicago Joe hacked a 600 MHz PMC-Sierra CPU into an SGI O2, the quest for newer, faster chips for the aging O2 began. 600 MHz is a nice upgrade, but why stop there? A 900 MHz CPU should be possible as well, but it would require changes to the O2's PROM at the source level. Due to one thing or another, SGI has been unwilling to release the PROM source code. I decided to ask Jesse if he knew the right people to contact at SGI to lobby for the release of the code.
The conversation went –
<mattst88> jbarnes, you used to work at SGI, no? <jbarnes> yep <mattst88> the holy grail of O2 hardware hacking is replacing the desoldering the CPU and replacing it with a a 600 MHz chip. <mattst88> theoretically, 900 is also doable, but it would require the release of the O2's PROM code <jbarnes> I played with some that had pmc 700MHz chips <mattst88> rumor has it that Microsoft owns most of the code, from the MIPS consortium days <jbarnes> I think we ended up not shipping due to some weird fp bug <mattst88> any idea if SGI is even _able_ to legally release this code? * jbarnes even did an irix kernel patch for that chip <mattst88> btw, SGI just got bought out. <jbarnes> yeah I'm still in touch with people there <jbarnes> yeah they could release a lot of it <mattst88> jbarnes, _SGI_ was going to ship 700 MHz chips for the O2? <jbarnes> it's just a pain due to external contractors doing some etc <jbarnes> yeah <jbarnes> we even did an x86 port in 2000 <mattst88> never heard that before, that's cool stuff <mattst88> x86 port of IRIX? <jbarnes> yep <mattst88> holy crap <jbarnes> well time to go home... <mattst88> do you think it's possible to pull the right strings to get as much code as possible to be released? <mattst88> the PROM, that is? <mattst88> btw, do you mind if I reproduce this conversation? <jbarnes> sure sgi got sold so I guess it's ok for it to be widely known <jbarnes> as for the prom... dunno who you'd talk to about that these days <jbarnes> rich altmier is at intel now, otherwise he'd definitely be the guy <mattst88> if you get any ideas, please let me know. there are definitely a lot of people who would love to hack at it <mattst88> so, any more secret tidbits to share before you head for home? <jbarnes> hehe <jbarnes> I'm sure someone will write a book <mattst88> why was the IRIX port to x86 not released? <jbarnes> just show up to la fiesta in mtn view on any given wed evening and keep your ears open <jbarnes> various reasons <mattst88> saving them for the book? :) <jbarnes> heh <jbarnes> ok bbl <mattst88> do you mind if I reproduce this conversation? <jbarnes> sure np <mattst88> thanks
*blink*
- IRIX for x86
- 700 MHz PMC-Sierra chip for the O2, by SGI
No commentary needed...
Ideas for the Future of SkyOS
In December 2004, I paid thirty dollars for a SkyOS Beta membership. I was intrigued by the project. I couldn't explain it. It was just different. I ported simple software and came to be a part of the SkyOS community. I wrote SkyOS programming guides. I spent hours talking with other SkyOS users on IRC. I reported bugs and followed development closely. There was no other project that I devoted more time to than SkyOS. But for the last year or so, SkyOS has progressed at an ever slowing pace. With long periods of downtime between SkyOS releases, many users, myself included, gradually moved on to other projects. Finally, Robert made the announcement that SkyOS development is officially halted. I wasn't surprised, but I was saddened. Given what I know of the project and of Robert, and having seen in four years of development the same concerns raised, problems faced and subsequently fixed over and over again, I wrote a letter to Robert outlining what needs to be done to save his hobby of the last thirteen years.
Hi Robert,
This is Matt (mattst88) from SkyOS.
I read your response on OSNews. I want to comment on your possible resorts:
- Open source SkyOS
- Make SkyOS available for free
- Specialize on a yet to define niche
Do all of them, by
Releasing SkyOS as open source/free software under the MIT or BSD license. By licensing under a very permissive license, it will allow projects from whom SkyOS has used code (e.g. Haiku) to use SkyOS's code where possible.
Implementing a Linux-style development model. Source code would be available in a public git repository, of which you would be the only one with commit access. You, and you alone, would:
- control what goes into the repository
- define targets and make releases
- point people in the right direction
This way, others do the heavy lifting and you help where needed.
Once this has been done, I see a number of things that can be done to improve SkyOS.
Move SkyOS-specific code in ported software upstream. As an open source project, it should be much easier to have official support from other open source projects.
Reduce development time and duplication of effort by replacing SkyOS components with open source counterparts. As I have not viewed the SkyOS source, I cannot comment further on which components could be replaced.
Port the Direct Rendering Manager to the SkyOS kernel. With DRM in place port Gallium3D [1], which should _greatly_ simplify graphics drivers. Using Gallium3D, SkyOS would be able to leverage support from a much wider base of developers.
Finally, define a niche for SkyOS to fill. Laptops are more likely to have nonstandard hardware, thereby requiring all kinds of extra support, from strange integrated graphics chips, to countless wireless chipsets, to docking stations. (I do not mention power management, as it is becoming increasingly necessary even for desktop systems.) I therefore propose supporting only standard desktop systems.
I hope you find time for SkyOS in the future and implement my suggestions. With this plan, SkyOS should live on with community support, and you should be able to devote time to your daughter (I guess she has just turned one?) and family.
Thanks Robert, for everything. I'll turn 21 this month, graduate with a degree in Physics next year, and go to graduate school in either Computer Science or Computer Engineering the year after. I can definitely say that SkyOS has contributed heavily to developing my passion -- computers. I've learned so much from this project. I know there's still much to learn from you and from SkyOS, so I hope you continue the project.
Thanks again,
Matt Turner
[1] http://www.tungstengraphics.com/technologies/gallium3d.html
http://www.tungstengraphics.com/wiki/index.php/Gallium3D
https://en.wikipedia.org/wiki/Gallium3D
I sent this email almost two weeks ago. I have received no response.
As an addendum to my email: SkyOS should further limit its hardware support by supporting only x86-64 systems in 64-bit long mode.
Another long time SkyOS user told me via IRC that he believes Robert has entirely lost interest in SkyOS. Evidently, he didn't even notice that SkyOS.org was down for two to three days after OSNews ran its article.
I sincerely hope he is wrong, but I can only doubt his claim so much. If SkyOS is not dead – great, let's see how we can give it new life and contribute to projects on which we've drawn support an inspiration. If it is dead, it was a fun hobby for Robert, me, and others involved. I certainly learned a lot and cut my teeth on SkyOS.
– Tags: skyos