A quick note that I accidentally dd'ed Haiku over my main Linux workstation while doing some testing. (doh!)
Haiku Mesa development is going to be slightly delayed while I re-setup my main rig.
As a side note, ArchLinux is pretty cool and i'll be doing my future Haiku development on it. :D
This post's comments feed
no trackback
I've made a lot of progress over the last few weeks, here is the latest statuses layed over the bullet points posted here.
Update Mesa3D / aka Gallium3D to current and work on getting changes accepted in Mesa upstream
This is 99% done. The latest Mesa upstream now compiles under Haiku gcc4 with a patched makefile. I am working on getting a scons build script working. scons is the build system Mesa seems to be moving to, and they voiced in the ML that would perfer to not accept new Makefiles. There is a scons port on haikuports, so this shouldn't be a big deal.
Get stock Mesa3D into the build system somehow so it is pulled / extracted prior to compiling opengl kit
I am glad to confirm this is 100% done. (yay!) Right now the Haiku build system pulls external pacakges for Mesa, and compiles using them.
Relevant commits include hrev43650 (the "big" one), hrev43651, hrev43652, hrev43655, hrev43656, hrev43657
Haiku pretty much keeps it's own for of GLUT at the moment, as glut is no longer actively developed. Glut was (and is) pretty big in the BeOS / Haiku world, so keeping our own fork of it makes sense (it's also a small project code wise) Glut was moved from src/lib/mesa/glut to src/lib/glut while I was removing the mesa files from src/lib/mesa
Ensure new Mesa3D based opengl kit works and software rendering occurs (this gets us back to square one with the new Mesa version compiled from upstream.)
This is mostly complete. I am not going to accept the first portion of the bounty however until things are 100% what they were... there are a few qwerks in GL rendering I want to address before calling this one done...
I have seen teapot spinning at 300-400fps on decent hardware and ~ 16fps in the lowest qemu.. I'm pretty sure thats faster then it was, I don't have data to confirm however. Things are stable, and GLteapot has run for multiple days at a time without leaking any noticable memory.
Get at least one Gallium3D Hardware driver working / rendering.
Not started yet, the door is now open as we have stock Mesa running. Right now we are using what Mesa calls their "Software rasterization" engine. I am planning on checking out what others have done in the past for Gallium3D software pipe rendering... it would be a good spot to start.
Get two Gallium3D Hardware drivers working / rendering.
Lets get one working first :)
Thats all for now, thanks for the support everyone one who has helped thus far... and a big thank you to the Mesa project folks for putting up with me and my Haiku patches :D
-- Alexander von Gluck
This post's comments feed
no trackback
As some of you may know, to take advantage of all this new found Radeon HD love, I've begun some work on the Gallium3D bounty over at Haikuware... Below is my first status update...
It has taken a while, but parts of my first Haiku support patch was accepted into Mesa.
Update 12/27 11am A few more have been accepted now, making progress! here, here, here, here.
Still trying to get the hang of the Mesa patch submission process... it's all done via git send-email.
Brian (one of the main Gallium contributors) has been giving positive feedback / criticism.
I've been kind of on hold trying to get these base level patches into Mesa, once they all funnel into mesa things will move a lot smoother as I'll have a solid work base.
One worrying point right now is getting gcc2 working, as gcc2 is no longer a tested compiler for Mesa it is going to be rough. I'm not expecting Mesa to accept gcc2 support patches, so once all of my base "get it building" patches above are accepted and I can verify this build process I have in mind works for gcc4. I'll see if I can throw together a set of gcc2 build fixes that could be applied to the *bare* Mesa sources of a tagged revision of Mesa (7.12 for example)
This post's comments feed
no trackback
Just wanted to throw a quick first out there... as of hrev43498 we have performed our first DisplayPort query!
This post's comments feed
no trackback
Development on radeon_hd has slowed a bit, this is mostly due to the major code being done and me falling back to adding the stupid-complex stuff. Most current Radeon HD cards (Radeon HD 2xxx through Radeon HD 5xxx) are working with mode setting. Radeon HD 6xxx *should* work... but is not well tested due to me not having a desktop Radeon HD 6xxx card.
Radeon HD 6xxx chipsets are starting to use DisplayPort quite a bit. I purchased a new laptop recently with an on-board Radeon HD 6480G. While the GPU is awesome, the laptop's LCD is connected via LVDS through a special unicorn Active DisplayPort bridge. Even the VGA port on the back of the laptop is an active DisplayPort bridge. DP is neat.. but is going to require lots of new code to get working. I am trying to get the minimum DP code done to do mode setting.
I added a new table to graphically represent Radeon HD cards supported... you can find it here.
One last item.. if you want to help Radeon HD development, please click the advertisement on the right side of the site... every penny helps me get more Radeon hardware.
This post's comments feed
no trackback
I am happy to report that mode setting under Haiku is working off-and-on under r600 series Radeon HD cards.
r700+ (Radeon HD 4xxx+) is still failing with black / white / blue / red screens. I think I've narrowed the issue down to the frame buffer (and the fact that I have no experience programming a frame buffer). I have been getting a run down by the AMD folks and think a solution may be close.
The radeon_hd driver is in the latest nightly images.. feel free to test away on your Radeon HD 2xxx - Radeon HD 4xxx cards.
This post's comments feed
no trackback
I2c is finally working after much bit-banging. The I2c signal looks pretty dirty, but that's to be expected as it's all bit-banged.
I've removed a lot of legacy code, and am working on the mode switching. I haven't gotten a successful switch yet but have had enough luck freaking a few monitors out... which is a good sign :)
This post's comments feed
no trackback
Working on i2c has been a pretty big pain. I've fallen all of the way to hooking up a logic probe to a connected display to sniff the i2c traffic.
I reworked how we handle all the supporting information for i2c communications making things a little more robust. We now map all possible GPIO pins, then assign them as things request them.
You can see the new mapping (and the current state of edid reading) in the latest logs here.
This post's comments feed
no trackback
I've been banging on the i2c ddc connector interface for a few days now without much luck.
Getting per-connector EDID working has been a major stopping point given it's complexities. At this point I am *very* close... however I have yet to get a valid EDID back from the card. EDID is important as it is how you are supposed to detect attached monitors, and gives a lot of mode line information so you know what frequencies to send to the display.
I'm almost to the point of sniffing the i2c lines on the video cable to get a clearer picture of whats going on. I'll grab a few pictures as it will be the first hardware hacking part of this driver. If I go this route, i'll be using my awesome Saleae Logic analyzer attached to an Ubuntu machine.
This post's comments feed
no trackback
I've been hard at work attempting to get i2c working on each connector using the accelerant common code. Having a working i2c means we can read edid from each detected connector and get the limitations of each monitor. Reading the edid is also how AtomBIOS expects you to detect attached monitors.
i2c has been tricky to get working as if we have one i2c timing off, we break the communications channel... thus far all I can get is an empty EDID block.
I added a new debug function to list out the connectors we have detected through AtomBIOS... it gives a nice picture of your card:
radeon_hd: Currently detected connectors============= radeon_hd: Connector #0 radeon_hd: + connector: DVI-I (Digital and Analog) radeon_hd: + encoder: TMDS radeon_hd: + gpio valid: true radeon_hd: + gpio pin: 0x91 radeon_hd: Connector #1 radeon_hd: + connector: DVI-I (Digital and Analog) radeon_hd: + encoder: TV DAC radeon_hd: + gpio valid: true radeon_hd: + gpio pin: 0x91 radeon_hd: Connector #2 radeon_hd: + connector: 9-Pin DIN radeon_hd: + encoder: TV DAC radeon_hd: + gpio valid: false radeon_hd: + gpio pin: 0x0 radeon_hd: Connector #3 radeon_hd: + connector: DVI-I (Digital and Analog) radeon_hd: + encoder: TV DAC radeon_hd: + gpio valid: true radeon_hd: + gpio pin: 0x90 radeon_hd: Connector #4 radeon_hd: + connector: DVI-I (Digital and Analog) radeon_hd: + encoder: TMDS radeon_hd: + gpio valid: true radeon_hd: + gpio pin: 0x90 radeon_hd: ==========================================
The missing gpio pin for 9-Pin DIN makes sense because component/s-video wouldn't have edid data.
Onward!
This post's comments feed
no trackback
AtomBIOS uses a callback function to access registers directly on the card.
It turns out the the new AtomBIOS parser was expecting the driver to take the register address given and multiply it by four. As I was doing it the older way and not multiplying memory addresses by four... AtomBIOS was writing to incorrect card locations and making a mess of itself.
As of r42647, AtomBIOS calls no longer enter a loop state... and the card does stuff when calls are made (yay!).
This leaves me with the following short-term goals:
I am pretty much redoing a lot of work done before, but now I can rely on the AtomBIOS to do all the register hitting and we no longer have to worry about large undocumented structural changes between card revisions.
I am moving next week, so updates may be erratic for now.
This post's comments feed
no trackback
I'm going through some real-life (c) stuff that is putting a delay on my Haiku work.
I should be able to pick things back up starting next week.
This post's comments feed
no trackback
The AtomBIOS parser is still looping infinitely when asic_init is called.
I was assuming I was missing setting something up before calling the asic_init call, however i've been over the initialization code several times in the drm driver and don't see anything that may be a cause.
I back ported several changes / fixes from the linux drm AtomBIOS parser that weren't present in the original kgrids one, however this also didn't resolve the issue (I did add a quick check though that allows the AtomBIOS parser to detect looping code and halt the current AtomBIOS execution)
Steps going forward:
This post's comments feed
no trackback
Just a quick status update on the AtomBIOS situation.
Progress is on-going.
On a more positive note I reworked the model storage scheme for Radeon HD cards, added the first HD 6xxx cards, and added an IGP field. The radeon_hd driver will also drop out and go to VESA if it can't find an AtomBIOS... so feel free to test that functionality. Just don't be surprised if the Radeon HD driver loads and you see a black screen :P
This post's comments feed
no trackback
As of r42566, we successfully read the cards AtomBIOS in the driver and pass it all the way to the accelerant which gives it to the AtomBIOS parser. (great success)
You can catch the logs here
... or pay attention to the one line that matters:
radeon_hd: ATOM BIOS: VT-2400P256PCI
Thats the init call for the AMD kgrids AtomBIOS parser.
Now, time for some cake.
This post's comments feed
no trackback
AtomBIOS is AMDs way to make it easy to support multiple Radeon HD cards with one driver.
I've decided to put some work into using AtomBIOS as hitting registers has given very inconsistent results. (this also rides on the recommendations of engineers at AMD)
Right now I am working on getting the Radeon HD PCI BIOS ROM loaded into AtomBIOS. Once the ROM is loaded into the AtomBIOS parser, in theory we should have access to functions built into the BIOS. These functions can be viewed via the Atom Disassembler...
This post's comments feed
no trackback
I just wanted to throw a quick high-five out to AMD. They are *awesomely* supportive of giving a hand to Open Source projects writing drivers for their hardware. I was completely struck dumbfounded when I emailed an Open Source developer email on their website and got multiple responses on a weekend from Radeon engineers at AMD.
High-fives all around!
This post's comments feed
no trackback
The Good
The Haiku beceem WiMax device driver has progressed nicely and can control and communicate to the Beceem family of USB WiMax devices. We successfully can push the binary firmware to the device and enable the multi-colored status led.
The Bad
While the device communication functions are complete, no network stack has yet been attached to the device, let alone implement libeap needed for authentication.
This post's comments feed
no trackback
I recently obtained a G5 iMac on the cheap (i mean *CHEAP*). Turns out the Haiku boot loader wouldn't even start on it.
r42826 fixed some major problems in the boot loader where OpenFirmware stored memory base addresses for 64-bit capable PowerPC CPU's as 64-bit integers vs 32-bit... however we were using a struct with a fixed 32-bit address.
Getting technical for a moment, here was the situation.
32-bit OpenFirmware systems store their memory ranges as follows:
Base Size 00000000 20000000 20000000 20000000
This represents two memory sticks. Base is the memory location each stick starts at, and size is the size of each memory stick (0x20000000 == 512MB)
We read the information by laying each line over a struct:
struct of_region {
void *base;
uint32 size;
};
On 64-bit PowerPC systems though OpenFirmware stores the memory base as a 64-bit integer:
Base Size 00000000 00000000 20000000 20000000 00000000 20000000
As Haku is 32-bit code on PowerPC, a void pointer is a 32-bit number... which means we read the memory as 0MB throwing off all of our memory management calculations.
Selectively choosing uint32 or uint64 based on the #address-cells parameter is what the solution was in r42826
This post's comments feed
no trackback
Current Status
I took a small break from radeon_hd work last week due to me burning out a bit on it.
The good news is that I have started radeon_hd work again with a running start via r42462
r42462 adds the internal design needed to support multiple monitors and makes the whole monitor connection management situation easier.
AtomBIOS-less status
I have been steady in my decision to skip using AtomBIOS for the moment. While AtomBIOS is supposed to make supporting future Radeon cards easier, it also is very Xorg centric and does lots of things I personally don't like.
I foresee the following driver limitations by not using AtomBIOS:
Long term we are going to have to start using AtomBIOS to fully utilize Radeon HD cards, for the moment though we can skip it.
Thats about it for now. The radeon_hd driver as of r42466 is getting pretty stable and will probably work to some-degree for a few people. Extended video mode setting is still not great though and most modes won't be right.
Example syslog output of driver with one monitor attached.
-- Alex
This post's comments feed
no trackback
Powered by Dotclear - Theme Freshy by Julien de Luca
