Login

logo6

Gallium

freedesktop

Target: $2000 Reached! Balance
Developer
Assigned | Alexander von Gluck (kallisti5) - Check Status

Alexander proposes the bounty be split into payment milestones with the following guidelines:

  • 0% * Update Mesa3D / aka Gallium3D to current and work on getting changes accepted in Mesa upstream
  • 0% * Get stock Mesa3D into the build system somehow so it is pulled / extracted prior to compiling opengl kit
  • 25% * 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.)
  • 50% * Get at least one Gallium3D Hardware driver working / rendering.
  • 25% * Get two Gallium3D Hardware drivers working / rendering.

The amounts are proportionate to the work done.

Links:


alt

 

 

Back to the bounties...


Share

Comments  

 
+2 # RE: Galliumcb88 2010-09-13 20:50
Is there some reason the nvidia driver was specified? It seems the developer should implement whichever driver for the hardware he has. Radeong is also in a more advanced state as it has open documentation. Also Gallium isn't everything maybe you missed my previous post hopefully the port will be flexible enough to accommodate the classic mesa drivers as well as some hardware will *never* have a gallium driver namely embedded and older GPUS.

Its a trivial thing though as once one driver is done the others are likely to follow.
 
 
+1 # RE: RE: Galliumkarl 2010-09-14 01:33
This is mostly copied from the AROS bounty. I really am not well versed with the specifics of what's needed and what would be best for Haiku. I just know that Gallium would be a good option for 3D on Haiku. You may have also missed that I wrote this is a guideline, and the community is welcome to help rewrite this. So, if you'd like to submit a more formal proposal and guidelines, please do.
 
 
+3 # RE: Galliumsparklewind 2010-09-14 02:24
I understand what you're saying. I am not too knowledgeable about the more technical aspects of Gallium3D so to speak, so I can't make a more formal proposal than what's written here. I would like to question the nVidia thing however. Isn't it better to try to get some Radeon HD support? ATI is a lot more supportive and release documents, and I think the open source drivers have come further with those cards.

Anyway, awesome bounty! I can't wait to see what becomes of this! Thanks.
 
 
+1 # RE: RE: Galliumkarl 2010-09-14 05:55
Yes, I'm not too sure why AROS specified the Nvidia driver as well, would require more investigation. Perhaps, as they say, this is a sample driver, and there only is a Nvidia sample driver. If ATI (AMD) is better at releasing specs, then it should be easier to support those (maybe why they wanted the Nvidia driver). You have to remember years ago though, it was ATI who wouldn't release docs very easily. They wouldn't even provide binary drivers for Linux (and Nvidia did).

Yes, I hope someone that knows what they're doing can take on this project - and someone else can help with the guidelines; if not the developer themselves.
 
 
+3 # RE: RE: RE: Galliumtonestone57 2010-09-21 20:00
For #3:
Gallium drivers are listed here:
cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers
Person taking over the bounty could choose any of the hardware accelerated 3D drivers.

Gallium3D device drivers
cell - Driver for Cell processor.
i915 - Driver for Intel i915/i945.
i965 - Driver for Intel i965.
llvmpipe - Software driver using LLVM for runtime code generation.
nv* - Drivers for NVIDIA GPUs.
r300 - Driver for ATI/AMD R300.
softpipe - Software reference driver.
svga - Driver for VMware's SVGA virtual GPU.
trace - Driver for tracing Gallium calls.
from here:
www.mesa3d.org/sourcetree.html
Also ATI r600 in repo and not listed above.

I would also throw in llvmpipe (requires llvm compiler) (or i915) as optional extra. This allows anyone not having the correct hardware to get somewhat faster 3D. i915 should support 1st generation Atom systems.

#4:
I provided a few 3D demos. Michael provided 3D demos and 3D games. These will run faster with HW 3D driver. GLTeapot and Quake 3 port should run faster too, etc.
"Test and demonstrate with OpenGL demos and games to show performance difference, compared to software renderer, and driver stability."
 
 
+1 # RE: RE: RE: RE: Galliumkarl 2010-09-21 20:54
thanks ts. i'll update it tomorrow :lol:

from aros' bounty, i still don't understand why the drivers have to be ported. i thought that was the point of gallium (once gallium is itself ported, all the drivers will just work).

from the gallium project:

Quote:
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.
 
 
-1 # RE: RE: RE: RE: RE: Galliumtonestone57 2010-09-22 09:22
Look at modules section for lots of information & overview:
jrfonseca.blogspot.com/2008/04/gallium3d-introduction.html

State Tracker talks to Graphics API (OpenGL)
Winsys talks to OS (ie: Haiku). Only Winsys requires OS dependent code. Look at Module Dependency Table

Some background information on Gallium 3D:
dri.freedesktop.org/doxygen/gallium/index.html
 
 
+2 # RE: RE: RE: RE: RE: RE: Galliumkarl 2010-09-22 10:38
I nominate you to rewrite the bounty ;-)
 
 
+1 # RE: RE: RE: RE: RE: RE: RE: Galliumtonestone57 2010-09-22 13:26
Your bounty outline is good Karl. I think anyone applying for it understands they have to accomplish what I stated below.

In General (what matters):
1) Get Gallium 3D working on Haiku 2) create working hardware accelerated Gallium 3D driver (Nvidia, Ati or Intel) 3) test and show actual performance and stability with OpenGL demos and with two OpenGL games.(showing fps during operation)
 
 
+1 # RE: RE: RE: RE: RE: RE: RE: RE: Galliumkarl 2010-09-22 15:57
Quote:
Your bounty outline is good Karl.


Actually ripped it from Aros' bounty :-*

@sparkle - yea saw that interesting!
 
 
+1 # RE: Galliumsparklewind 2010-09-22 12:52
This might not be directly related to the bounty, but I thought it was interesting: http://www.phoronix.com/scan.php?page=article&item=mesa_gallium3d_d3d11&num=1
Might D3D11 be supported in Haiku when Gallium3D has been ported?
 
 
+1 # RE: Galliumthatguy 2010-10-15 21:33
Some may wish to review this benchmark suite.

http://www.phoronix.com/scan.php?page=article&item=nouveau_gallium3d_first&num=1
 
 
0 # RE: Galliumthatguy 2011-01-22 23:58
Has anyone contaced the developers from the gallium project yet about maybe one of them or their lower tier guys being interested in this ?

Would certainly seem like the best place to get a developer. The core Haiku dev's don't seem terrifically interested in any projects like this.
 
 
0 # RE: RE: Galliumkarl 2011-01-23 11:01
I can't remember if I did. This is a community effort, so go ahead and contact... ;-)
 
 
0 # RE: RE: RE: Galliumthatguy 2011-01-23 20:21
trying to respect the hierarchy. I am actually chasing other fish right now.

Make a post on OSnews. I don't have a account but OS news gets loads of developer traffic.
 
 
+2 # RE: RE: RE: RE: Galliumsparklewind 2011-01-24 07:28
I just went ahead and made a post. Hopefully it will get approved and it will be up soon.
 
 
0 # RE: RE: RE: RE: RE: Galliumkarl 2011-01-24 19:24
where?
 
 
0 # RE: RE: RE: RE: RE: RE: Galliumsparklewind 2011-01-25 05:07
osnews.com. They seem to have silently removed my post from the list of pending submissions though..
 
 
0 # RE: Galliumsparklewind 2011-01-25 09:58
The article got submitted now. It's visible now on the right row if you go to osnews.com.
 
 
0 # RE: Galliumthatguy 2011-01-28 20:55
any bites ?
 
 
0 # RE: RE: Galliumkarl 2011-01-29 10:02
I do have one person that expressed interest, although he needs more time to decide if he'll take it on. If I don't hear from anyone else I'll be emailing him three days before the bounty expires (Mar. 15th), to make a decision...
 
 
0 # RE: RE: RE: Galliumthatguy 2011-03-15 19:38
Quoting karl:
I do have one person that expressed interest, although he needs more time to decide if he'll take it on. If I don't hear from anyone else I'll be emailing him three days before the bounty expires (Mar. 15th), to make a decision...


di you put out email today about a developer ? spill the beans Karl,
 
 
+1 # RE: RE: RE: RE: Galliumkarl 2011-03-15 19:53
I'll let you guys know within two days. Not only do I have interest in one, but two of the bounties! ;) One promised a proposal, the other needs two days to see if it's feasible/he's capable of doing the work..
 
 
0 # RE: RE: RE: RE: RE: Galliumthatguy 2011-03-15 20:28
Quoting karl:
I'll let you guys know within two days. Not only do I have interest in one, but two of the bounties! ;) One promised a proposal, the other needs two days to see if it's feasible/he's capable of doing the work..



Kick ass,fully native ?no X etc ?? I sure hope so. I saw the email and felt pretty chipper this afternoon.
 
 
0 # Any News?vooshy-agh 2011-05-03 11:54
Just wondering if their is any news on progress with this bounty?
 
 
0 # RE: Any News?karl 2011-05-03 12:12
I think he's writing here,

mapopa.blogspot.com/

as well as the dev mailing list
 
 
0 # RE: RE: Any News?vooshy-agh 2011-05-03 12:17
can't see anything gallium related but thanks
 
 
0 # RE: Galliumthatguy 2011-05-24 00:40
updates ?
 
 
0 # Popacipri 2011-05-24 12:28
Andrian Popa, is from Romania. And sadly, I have the impression that some romanian programmers are not very serious.
No updates, nothing. I remember the wifi port. Collin made a schedule and with fixed dates and so on.
I think, if adrians continues not to give any kind of update, we should simply make the gallium bountry open again, so that perhaps we find somebody else.
 
 
+1 # RE: Popakarl 2011-05-24 16:56
hehe, well I think we all know, nothing beats German productivity and efficiency :eek:

anywayyyyys, to be fair, to make sure stuff like this doesn't happen, I adjusted the rules developers are to abide by if they accept a bounty (before Adrian started).

that can be found under #4:

Quote:
In order to maintain the quality, integrity and succes of bounties at Haikuware, as of Oct. 1, 2010, all developers accepting a bounty job are required to submit quarterly progress reports.


Adrian started the bounty Mar. 26th, for a one year term. That would mean he's obliged to update us by Jun. 26th ;-)

That said, I have mailed him to ask how things are going.
 
 
0 # RE: RE: Popatonestone57 2011-05-25 20:40
Quote:
hehe, well I think we all know, nothing beats German productivity and efficiency


Maybe Japanese do =)

Yes, I agree Germans are very hard and smart workers.

Having updates every month or two months is much better. Even if just 3 to 5 lines to say what happened or is going on. Short, to the point reports with couple of lines are good with me.
 
 
0 # RE: RE: RE: Popakarl 2011-05-26 07:22
Quote:
Maybe Japanese do =)


hehe, well when they reach being the #1 world wide exporter with only 80 million people, I'll believe it :P

adrian said he'll provide an update (and roadmap) by the end of this week.
 
 
0 # RE: RE: RE: RE: Popacipri 2011-06-13 17:01
Quoting karl:
adrian said he'll provide an update (and roadmap) by the end of this week.


I guess the "end of this week" is already over :-)
Still no signs of any kind of progress?
 
 
0 # RE: RE: RE: RE: RE: Popakarl 2011-06-13 17:32
indeed, I've heard nothing so far. But

Quote:
Adrian started the bounty Mar. 26th, for a one year term. That would mean he's obliged to update us by Jun. 26th


If I don't hear anything by the 26th it's over...
 
 
0 # RE: RE: Popacipri 2011-06-26 10:34
ok, now we have 26 june.
I guess there is still no response from andrian. What happens now?
 
 
0 # RE: RE: RE: Popakarl 2011-06-26 12:00
yes, this is disappointing. but, the bounty taken on by Adrian will be cancelled due to failure to comply to the rules set out.

the options are:

  • reopen and look for a new developer.
    refunds
    donate to Haiku (perhaps towards mmlr's contract?)


any other recommendations?
 
 
0 # RE: RE: RE: RE: Popacb88 2011-06-27 07:14
It would seem kinda odd to donate the money to anything other than the 3d drivers it is at the top of the "want list" too for users. Perhaps get back with
Artur and see if he is still interested he hasn't committed in quite awhile?
 
 
0 # RE: Popathatguy 2011-05-25 19:07
Quoting cipri:
Andrian Popa, is from Romania. And sadly, I have the impression that some romanian programmers are not very serious.
No updates, nothing. I remember the wifi port. Collin made a schedule and with fixed dates and so on.
I think, if adrians continues not to give any kind of update, we should simply make the gallium bountry open again, so that perhaps we find somebody else.



Actually, I am beging to think Gallium is a bad design decision the more I learn about graphics stack programing, Although there are many useful thing in gallium.

I am working on a design proposal but its going to take months of research and a good bit of testing to figure out what to do, but the gallium design adds to many layers of abstraction.To much overhead and will never get close to directX drivers.
 
 
0 # RE: RE: Popacb88 2011-05-28 20:34
If you are going to say its a bad design decision say why.. don't just leave us hanging.

The biggest problem with gallium at the moment is the expense of state changes and buggy libdrm code... once that gets ironed out you're going to have alot harder time bashing it.

The mesa developers working on gallium aren't focusing on performance now anyway they are working on getting it working. I hate to quote the crappy phoronix benchmarks but at least they show that in some situations the gallium drivers are getting there.
 
 
0 # RE: RE: RE: Popacb88 2011-05-28 20:37
The bad design decision I see is using LKL to wedge linux into haiku to make a hacky compatibility layer. I mean the real gallium port has to happen anyway why not do it right to begin with.
 
 
0 # RE: RE: RE: RE: Popatonestone57 2011-05-29 10:28
Quoting cb88:
The bad design decision I see is using LKL to wedge linux into haiku to make a hacky compatibility layer. I mean the real gallium port has to happen anyway why not do it right to begin with.

Reason is because LOTS of work and nobody wants to do it!!! Not only must lots of work be done but then someone would have to maintain the port.

Using LKL makes it [1] easier to port to Haiku [2] with only the LKL having to be updated and maintained and not any changes to Gallium [3] Gallium will change much more often than the LKL would and so require more work to maintain and update.

Same reason why Haiku uses BSD network drivers rather than native ones (ie, less work & easier).

Hard to interest developers to do the actual programming work for a native port of Gallium to Haiku. Same for VLC which no longer offers BeOS GUI and no developer willing to do the work to maintain VLC front end for Haiku.

Non-native ports are quick & easy to do with lots less work. That is why. =)
For now it is Ok until R1 release and then should try to get couple more native versions of applications.

I also think native Gallium would give little or no performance improvement over Linux version. It may even perform slower. Keep in mind that Gallium is written for Unix and going native means rewriting lots and lots of the code for Haiku.
 
 
0 # RE: RE: RE: Popathatguy 2011-05-28 22:02
Quoting cb88:
If you are going to say its a bad design decision say why.. don't just leave us hanging.

The biggest problem with gallium at the moment is the expense of state changes and buggy libdrm code... once that gets ironed out you're going to have alot harder time bashing it.

The mesa developers working on gallium aren't focusing on performance now anyway they are working on getting it working. I hate to quote the crappy phoronix benchmarks but at least they show that in some situations the gallium drivers are getting there.


the code compile and conversion path is really long.

you have several layers of front end

first you have the state tracker, which is going to take say openGl and translate that to TGSL. Then you have to take the TGSL and compile that to native binary.

so you are twice converting the output. the real question becomes, why convert everything to TGSL, thats a pretty heavy performance hit on the cpu side.

I get that is make the gpu jit generic, but its going to incur a massive performance penalty even if its is multithreaded, I do not belive it is currently multithread.

Even regular mesa on haiku could be dramaticlly improve with parrellel frame processing by dispatching a worker thread per core per frame.

IE if each core had a rendered frame being worked in parrelell and then you could get significant speed ups in graphics on raw software.

It'd be tricky.

But up front it could net some big performance. Now do the same thing with gallium. The part that is really of interest is the JIT anyways as thats where the magic happens.

While haiku needs a dri/drm of sorts, it doesn't have to be anything like the X version.

I am still learning alot about the architecture and design but so far, looks like alot of running in cricles.

As to why gallium is doing there design. Its pretty simple, you can have one compiler for each gpu family and then have the state trackers handle the conversion from "insert Api here" to TGSL therby eleminating multiple jits for each api, the side effect is going to be a nearly doubling of cpu consumption for the graphics pipeline.

not to mention that the jit needs to be multithreaed so it can take advanatge of all the power new cpu's offer.
 
 
0 # RE: RE: RE: RE: Popacb88 2011-05-29 11:26
There is no such thing as a dri/drm X version.. its direct that is the whole point. As far as that goes X is dying anyway... and Wayland will likely replace it. Wayland is rather alot more modern than X.

Also the performance bottlenecks are not in the compiler which is the IR you speak of which actually is there to save cycles by being an easy to optimise format... they are in the state tracker transitions read the mailing list for yourself.

Mesa has been parallelized before.. llvmpipe and the Cell SPU driver are both parallel.

My point is one way or other .. the opengl calls have to be converted into an internal representation before the command steram can be generated.. may as well be TGSL

While on paper it looks like its more layers... it is just that the layers have been more cleanly separated that were already there.
 
 
+2 # RE: RE: RE: RE: RE: Popathatguy 2011-05-29 14:30
Quoting cb88:
There is no such thing as a dri/drm X version.. its direct that is the whole point. As far as that goes X is dying anyway... and Wayland will likely replace it. Wayland is rather alot more modern than X.

Also the performance bottlenecks are not in the compiler which is the IR you speak of which actually is there to save cycles by being an easy to optimise format... they are in the state tracker transitions read the mailing list for yourself.

Mesa has been parallelized before.. llvmpipe and the Cell SPU driver are both parallel.

My point is one way or other .. the opengl calls have to be converted into an internal representation before the command steram can be generated.. may as well be TGSL

While on paper it looks like its more layers... it is just that the layers have been more cleanly separated that were already there.



DRI/DRM are very much X window system concepts. they are a very complicated way of doing a ring buffer.

Graphics performance on linux is often 50% of that on directx on windows on the same hardware using propritary drivers.sadly consoules outrun PC's windows to Xbox by about 50%. the linux graphics stack and design is cpu bottle necked or pipeline bottle necked. I don't know nor care enough about the linux design to really know all the detailed reasons. but its obviously a bad design.

the windows design gets closer to the driver then the current linux designs.

My point is that the linux design is heavy and messy. Looking at the windows design and or consoule designs is a better way to go. In fact the 3dfx opengl windows driver points the way to hwo to construct efficient drivers. Been looking at it for a long time.

All of those IR's have a time penalty. No way around it, you make enough turns you loose speed period.

the state trackers job is to recompile the opengl into TGSL and its not a straight transliteration. It requires some over head. I get why they are designing the way they are. It makes perfect sense for a portable design.

However, its add more turns. Turns cost time and cpu cycles.the problem with gallium performance isn't the card, its the graphics stack pipeline. Its having a good enough compiler and pipeline to feed the card.

While Gallium will be good, haiku as a group could do much better by taking the best parts of gallium an adapting them to haiku instead of bringing all the heavy IR layers. It can be done and honestly, I think it would actually be easier.
 


Please register to post comments

Search Files

Search For: 
Search File Titles: 
Search File Descriptions: 

The Largest BeOS/Haiku Software Repository