R600 Gallium3D Shader Compiler Milestone Hit

[bridgman]

Right now I believe glisse is writing new compiler code for the 600g driver rather than converting TGSI back to the "classic" program format to re-use the old compiler (as I understand was done for 300g).

As long as there is a working reference driver (which we have today with the classic 600 code) it may turn out that writing new code is just as fast. There was a big investment in optimizing 3xx-5xx shader programs which was felt to be worth keeping, but the corresponding optimization work has not yet been done for 6xx and higher.

[Nille]

for an real solution amd do have some problems in hardware!.....
remember R600+ R800 is not amd hardware its ATI hardware!
ATI=the bad one...
AMD= the good one
but yes AMD do have a plan to save us all but they need new hardware desine!
R900 will save you!
Pure AMD Philosophie hardware !
means: no bullshit just work....
R900 means secure processing part is a other transistor than the viedeo acceleration part!
so you can have a full featured SPEC for the opensource driver.
and clousedsource DRM brainfucked stubit people can have HDCP copy-protection to.

Do you has thoughts diarrhea? Your Posts are getting more stupid. You ever once think about what you write?

[BlackStar]

Crossfire is pretty useless (on Windows too, but esp. on Linux),

Appart from giving me more FPS (Crysis) I would rather have a dedicated OpenGL 3.2 card for games and compositing and the rest of the State Tracker goodness, including OpenCL apps, on another dirt cheap, but still capable, ATI card.

Responsiveness for the win!

Interesting idea, put that idle IGP or secondary card to work. Too bad drivers are too unstable at this point for the idea to work (dirty stare at Nvidia). Maybe by the time OpenCL 1.1 is released this will be feasible.

[V!NCENT]

@BlackStar:
While there will almost be no OpenCL software in the free software spectrum anytime soon, I can see the computing landscape change drasticaly with more and more tasks being demanded from the graphica card that are not graphics related, or at least not directly.

With Gallium3D the performance will already be less than optimal.

With more powerfull IGP's and shader processors in the CPU, I think that they should take on all the other non-gaming stuff.

I always likes multicore because of the timeslicing 'problem' and not nessecarily increased performance.

In the future I hope that the CPU with its shaders shaders will take on the compositing desktop, the IGP/secondary GPU take on the rest and the 'primary' GPU take on the rasterised games and raytracing.

I don't think that that's unpractical and distant science fiction et al...

[jrch2k8]

afer reading the whole thread i ll just say patience my fellow geeks

remember that OSS development cycle are long but good, i mean at first KMS was unusable and unstable almost like fglrx, but now is amazingly stable, 2d has gettting a lot better, rigth now in peacekeeper my browser hit almost the same value of windows 7 in the advanced 2d graphics, XVideo is perfect rigth now even under heavy load.

so what you should expect is not a magically super fast 3d engine just yet
you should expect something like these:

* slowish mesa 3d until gallium is here
* slowish gallium 3d until all features for gl3.2 and glsl are there
* slowish gallium 3d until opencl tracker is here
* slowish but a bit better gallium 3d until first stable release
* improved shader code in gallium
* major clean up and optimization the gl library
* here come the focus of performance and FPS

about video acceleration my bet is forget about gallium peeps, the most and smarter solution is to reach an stable opencl tracker then the rigth projects take the stick to accelerate their code like FFMPEG and xorg. is not such a good idea to over load gallium with stuf that should be in other projects.

about svg accel and color handling i think this should be done in xorg not gallium but thats me

so patience cuz is better this way, i prefer i well thinked driver coded to be "the shit" than a unusable fglrx abort.

beside the brigth side is like gallium and mesa advances more dev will eventually join, gpu dev is not that easy but once the code is there is easier for more dev to optimize and test

[droidhacker]

about video acceleration my bet is forget about gallium peeps, the most and smarter solution is to reach an stable opencl tracker then the rigth projects take the stick to accelerate their code like FFMPEG and xorg. is not such a good idea to over load gallium with stuf that should be in other projects.

I completely DISagree.
Problem is with the various different hardware that is available, the relative capabilities and performance, availability of video decode hardware, etc. G3D offers the possibility of making this whole video decode problem transparent by using common APIs rather than having to reimplement everything the hard way within every video decoder.

[bridgman]

I have to argue in favour of video-specific APIs as well. There are some video-related tasks which can work well with compute APIs like OpenCL or CUDA, but other video processing tasks can still be done more efficiently with a lower level API.

[lucx]

Hello,

does some one know if we can test this git repo: http://cgit.freedesktop.org/~glisse/mesa/
is safe, is in an testable state or is to early to test? for r600, r700.

[bridgman]

If you want to draw a single triangle, I imagine it's OK to test. If you want to do anything more, maybe wait for a while

[glisse]

Hello,

does some one know if we can test this git repo: http://cgit.freedesktop.org/~glisse/mesa/
is safe, is in an testable state or is to early to test? for r600, r700.

Like John said if you want to draw tri-flat tri-gouraud it will make you happy but if you want to test it against other app you will just see red window ... so the interest is very limited from non developer point of view. Also i am not interested in testing yet i wouldn't be surprised if it only works on rv710.