Page 27 of 29 FirstFirst ... 172526272829 LastLast
Results 261 to 270 of 290

Thread: r6xx 3D games

  1. #261
    Join Date
    Dec 2007
    Posts
    2,359

    Default

    Quote Originally Posted by Melcar View Post
    Too bad enabling KMS causes Firefox scrolling to be choppy. I just can't do without DRI2 anymore, so it's back to fglrx for now.
    Try disabling smooth scrolling in FF. Also, if you are using an older xf86-video-ati, try git master. Command batching support for r6xx+ EXA/Xv was added around the end of November and improves 2D performance significantly.

  2. #262
    Join Date
    Dec 2008
    Posts
    57

    Default

    Now i get OpenGL 2.0 as well. Great!
    But KMS won't work for me. I can turn it on (with radeon.modeset=1), but then i can't use compiz. If i try to turn it on, my screen gets totaly white. dmesg says kms is enabled. It tried it out with my Ubuntu karmic + xorg-edgers ppa + 2.6.32-4 kernel on an ATI Radeon HD 2600.

  3. #263
    Join Date
    Dec 2007
    Posts
    2,359

    Default

    Quote Originally Posted by Boerkel View Post
    Now i get OpenGL 2.0 as well. Great!
    But KMS won't work for me. I can turn it on (with radeon.modeset=1), but then i can't use compiz. If i try to turn it on, my screen gets totaly white. dmesg says kms is enabled. It tried it out with my Ubuntu karmic + xorg-edgers ppa + 2.6.32-4 kernel on an ATI Radeon HD 2600.
    Make sure your r600 mesa driver is built with kms support. Also, make sure compiz is using an indirect context. Try running:
    LIBGL_ALWAYS_INDIRECT=1 compiz

  4. #264
    Join Date
    Apr 2008
    Location
    A Coruņa (Spain)
    Posts
    100

    Default

    After recent updates Darwinia is very playable (good framerate, only minor artifacts) and Doom 3, although with heavy shadow artifacts, has a decent framerate (30fps average in timedemo demo1).

    This is with RV670, kernel 2.6.33-rc5 and git libdrm, mesa and drivers. Great work, devs

  5. #265
    Join Date
    Feb 2009
    Location
    Poland
    Posts
    72

    Default

    I have to say that CS 1.6 is working quite well (some shadow glitches, but on specific maps only), but not with decent framerate... It sometimes drops to 5-10 FPS and is totally unplayable. I have to note that using fglrx it didn't drop that much (maybe sometimes to 30-40). I'm using RV670, everything connected to graphics from git and 2.6.33-rc4 kernel (KMS enabled). With UMS it's still painfully slow. Is there any way to change this situation? Will Gallium driver solve this issue?

  6. #266
    Join Date
    Jul 2009
    Posts
    416

    Default

    Quote Originally Posted by Wielkie G View Post
    I have to say that CS 1.6 is working quite well (some shadow glitches, but on specific maps only), but not with decent framerate... It sometimes drops to 5-10 FPS and is totally unplayable. I have to note that using fglrx it didn't drop that much (maybe sometimes to 30-40). I'm using RV670, everything connected to graphics from git and 2.6.33-rc4 kernel (KMS enabled). With UMS it's still painfully slow. Is there any way to change this situation? Will Gallium driver solve this issue?
    I believe Gallium will only work with KMS. But by the time the Gallium driver is usable, using KMS will be painless. Like where the Intel driver is now.

  7. #267
    Join Date
    Feb 2009
    Location
    Poland
    Posts
    72

    Default

    You didn't understand me UMS is as slow as KMS - there is no performance difference between them in my case.

  8. #268
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    FWIW I read your previous post the same way as pvtcupcakes, ie that KMS was slow in places but that UMS was worse

    Unless one of the devs is familiar with exactly what the app is doing when framerates are low it's going to be hard to do more than guess about what development work is most likely to make a difference. Right now the focus is still more on making the apps run in the first place and accelerating commonly used functions than doing any specific optimization work.

    What is the app doing when it gets slow, ie large amounts of detail, specific effects etc ?

  9. #269
    Join Date
    Feb 2009
    Location
    Poland
    Posts
    72

    Default

    It's Half-Life based game (GoldSource engine), it's very simple and derived from Quake engine. FPS is low when I look at many triangles (for example it's a bit higher when I look on the floor). It may be connected to unoptimized CPU->GPU transfers. AFAIK this engine batches all triangles on every frame, so more triangles -> lower performance because of this bottle-neck. This was for sure the case for fglrx, but mesa could have introduced another bottle-necks. Also note that I play this game through wine (but still OpenGL). I'll try to start the game from console to find some interesting wine messages (if any).

    Edit: Nothing much interesting in console, only this (may be produced by mesa):
    Code:
    warning: Unknown nb_ctl request:  4
    repeated few times.
    Last edited by Wielkie G; 01-24-2010 at 04:20 PM.

  10. #270
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by bridgman View Post
    FWIW I read your previous post the same way as pvtcupcakes, ie that KMS was slow in places but that UMS was worse

    Unless one of the devs is familiar with exactly what the app is doing when framerates are low it's going to be hard to do more than guess about what development work is most likely to make a difference.
    Which is why some company interested in graphics should fund getting better OpenGL debug tools. I'm about ready to just give up entirely on OpenGL/Linux after seeing the DirectX tools like PIX and NVperfHud. I can't even put into words the difference they make; it's like taking regular programming from working in raw machine code to writing everything in plain English, and that's not an exaggeration.

    Not only can you trace and profile every last bit of the entire graphics pipeline from your app down into the hardware execution of the shaders for any given pixel, you can play back frames and step through execution, you can get hotspots in your API usage, and the tools can give you errors that pretty much say "this thing right here is what's wrong with your performance, and here's how to fix it."

    As a driver developer, the ability to see the call graphs through the API down to the hardware execution of shaders would help you identify hotspots and performance issues in the drivers without needing to look at the app's source at all. Even if you don't own the app, it would make it possible for users to submit logs with the profiling results.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •