Announcement

Collapse
No announcement yet.

AMD's R300 Gallium3D Driver Is Looking Good For 2011

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • marek
    replied
    Yes, --with-dri-drivers=x,y,z,... is for classic. --enable-gallium-xxx is for gallium. You don't have to type --enable-gallium-radeon and I recommend you not to do so, because it builds the xorg state tracker powered by r300g, which is unsupported and untested. lib/gallium/r300_dri.so is always built unless you type --disable-gallium-radeon.

    Leave a comment:


  • 69acid69
    replied
    Thanks, it worked

    Leave a comment:


  • Paulie889
    replied
    Originally posted by 69acid69 View Post
    well, as you can see i'm using --with-dri-drivers=r300, but still double build (mesa + gallium)
    could you specify a bit?
    Yeah, that is why r300c is being build, you need to set --with-dri-drivers= which mean you don't want any dri drivers, however you will still get r300g driver because it is being build by default.

    Leave a comment:


  • 69acid69
    replied
    Originally posted by marek View Post
    Use: --with-dri-drivers=
    well, as you can see i'm using --with-dri-drivers=r300, but still double build (mesa + gallium)
    could you specify a bit?

    Leave a comment:


  • curaga
    replied
    What about the low-hanging fruit, such as compiling independent-from-each-other shaders in parallel?

    Leave a comment:


  • marek
    replied
    Originally posted by 69acid69 View Post
    Hi folks,
    how to build only gallium without mesa build?

    Because now i've got:
    ../mesa/lib/r300_dri.so <<- mesa (R300 classic)
    ../mesa/lib/gallium/r300_dri.so <<- gallium (R300 gallium)

    please, correct me if i'm wrong!

    P.S. my configure line looks like this:
    ./configure --disable-gallium-nouveau --disable-gallium-svga --disable-gallium-i915 -disable-gallium-i965 --disable-gallium-swrast --enable-gallium-radeon --disable-64-bit --enable-32-bit --enable-asm --disable-debug --disable-glut --disable-glu --disable-glw --disable-egl --disable-openvg --with-state-trackers=dri,glx --with-dri-drivers=r300

    P.S.S Unreal Tournament runs better in mesa about +10fps (self demo rec). Unreal Gold crash whole system with gallium (Ctrl+Alt+Backspace does not help).
    Use: --with-dri-drivers=

    Leave a comment:


  • RussDill
    replied
    Originally posted by popper View Post
    as it happens, i agree with what you say, basically make a development plan ,follow it, its the only way to progress in a timely manor.

    But, and theres always a but, If your plan actually includes 'threading' in this case at some point, then allowing for that at the core of your plan is probably a good thing to consider, so you dont have to rip out lots of new code that just doesn't work well with threading later.

    if there is a suggestion, that is it, nothing more, nothing less.

    OC given we are talking Open source here and not closed , then what harm is there to pick an existing well optimized external threading code base library , use its supplied API ,and try building your plan with that along side your other tests as you progress, slightly more work sure, but mattst88 and others are coding for Fun and to learn/try new thing's not pay i assume!
    You seem to be under the misunderstanding that multi-threading is some feature that is added by linking to a library and calling some functions. I can assure you, it is nothing like that. The linking to a library part and calling functions part is much less than 1% of the effort that would be required.

    Leave a comment:


  • 69acid69
    replied
    how to build only gallium (r300) ?

    Hi folks,
    how to build only gallium without mesa build?

    Because now i've got:
    ../mesa/lib/r300_dri.so <<- mesa (R300 classic)
    ../mesa/lib/gallium/r300_dri.so <<- gallium (R300 gallium)

    please, correct me if i'm wrong!

    P.S. my configure line looks like this:
    ./configure --disable-gallium-nouveau --disable-gallium-svga --disable-gallium-i915 -disable-gallium-i965 --disable-gallium-swrast --enable-gallium-radeon --disable-64-bit --enable-32-bit --enable-asm --disable-debug --disable-glut --disable-glu --disable-glw --disable-egl --disable-openvg --with-state-trackers=dri,glx --with-dri-drivers=r300

    P.S.S Unreal Tournament runs better in mesa about +10fps (self demo rec). Unreal Gold crash whole system with gallium (Ctrl+Alt+Backspace does not help).

    Leave a comment:


  • marek
    replied
    Originally posted by popper View Post
    "The open source drivers are not multi-threaded AFAIK" which is Very ODD Today if thats really the case, as NPTL(Native POSIX Thread Library)has been in since 2.6 started http://en.wikipedia.org/wiki/Native_...Thread_Library
    "NPTL has been part of Red Hat Enterprise Linux since version 3, and in the Linux kernel since version 2.6. It is now a fully integrated part of the GNU C Library.[citation needed]
    There exists a tracing tool for NPTL, called POSIX Thread Trace Tool (PTT). And an Open POSIX Test Suite (OPTS) was written for testing the NPTL library against the POSIX standard." ,not to mention there are several other optimized 3rd party threading libraries suitable for any such driver inclusion around too.
    Using more than one core in the current graphics stack is a non-trivial task and using more than two cores efficiently is nearly impossible. There's a lot of tasks which must be performed in-order, e.g.:

    task A -> task B -> task C -> task D -> task E -> task F ...

    You may split this into two threads, like this:
    1st thread: task A -> task B -> task C -> write the output of C to a work queue.
    2nd thread: read the work queue -> task D -> task E -> task F

    Now where would you do the split in the current stack? Before st/mesa? Or after st/mesa and before the driver? Or between the driver and libdrm? Somewhere else? Note the split itself costs a lot of CPU cycles.

    Of course we could use OpenMP or Threading Building Blocks etc. for some algorithms but that would give us very little speedup, not enough to get 2 fully-loaded cores.

    I'd really like to see an actual plan instead of arguing that we should use some threading library. No library will magically use all your cores. And BTW, Mesa does use NPTL; it didn't help much, did it?

    Leave a comment:


  • bridgman
    replied
    Originally posted by Qaridarium View Post
    in your words there are some spec infos left and you say something about 5% means the OS driver r600 can have up to 95% of the speed
    Sure, but I also said that the last few bits of hardware info were not things where hardware support could easily be added to the open driver... if we ever get to the point where the open driver has a large team of developers doing application-specific optimizations *then* the additional HW info could make a difference. Not 100% sure, but I believe the 5% difference quote was from the 5xx days, and we have actually released some of that info since then (for both 5xx and 6xx+). I believe I was thinking of CMASK info and a few other bits when I mentioned the 5% number.

    I'm not sure if the CMASK info turned out to be useful... there was some hope of using it for faster clears but don't remember if that actually worked out.

    Originally posted by Qaridarium View Post
    @bridgman:but in the video decode side you imagine thats there are only mpeg2 but the x1950 have shader based h264 decode...
    I was talking about video decoding *hardware*, ie not counting general purpose shaders. On 5xx and earlier that is MPEG2-only (other than the rv550).

    Leave a comment:

Working...
X