kallisti5's blag

I've installed several ArchLinux systems now, and I've worked out the following steps to obtain a nice desktop with minimal work:

1. Install ArchLinux selecting only the base system.
2. Install packages:
   1. pacman -S xorg xorg-utils xfce4 git fakeroot base-devel bison git texinfo yasm openssh unzip libgnome-sharp intltool gio-sharp gconf-sharp libgnome-desktop-sharp gnome-keyring-sharp mono-addins notify-sharp rsvg2-sharp wnck-sharp dbus-sharp-glib synergy nfs-utils xscreensaver flashplugin openssl slim sudo vim
3. edit /etc/rc.conf and add the following daemons:
   1. dbus rpcbind slim
4. Add a non-root user
5. Edit /etc/groups and add your non-root user to needed groups (including wheel)
6. Edit ~/.xinitrc, uncomment the xfce line
7. Reboot
8. Log into your new desktop
9. Install http://tiheum.deviantart.com/art/Faenza-Icons-173323228
   1. Configure xfce to use Faenza (through preferences) once it's installed.
10. mkdir /aur
11. wget "http://aur.archlinux.org/packages/do/docky/docky.tar.gz"
12. tar xvzf docky.tar.gz
13. makepkg -i
14. Remove the xfce panel on the bottom
15. Applications -> Run -> Docky

Good afternoon folks, sorry for the delay in an update. Things have paused for the moment on the Mesa updates mostly due to all of the Alpha 4 talk on the Haiku Mailing list... the latest changes in Mesa (mentioned in the last blog post) will require a pretty large rewrite to the Mesa swrast driver... something I don't want to undertake shortly before an Alpha 4 potentially in early in March.

The Mesa swrast driver is stable at the moment, and double buffering is nearly working (no more crashes, yay!). Double buffering will remain disabled for the moment mostly due to Haiku limitations. (Haiku vesa has a software cursor. if you double buffer a GL image the cursor will disappear completely vs flicker when you single buffer)

Once the Alpha 4 hits, I can resume work and will take the following steps:

• Update Mesa to the latest and greatest.
• Split Mesa software rast driver in two (legacy gcc2, and gcc4)
• Get new Mesa code working (shouldn't be that hard)
• Use new (non-legacy) Mesa software rast code as a skeleton for the first Gallium driver (softpipe)

A few things I worked on this last week include radeon_hd improvements and ensuring the OpenGL binaries run on pentium (Haiku's target cpu)

One step forward, six steps back.

This week I started looking in-depth into a series of Mesa changes to swrast that I knew would effect us... oh boy these changes turned out to be a doozy.

GL Teapot depth fixes

The step forward is last week I fixed the GL Teapot depth issues so that the handle and spout aligned properly

Split Mesa swrast driver

I will need to break the Mesa swrast opengl addon into two as we have to support both the older Mesa (7.8.2) for the gcc2 images, and newer Mesa to get Gallium. As we call private Mesa functions that are not normally public, large changes such as these can happen.

What this means

This means the following will change:

Old layout:

• MesaSoftwareRenderer.cpp
• MesaSoftwareRenderer.h

New Layout:

• MesaSoftwareRenderer.cpp
• MesaSoftwareRenderer.h
• MesaSoftwareRendererLegacy.cpp
• MesaSoftwareRendererLegacy.h

The *Legacy sources will be pretty much only used on gcc2 images with Mesa 7.8.2. The MesaSoftwareRender.cpp will be whats used on gcc4 + Mainline mesa. The Jamfile will choose a source and use it based on the GCC version. This isn't ideal because it means swrast fixes will need to be targeted to each driver, however keep in mind as Mesa 7.8.2 is the *latest* version of Mesa we can run on gcc2... MesaSoftwareRendererLegacy.cpp won't need to be updated very often.

This new layout also offers the following paths:

• Post R1/gcc2 we can simply remove MesaSoftwareRendererLegacy.cpp
• If Gallium software pipe rendering begins working (and is faster) we can simply disable the swrast driver so it is only used on GCC2 images.

Another reason I went this route is the #ifdef's for Mesa version were beginning to number in the 100s working out of a single file. The new Mesa swrast engine just works *way* to differently.

You can compare the new add-on work here (600 lines). to the old one here (1000 lines)

I'm testing the new software rast engine and code, but have been stopped dead cold by a Mesa bug

It looks like it may be a while until I collect the first bounty payment :)

Things have slowed a bit on the Mesa / Gallium front. I am finding myself falling a little behind due to the following:

Illness

I was pretty sick off-and-on this last week pretty much removing all the programming fight from me.

dd'ed haiku over my Linux system accidentally causing the need for a re-install.

Normally dd'ing Haiku over Linux is a good thing.. not so much this time.

Mesa rtasm / Heap corruption

Arrgh, so there is a set of old rtasm sources in Mesa (http://goo.gl/dDJ8J), and a set of newer rtasm sources in Gallium (http://goo.gl/zzSsy). Each set of sources has a conflicting (but different) set of structs / functions / etc as the gallium one was originally based on the Mesa one. This doesn't effect Linux, however when you link together Mesa and Gallium you begin getting heap corruption and libGL.so linked binaries start acting all stupid following "if (0)" as true.

The patches to make Mesa code use the newer Gallium rtasm are pretty simple (maybe 30 lines changed), and simply pointing the Mesa code to the Gallium sources works for us (it's what the current Mesa optional packages does. This however violates one of Mesa's rules.. Gallium cannot rely on Mesa to compile and vise-versa. The *correct* solution is to move Gallium's rtasm into the common src/ directory and have Mesa and Gallium both compile and use it. Sounds simple enough, except when you factor in that this change requires changes to core parts of Mesa and Gallium, while keeping the two working across all 9000 build options via both Makefiles as well as Mesa/Gallium's (python) scons build system. Scons has been easy and is almost done, the older Makefiles however are causing me grief.

Tea pot oddness

I have hacked and hacked, I just cannot get the teapot to render perfectly. The depth is all weird and the blinking red when you mouse over it is driving me nuts.

Double buffer crashing

Enabling the double buffering GL causes all GL apps to crash. The double buffering code is easy enough, setting up two render buffers vs one, however things go wacky when it is enabled. This may be related to the issue above, I feel as though it is another dreaded heap corruption issue overflowing buffers.

On a positive note, SSE optimized code is now mostly working.. We were getting general protection faults when running *real* SSE2 / MMX optimized code. hrev43673 should *hopefully* be the fix to that... although I think there may be a few multi-cpu configurations were the FPU still isn't setup properly for SSE2.

I've yet to request any Haikuware bounty percentages as I am still not comfortable with the quality of the GL rendering going on...

All for now. -- Alex

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.

• Haiku gcc2
  • The Haiku GCC2 images pull a compiled Mesa 7.8.2 Optional Package. I went with 7.8.2 because this is the *very* last upstream version of Mesa I could get to compile without Haiku keeping a complete fork. After 7.8.2, glsl was introduced which is C++ and is *not* gcc2 friendly.
• Haiku gcc4
  • The Haiku GCC4 images pull a compiled Mesa 8.0 Optional Package. Upstream Mesa has accepted several Haiku patches and I am happy to report it looks like Mesa 8.0 should build under Haiku with very little assistance.
• The new build system pulls in the Optional Mesa package from a remote server and uses the combined binaries and headers to generate libGL (via the Haiku OpenGL kit)

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...

• GLTeapot 's handle and spout have some odd depth issues... unsure if this is due to GLTeapot being old code, or if it is due to the Mesa software rendering driver.
• Haiku3d has some instances of leaving a trail. (see http://twitpic.com/85vthm) I do have reports it is working 100% for other people however on 32bpp.. so I think it's a color space issue.
• Right now we only do single buffer rendering, double buffer causes crashing of GL apps.
• The Teapot flashes red when you mouse over it.. this may be related to the single buffering, I am not sure however.

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

Just wanted to throw a quick first out there... as of hrev43498 we have performed our first DisplayPort query!

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.

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.

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!