Announcement

Collapse
No announcement yet.

Testing Out AMD's DRI2 Driver Stack

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

  • Veerappan
    replied
    Originally posted by agd5f View Post
    you'll also need to revert:
    8338385cd94b35f54b25cf2576890159f8dd9f71
    or just apply this patch:
    http://www.botchco.com/alex/xorg/kms_fix_xv.diff
    which contains both the reversion and the clipping fix.
    Much better. The picture looks correct as far as I can tell. Xv is now usable, and much improved over having to set gstreamer to non-Xv output (was getting alternating smooth video and a slideshow watching videos earlier).

    Thank you for the patch, and keep up the great work.

    --Aaron

    Leave a comment:


  • agd5f
    replied
    Originally posted by Veerappan View Post
    Hey Alex,

    Thanks for the diff. I patched a fresh copy of the radeon-rewrite branch using what you just posted, and the Xv output is indeed improved, but there's still some cropping going on. I am seeing what looks like the upper-left quadrant of the video stream (using Miro to test using Xv output, M22 (x300 mobility), Ubuntu 9.04 w/ KMS/DRI2/etc), but the other 3/4 of the video are getting chopped off.

    I'll probably play around with the offset changes you had in your diff to see if I can get it to work on my machine, but no guarantees.

    --Aaron
    you'll also need to revert:
    8338385cd94b35f54b25cf2576890159f8dd9f71
    or just apply this patch:
    http://www.botchco.com/alex/xorg/kms_fix_xv.diff
    which contains both the reversion and the clipping fix.

    Leave a comment:


  • Veerappan
    replied
    Originally posted by agd5f View Post
    This patch fixes the Xv problems with Glisse' kms DDX:
    http://www.botchco.com/alex/xorg/kms_fix_clipping.diff
    Hey Alex,

    Thanks for the diff. I patched a fresh copy of the radeon-rewrite branch using what you just posted, and the Xv output is indeed improved, but there's still some cropping going on. I am seeing what looks like the upper-left quadrant of the video stream (using Miro to test using Xv output, M22 (x300 mobility), Ubuntu 9.04 w/ KMS/DRI2/etc), but the other 3/4 of the video are getting chopped off.

    I'll probably play around with the offset changes you had in your diff to see if I can get it to work on my machine, but no guarantees.

    --Aaron

    Leave a comment:


  • agd5f
    replied
    This patch fixes the Xv problems with Glisse' kms DDX:
    http://www.botchco.com/alex/xorg/kms_fix_clipping.diff

    Leave a comment:


  • cliff
    replied
    Originally posted by nanonyme View Post
    4.5? o.O Did you mean 9.5?
    Yes 9.5 thanks

    Leave a comment:


  • nanonyme
    replied
    Originally posted by cliff View Post
    No, in Intrepid the Catalyst drivers were progressing nicely. But now with Jaunty they are a no-go. I though about going back to Intrepid but I have everything working nice in Jaunty except 3d so I am taking a break from gaming for now. Hopefully Catalyst 4.5 will soon fix the problem.
    4.5? o.O Did you mean 9.5?

    Leave a comment:


  • cliff
    replied
    Originally posted by bridgman View Post
    A few people have reported problems with the X2 boards and Jaunty, although they didn't show up in our "early look" testing on server 1.6. Did you see the same problems with Intrepid ? If not, it might be worth staying on 8.10 until we finish QA testing & bug fixing on Jaunty, and announce support in the release notes.
    No, in Intrepid the Catalyst drivers were progressing nicely. But now with Jaunty they are a no-go. I though about going back to Intrepid but I have everything working nice in Jaunty except 3d so I am taking a break from gaming for now. Hopefully Catalyst 4.5 will soon fix the problem.

    Leave a comment:


  • nanonyme
    replied
    Originally posted by Pitabred View Post
    with Xv. While it's not GPU acceleration
    Err, yes it is? Wikipedia: "Most modern video controllers provide the functions required for XVideo; the feature is known as hardware scaling and YUV acceleration or sometimes as 2D hardware acceleration. "
    http://en.wikipedia.org/wiki/X_video_extension
    Edit: Oh, right. You meant as in decoding acceleration. Well, nice to see modern CPU's can actually do it with full quality with multithreading, I had to downscale playback quite a bit on my AMD64 3500+ to get it to work fluently.
    Last edited by nanonyme; 14 May 2009, 08:04 AM.

    Leave a comment:


  • bridgman
    replied
    Originally posted by cliff View Post
    In fact it has caused me many system re-installs.
    I have the 4870 X 2 and no 3d support on Jaunty Jackalope. I tried installing the Catalyst 9.4 and when I reboot my machine it locks up and the colors are all messed up.
    A few people have reported problems with the X2 boards and Jaunty, although they didn't show up in our "early look" testing on server 1.6. Did you see the same problems with Intrepid ? If not, it might be worth staying on 8.10 until we finish QA testing & bug fixing on Jaunty, and announce support in the release notes.
    Last edited by bridgman; 14 May 2009, 12:03 AM.

    Leave a comment:


  • highlandsun
    replied
    Originally posted by bridgman View Post
    Most of the real discussion was a few years ago, but the key point is that there were some real serious problems with the current architecture (possibly worse than the ones you were dealing with) which had to be addressed.

    The main problems were :

    - multiple graphics drivers, some in user space, and some in the kernel, over-writing each others settings during common use cases

    - inability to share memory between 2D and 3D drivers, which made any kind of desktop composition inefficient and slow

    Both the 2D and 3D drivers need context switches in order to access the hardware anyways, since the direct rendering architecture uses drm to arbitrate between the ddx and mesa drivers, and to manage the shared DMA buffers (aka ring buffer) used to feed commands and data into the graphics processors. I don't think these changes really introduce more context switches as much as change the dividing line between user and kernel responsibilities.

    I'm a bit rusty on the history (my hands-on X experience was before X11), but my understanding is that user modesetting is a relatively new addition to X, and that the KMS initiative is arguably going back to the way modesetting was handled in earlier versions of X which were presumably built on existing kernel drivers. I haven't had much luck finding online references to support this, but I have been told this by a number of people who have worked on X for a very long time.

    If you're saying that the DRI architecture is fundamentally flawed and that all graphics should go through a single userspace stack (presumably in the X server) then that's a different discussion of course.

    Jesse Barnes wrote a good summary of the rationale for moving modesetting into the kernel, and there is a good discussion (plus the odd rant ) in the subsequent comments : http://kerneltrap.org/node/8242

    Thomas's original TTM proposal is a pretty good summary of the goals related to memory management : http://www.tungstengraphics.com/mm.pdf
    Thanks, those references were pretty interesting.

    Yeah, I guess a lot of things were simpler on the Apollo workstations; they had no hardware text mode, they really only had one supported graphics mode per given machine configuration. The one wrinkle is that they already had their own native graphics/windowing system that was not related to X. There were two porting efforts going on, one to simply layer the X APIs on top of the native APIs, and one to drive the hardware directly. I think ultimately we had to accept the overhead and just layered on top of the Apollo APIs, to allow native apps to continue to run alongside X apps. Otherwise we would have had the same issues - multiple drivers talking to the same graphics hardware...

    As for DRI ... we obviously wouldn't need to fret over "redirected direct-rendering" if everything was going through the X server...

    Leave a comment:

Working...
X