Page 2 of 15 FirstFirst 123412 ... LastLast
Results 11 to 20 of 146

Thread: Grand Theft Auto Running On Direct3D Natively On Linux Shows Gallium3D Potential

  1. #11
    Join Date
    Nov 2010
    Posts
    391

    Default

    Quote Originally Posted by Atirage21 View Post
    This solution is not good for professional graphic card by games. Now i have any problem with games under linux, because on quadro i have good performance, but by directx this is catastrophe. Please dont making from this default solution for wine. Thank you !
    What's wrong with you? Wine's solution is to dump more overhead on the CPU to keep the GPU from waiting. That's what the big feature is with CSMT. The weaker the CPU and more powerful the GPU, the more of a problem this will become. This is a great move on Linux to get faster Windows games running. Who cares if it only runs on Linux and requires open source drivers. Do Windows games run 3x faster with DX9 state tracker? Yes? Then I'll be exclusively using open source drivers.

    Think of the poor mac users and binary drivers users.
    Good news cause Linux has a limited unlimited sale of free. Open source drivers also have the same sale.

  2. #12
    Join Date
    Sep 2013
    Posts
    220

    Default

    Quote Originally Posted by rikkinho View Post
    we need native games not this even less dx
    This will not affect native games at all because blobs not going to support anything like that ever.

  3. #13
    Join Date
    Jan 2014
    Posts
    11

    Default

    Quote Originally Posted by _SXX_ View Post
    This will not affect native games at all because blobs not going to support anything like that ever.
    Of course, this solution is just like WINE, a way of running older Windows software on Linux. Nobody in their right mind will support a Linux game using this when they have the option of recompiling from scratch.

  4. #14
    Join Date
    Jun 2014
    Posts
    14

    Default

    Quote Originally Posted by justmy2cents View Post
    color me blind, but isn't https://github.com/iXit/Mesa-3D where d3d9 (or direct link https://github.com/iXit/Mesa-3D/tree..._trackers/nine ) is happening? last change here was 5 days ago. git repository that was posted was abandoned

    i'm not interested personally in d3d9 at least until it requires whole Mesa recompile
    That's a fork, the original is @ https://github.com/chrisbmr/Mesa-3D/..._trackers/nine

  5. #15
    Join Date
    Apr 2011
    Posts
    330

    Default

    Quote Originally Posted by Dukenukemx View Post
    What's wrong with you? Wine's solution is to dump more overhead on the CPU to keep the GPU from waiting. That's what the big feature is with CSMT. The weaker the CPU and more powerful the GPU, the more of a problem this will become. This is a great move on Linux to get faster Windows games running. Who cares if it only runs on Linux and requires open source drivers. Do Windows games run 3x faster with DX9 state tracker? Yes? Then I'll be exclusively using open source drivers.

    Think of the poor mac users and binary drivers users.
    Good news cause Linux has a limited unlimited sale of free. Open source drivers also have the same sale.


    The reason that PC users are stack with MS, regardless if free software is superior in quality and safety and free knowledge, is because the majority of PC games (art) are based on D3D (MS exclusive). The overhead is there on purpose of making our lives hard and no other technical reasons (as they say), and they have formed a Cartel with non legal deals. If you phoronix people, you where ATI or Nvidia you would support another company's standard? I would have my own. But MS gave them monopoly, and they gave monopoly to MS and Intel. You will not find your favorite games (art) in OpenGL, never, not because OGL is bad, but because they have shares on many graphic engines companies (and games production companies) to secure the monopoly. They have shares to many CPU companies, so ARM will never give you native x86 speed via Qemu, like Loongshon MIPS does. They want you to have both a x86 and an ARM device. And an extra console that has an OGL renderer with the X game, wile the same X game on PC has only a D3D one. Do not expect anything from D3D emulation either. They don't want Linux to win with OGL, they want slow emulation, for them to gain profits. They don't want something thet lives outside their product either.

    The question is not what they will do, but what we will do. We must brake their monopoly with native D3D on Linux. Then Linux will go boom at 25%. Then and only then, they will support it without their will, with native OGL titles. Someone must do it, and we will help with our donations if needed.-
    Last edited by artivision; 07-28-2014 at 05:34 PM.

  6. #16
    Join Date
    Jul 2009
    Posts
    258

    Default

    Quote Originally Posted by somini View Post
    Of course, this solution is just like WINE, a way of running older Windows software on Linux. Nobody in their right mind will support a Linux game using this when they have the option of recompiling from scratch.
    As the great philosopher mick Jagger once said: You can't always get what you want... But you get what you need.

    Some things are not worth doing. like porting hundreds or thousands of old games to linux. but you can run them anyway. (meh!) DX9 will not affect new games being portedas they will probably be going for OGl 4.x anyway. So its a nice thing to have.
    And as long as the open drivers are at 20-50% of the hardware speed (taking closed drivers as a reference) game vendors will not give a single fsck about open drivers. They will eventually hope for their fast improvement for a number of reasons. But that might actually be another reason to push AMD to abandon catalyst. Which they wont for the next 5 years at least.

    Generally its a nice thing to have possibilities.

  7. #17
    Join Date
    Jun 2009
    Posts
    1,136

    Default

    Quote Originally Posted by jakubo View Post
    As the great philosopher mick Jagger once said: You can't always get what you want... But you get what you need.

    Some things are not worth doing. like porting hundreds or thousands of old games to linux. but you can run them anyway. (meh!) DX9 will not affect new games being portedas they will probably be going for OGl 4.x anyway. So its a nice thing to have.
    And as long as the open drivers are at 20-50% of the hardware speed (taking closed drivers as a reference) game vendors will not give a single fsck about open drivers. They will eventually hope for their fast improvement for a number of reasons. But that might actually be another reason to push AMD to abandon catalyst. Which they wont for the next 5 years at least.

    Generally its a nice thing to have possibilities.
    i agree a d3d9 state tracker only for wine and gallium drivers is quite nice idea to play legacy games while new games get ported natively to GL4

    mmm 20-50% ??? what hardware are you talking about(i guess don't reclockable nouveau card)??? my radeonsi card is pretty much 60-95% of fglrx(few glitches remain in some special shadows tho) depending the workload and the intel driver kick the be jesus out of apple intel's driver since long ago

  8. #18
    Join Date
    Sep 2012
    Posts
    26

    Default

    Quote Originally Posted by oneofone View Post
    yes, it's fork. Only maintained fork at this time, which work with latest Mesa-3D code. Because calim left his work, I keeping his work synced with upstream + sometimes making minor improvements.

  9. #19
    Join Date
    Jun 2009
    Posts
    1,136

    Default

    Quote Originally Posted by okias View Post
    yes, it's fork. Only maintained fork at this time, which work with latest Mesa-3D code. Because calim left his work, I keeping his work synced with upstream + sometimes making minor improvements.
    btw to compile with mesa git you need to rename PIPE_SHADER_CAP_MAX_CONSTS to PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE since commit 04f2c88f45e26d7050cc88aaaac8e8154d6018d0 break the compilation


  10. #20
    Join Date
    Sep 2012
    Posts
    26

    Default

    Quote Originally Posted by jrch2k8 View Post
    btw to compile with mesa git you need to rename PIPE_SHADER_CAP_MAX_CONSTS to PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE since commit 04f2c88f45e26d7050cc88aaaac8e8154d6018d0 break the compilation

    Thank you, missed that one after rebase Fixed.

Posting Permissions

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