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:
Top Downloads in 30 Days
Free Heroes of Might and Magic II
DosBox 0.73
Firefox (Bezilla)
BeOS 5 PE Max Edition
VLC Media PlayerSearch Files
Newest Files
May 20 |
EGSL 1.5.3 |
| May 19 |
Powder |
| May 12 |
GUIsetdecor |
| May 8 |
QupZilla 1.2.0 |
| May 6 |
D52, D48 and Dz80 |
Comments
Its a trivial thing though as once one driver is done the others are likely to follow.
Anyway, awesome bounty! I can't wait to see what becomes of this! Thanks.
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.
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."
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:
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
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)
Actually ripped it from Aros' bounty
@sparkle - yea saw that interesting!
Might D3D11 be supported in Haiku when Gallium3D has been ported?
http://www.phoronix.com/scan.php?page=article&item=nouveau_gallium3d_first&num=1
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.
Make a post on OSnews. I don't have a account but OS news gets loads of developer traffic.
di you put out email today about a developer ? spill the beans Karl,
Kick ass,fully native ?no X etc ?? I sure hope so. I saw the email and felt pretty chipper this afternoon.
mapopa.blogspot.com/
as well as the dev mailing list
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.
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:
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.
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.
hehe, well when they reach being the #1 world wide exporter with only 80 million people, I'll believe it
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?
Quote:
If I don't hear anything by the 26th it's over...
I guess there is still no response from andrian. What happens now?
the options are:
refunds
donate to Haiku (perhaps towards mmlr's contract?)
any other recommendations?
Artur and see if he is still interested he hasn't committed in quite awhile?
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.
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.
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.
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.
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.
RSS feed for comments to this post