Linked by Hadrien Grasland on Tue 25th Jan 2011 15:29 UTC, submitted by sparklewind
BeOS & Derivatives A few months ago, a bounty for porting Gallium3D to Haiku was submitted. As the target sum of $2000 has been reached, what's needed now is a developer interested in doing the actual coding work. (Gallium3D is a cross-platform video driver API, on which an increasing number of open-source Linux drivers are based.)
Order by: Score:
thanks
by kvdman on Tue 25th Jan 2011 15:58 UTC
kvdman
Member since:
2006-04-28

Thanks for posting this, hopefully it'll get some exposure now. Check out the other bouties too!

I might add, a similar port was completed for AROS, for $1082... (I already contacted this developer, and he was unable to work on the bounty, but said he'd offer advice/help)

http://www.power2people.org/projects/profile/33

Edited 2011-01-25 16:00 UTC

Reply Score: 2

RE: thanks
by Earl C Pottinger on Tue 25th Jan 2011 16:11 UTC in reply to "thanks"
Earl C Pottinger Member since:
2008-07-12

People who are good on working on video drivers are few and far between. I am quite happy with the performance of VESA graphics on Haiku, but it would be nice if there is just one way to perform 3d graphics across all video systems with speed of graphics the only thing affect by your graphics hardware.

Hope someone works on this bounty soon, I know it will not be me. I am getting headaches just making my CRAMDISK working under Haiku and it is less than 300 lines of code.

The video gods are a class of programmers onto themselves.

Edited 2011-01-25 16:12 UTC

Reply Score: 2

....
by werfu on Tue 25th Jan 2011 17:11 UTC
werfu
Member since:
2005-09-15

I wonder if it requires to port DRI2/DRM. Also, could Gallium3D be ported over ReactOS or it wouldn't be compatible/usefull with the NT architecture?

Reply Score: 1

RE: ....
by Neolander on Tue 25th Jan 2011 17:14 UTC in reply to "...."
Neolander Member since:
2010-03-08

From the Gallium3D project's website ( http://www.freedesktop.org/wiki/Software/gallium ) :

"Gallium drivers have no OS-specific code (OS-specific code goes into the "winsys/screen" modules) so they're portable to Linux, Windows and other operating systems."

I have a hard time understanding how this can possibly work on something as performance-critical as a GPU driver, but keeping drivers cross-platform is one of their stated goal.

Edited 2011-01-25 17:16 UTC

Reply Score: 3

RE[2]: ....
by Mark Williamson on Wed 26th Jan 2011 19:23 UTC in reply to "RE: ...."
Mark Williamson Member since:
2005-07-06


I have a hard time understanding how this can possibly work on something as performance-critical as a GPU driver, but keeping drivers cross-platform is one of their stated goal.


I'm not an expert on this but I have spent some time looking into Gallium3D (though that was mostly a few years back!).

AIUI, it's source compatibility not binary compatibility, so that's part of it. The other part is that to a certain degree the OS-specific stuff does:
a) set up a direct comms channel between the application and the graphics hardware, e.g. using shared memory. 3D rendering under X, for example, doesn't mostly (in principle) interact with the X server.
b) talk to the windowing system about where the rendering is / should be

Neither of these things are on the performance critical path, which is the communications protocol with the graphics driver. So in principle they don't really matter to graphics performance.

That still leaves the question of how they do 3D API stuff, though... Currently, OpenGL on Linux is built on Mesa, with a load of function calls for very high level operations which call lower-level operations, which call lower-level operations, etc. The default implemenations are all software. The individual graphics card reimplements what operations can be accelerated, according to its capability (better cards might accelerate more or higher-level ops).

For Gallium the idea is that modern graphics cards offer a certain range of functionality that can be hidden behind a low-level (as opposed to high-level OpenGL operations) function call interface. The driver just implements these low-level operations and doesn't need to worry about the API in use.

That suggests (to me - I am no expert) that the optimisation opportunities are at least going to be rather different compared to folding the driver code into the 3D API implemenation. Maybe this is going to be beneficial, maybe it will be awkward...

Reply Score: 2

RE: ....
by deadwood on Tue 25th Jan 2011 20:14 UTC in reply to "...."
deadwood Member since:
2010-05-22

You don't need to port DRM, however Nouveau Gallium3D driver uses libdrm interface. You can implement your own libdrm-like module which will have all card init/control code and expose it through the libdrm interface. This however is a huge task and worth its own bounty. AROS port of Nouveau uses DRM with modifications kept to minimum so that we can relatively easy integrate upstream work.

Reply Score: 2

RE[2]: ....
by Michael Oliveira on Tue 25th Jan 2011 20:54 UTC in reply to "RE: ...."
Michael Oliveira Member since:
2005-07-07

In fact, we already have a basic libdrm implementation


please take a look at

http://dev.haiku-os.org/browser/haiku/branches/components/gallium3d

Reply Score: 3

RE[3]: ....
by umccullough on Tue 25th Jan 2011 22:02 UTC in reply to "RE[2]: ...."
umccullough Member since:
2006-01-26



I'm actually somewhat surprised that nowhere in this news bit, or the bounty (or the comments attached to the bounty) is there mention of the existing work done to port Gallium3d to Haiku.

Was that project so little known that others in the community aren't even aware that it was started, and significant progress was made on it already?

I think even the llvm softpipe was working already.

Edited 2011-01-25 22:03 UTC

Reply Score: 2

RE[4]: ....
by koki on Wed 26th Jan 2011 03:01 UTC in reply to "RE[3]: ...."
koki Member since:
2005-10-17

Was that project so little known that others in the community aren't even aware that it was started, and significant progress was made on it already?


Having a very small subset of source code in a big repo alone is insufficient to raise awareness; this is very easy to miss.

What may help make people more aware of such initiatives is if they had a home page with some of the basic info about the project (summary, goals, contact info, repo link, how to get involved, etc.), perhaps in the form of a microsite under the Haiku website.

Reply Score: 3

RE[5]: ....
by umccullough on Wed 26th Jan 2011 04:47 UTC in reply to "RE[4]: ...."
umccullough Member since:
2006-01-26

Having a very small subset of source code in a big repo alone is insufficient to raise awareness; this is very easy to miss.


Technically, the Gallium3D porting effort is an entire "development branch" of the Haiku codebase...but I see your point. Not much attention gets paid to those branches.

What may help make people more aware of such initiatives is if they had a home page with some of the basic info about the project (summary, goals, contact info, repo link, how to get involved, etc.), perhaps in the form of a microsite under the Haiku website.


At the time that it was started, I remember some excitement on the commit list and/or development mailing list. I don't seem to see any blog posts from Artur (the developer who was working on it), and it seems the project was "flying under the radar" so to speak.

I do recall some buzz about it on some news sites, however - but at this moment, you're right - there's no visibility. I just thought perhaps it would have been mentioned in relation to the bounty by now and was surprised that it hadn't been ;)

In any case, it looks like Karl added a blurb about it, so hopefully that will add some inspiration to any would-be takers, knowing that there is already some (significant?) progress made toward the port.

Reply Score: 2

RE[6]: ....
by Michael Oliveira on Wed 26th Jan 2011 12:27 UTC in reply to "RE[5]: ...."
Michael Oliveira Member since:
2005-07-07

Yes.. softpipe was working (slowly) until a few releases ago.. but now will be necessary update the gallium branch...

Reply Score: 1

Gallium3D
by drcouzelis on Tue 25th Jan 2011 18:24 UTC
drcouzelis
Member since:
2010-01-11

Thanks to this news post, I just read about Gallium3D and how it aims to separate video card drivers from the operating system. What a cool concept!

I have a video card that's supported by Haiku, but there sure are a lot of video cards that aren't. I used to think it would be a huge task getting a large amount of video cards to work in Haiku. I'm sure it still is a huge task, but if Haiku can share video card drivers with Linux through Gallium3D, I think it would be a huge help.

Reply Score: 2

RE: Gallium3D
by umccullough on Tue 25th Jan 2011 19:28 UTC in reply to "Gallium3D"
umccullough Member since:
2006-01-26

I have a video card that's supported by Haiku, but there sure are a lot of video cards that aren't. I used to think it would be a huge task getting a large amount of video cards to work in Haiku. I'm sure it still is a huge task, but if Haiku can share video card drivers with Linux through Gallium3D, I think it would be a huge help.


However, your card does not yet have 3d acceleration in Haiku (because no cards do)...

Gallium3d could be integrated into our Mesa port such that it offers 3d hardware acceleration, and eventually, with enough card support, it could potentially be used for hardware 3d desktop/window compositing so that people can finally get all their fancy eye-candy effects such as transparency and window skewing affects that people seem to go crazy for.

Reply Score: 6

adamk
Member since:
2005-07-08

3D acceleration is a noble goal, but can we at least get drivers that can properly handle HD resolutions and 2D acceleration?

Reply Score: 3

No it isnt Member since:
2005-11-14

I'm pretty sure Gallium3D should be able to handle that as well.

Reply Score: 2

adamk Member since:
2005-07-08

It doesn't currently handle this on any other operating system (though, yes, theoretically it could if enough time was spent on it).

Reply Score: 2

umccullough Member since:
2006-01-26

3D acceleration is a noble goal, but can we at least get drivers that can properly handle HD resolutions and 2D acceleration?


You weren't specific about your particular needs - but I'll assume you're either using some recent video chip for which Haiku is still missing a driver (namely, a Radeon HD or nVidia G80 or newer chips), or simply uninformed.

Haiku does already have "simple 2D acceleration and modesetting" with support for HD screen resolutions. There's a pretty decent range of chips supported as well - but there is currently zero 3d hardware acceleration support in Haiku (except perhaps for Rudolf's experimental 3d nvidia driver, but it doesn't work with Haiku's opengl stack).

Reply Score: 3

adamk Member since:
2005-07-08

I am most certainly not uninformed. I noticed similar remarks on the mailing list back when the poll was done and so many people also requested modesetting drivers.

I suspect a large percentage of the poll-takers don't even know if their hardware is supported by one of Haiku's existing video drivers, and as a result were unable to make an informed choice on that particular question.

That should sound familiar... Why not accept that people actually knew what they were voting for and that I knew what I was talking about above?

No recent GPU that I've tried (various radeon and nvidia cards) supports HD modes or 2D acceleration. Thankfully the vesa driver is quite impressive, and the lack of 2D acceleration is not really a problem.

But 1280x1024 on an LCD that prefers 1680x1050 is just awful to look at.

Reply Score: 3

umccullough Member since:
2006-01-26

Why not accept that people actually knew what they were voting for and that I knew what I was talking about above?


Because I *seriously* doubt the > 1000 poll takers that I was referring to have tried Haiku on a large percentage of hardware. Out of the dozen or so machines I have tested Haiku on (mostly machines that are between 3 and 10 years old), the only one that springs to mind as having no accelerated video currently is my new Atom D510 with Intel's N10 video. I do have a Radeon HD machine that I use for a media center which probably doesn't work either, but I haven't tested Haiku on it yet.

No recent GPU that I've tried (various radeon and nvidia cards) supports HD modes or 2D acceleration.


And, so, what do you propose is the solution to this problem of modern AMD/nvidia cards not having working 2d acceleration support? Clearly Haiku supports 2d acceleration and modesetting, and only the drivers are missing. Are you proposing that Haiku needs to implement the Linux graphics stack and port all the Linux drivers (including closed source, binary ones from nvidia)?

Note: This is different than the 3d acceleration problem where there is no current example of working 3d acceleration in Haiku. That is why I believe the Gallium3d port is arguably more important.

And while we're quoting my emails, why not also include this bit:

I didn't intend to imply we should ignore the result entirely - what I meant to imply is that the result is of little value. It doesn't tell us which hardware we need to focus efforts on first - we're obviously
not going to have video mode setting drivers for every piece of hardware ready for R1, so setting that goal will basically delay R1 indefinitely.


Edited 2011-01-26 21:21 UTC

Reply Score: 3

adamk Member since:
2005-07-08

"Why not accept that people actually knew what they were voting for and that I knew what I was talking about above?


Because I *seriously* doubt the > 1000 poll takers that I was referring to have tried Haiku on a large percentage of hardware
"

They don't need to have tried it on a large percentage of hardware. They need to have tested it on their hardware and run into a problem with modesetting. I see no reason to doubt that's the case.


And, so, what do you propose is the solution to this problem of modern AMD/nvidia cards not having working 2d acceleration support? Clearly Haiku supports 2d acceleration and modesetting, and only the drivers are missing. Are you proposing that Haiku needs to implement the Linux graphics stack and port all the Linux drivers (including closed source, binary ones from nvidia)?


No need to implement the binary ones. nouveau supports 2D acceleration, as does radeon. I can't speak directly about nouveau, but there isn't a radeon GPU (currently released) that doesn't have 2D acceleration and modesetting in open source drivers on linux. And, no, I don't suggest reimplementing the linux graphics stack. I suggest focusing on further development of the 2D drivers for Haiku that already exist to support more modern GPUs.


Note: This is different than the 3d acceleration problem where there is no current example of working 3d acceleration in Haiku. That is why I believe the Gallium3d port is arguably more important.


I would consider an example of working 3D acceleration in Haiku to be a low priority if users are going to have a hard time getting modesetting working on most of the GPUs you can currently buy off the shelf.

If the developers can't keep up with 2D acceleration for GPUs on the market, what's going to happen with the 3D support? In two years time, that 3D driver is going to support GPUs not easily available, and the 2D situation will be even worse than it is now.

In fact let's take a look at the situation with radeon GPUs (since they are the ones I'm most familiar with). gallium3d currently supports 3D acceleration on all radeons from the r300 family and up. r300, r400, and r500 are supported via the r300g driver. r600 and higher (up to the Northern Islands / r900) are supported via the r600g driver. Which of those GPUs have 2D acceleration and modesetting in Haiku? r300 and r400. There may be a few places where you can still buy those GPUs, but by the time the gallium3d port is completed, finding one will be a challenge to even the best shopper.

BTW, that's 5 generations of radeon GPUs that have no acceleration or modesetting. Some of those, obviously, may support HD resolutions if the video card itself is programmed with them, but that is not the case with the dozen AMD video card I've tested here.


And while we're quoting my emails, why not also include this bit:

"I didn't intend to imply we should ignore the result entirely - what I meant to imply is that the result is of little value. It doesn't tell us which hardware we need to focus efforts on first - we're obviously
not going to have video mode setting drivers for every piece of hardware ready for R1, so setting that goal will basically delay R1 indefinitely.
"

Because, frankly, I don't find the poll results of little value. I see no reason to take the results at anything but face value.

Edited 2011-01-26 23:15 UTC

Reply Score: 2

umccullough Member since:
2006-01-26

No need to implement the binary ones. nouveau supports 2D acceleration, as does radeon. I can't speak directly about nouveau, but there isn't a radeon GPU (currently released) that doesn't have 2D acceleration and modesetting in open source drivers on linux. And, no, I don't suggest reimplementing the linux graphics stack. I suggest focusing on further development of the 2D drivers for Haiku that already exist to support more modern GPUs.


Well, since you suggest a blanket "focus on development of 2d drivers", I'll challenge that this is not the best use of resources. Especially since Haiku developers are volunteers, unpaid, etc. They're only likely to work on hardware drivers for chips that they own. And I *do* have a suggestion.

Back to my point that it would probably be better to identify the *important* chips to support rather than all of them, I propose that when a Haiku user runs into a card that doesn't have native driver support, they should actually file an enhancement ticket in Trac: http://dev.haiku-os.org - Until that happens, we can't possibly track what the actual users of Haiku are running into, hardware support wise.

I think Haiku should add ticket voting support to Haiku's Trac so that other people who use the same hardware can vote that enhancement request up. Eventually we'll *know* which cards are most important, and can focus our development efforts as such.

This would be a MUCH more manageable approach than putting out a vague poll about this topic and then hoping that the Haiku developers will magically just work on it. This would also allow funding of hardware purchases for developers to work on the most important chips first.

Reply Score: 3

adamk Member since:
2005-07-08

I do not disagree with anything you just said :-) Please understand that it's not my intention to say the developers must work on more/better 2D drivers. I, personally, just feel it's a better use of resources and a more logical goal than 3D acceleration for one or two models of GPUs.

I do not appear to have opened up a ticket for improved radeon support. My only previous ticket concerning video support, though, still seems to be open:

https://dev.haiku-os.org/ticket/3501

Maybe an enhancement ticket is still worth creating, though.

Adam

Reply Score: 2

umccullough Member since:
2006-01-26

Maybe an enhancement ticket is still worth creating, though.


Indeed ;)

And with that, this discussion reminded me that there's a new patch for Intel N10 that I haven't tested yet:

http://dev.haiku-os.org/ticket/6202

Reply Score: 2

I'm sure
by cipri on Wed 26th Jan 2011 15:57 UTC
cipri
Member since:
2007-02-15

I'm sure, if we find somebody willing to port Galium3D, then I'm sure that the bounty will rise even more.

Reply Score: 1

There is a solution...
by Luposian on Wed 26th Jan 2011 22:39 UTC
Luposian
Member since:
2005-07-27

But it requires abandoning conventional wisdom. It would never be as fast as an actual video card, natively supported with a proper driver, but it would likely, be much faster than what we have currently.

Reply Score: 2

vesa 3.0
by specialspambot on Fri 28th Jan 2011 16:05 UTC
specialspambot
Member since:
2011-01-28

There was work done on the new OS kernel years ago to support vesa 3.0 which allows for alot more modesetting power. Maybe the haiku devs could investigate such a feature to update the existing vesa 2.0 driver with a more powerful vesa 3.0. I know the source code it still in the newos trunk I looked at it just a few days ago.I just don't have the needed deep system knowledge to get it working.

Reply Score: 1