Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 41

Thread: DirectX 10/11 Coming Atop Gallium3D

  1. #21
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote Originally Posted by curaga View Post
    Meh, at least we could play Microsoft and Embrace & Extinguish DX.
    We release DX12 that is improved in in every way compared to 11, while binding it to linux-only functionality for maximum advantage.

    ...Or not...
    Now, that thought brings a smile to my lips.

    And there's a perfectly suitable extension to D3D for this approach: quad buffer stereo. Maybe framelock extensions, too - there are developers who would positively kill to have those features in D3D. It is actually rumoured that QBS will be the next "big" feature for D3D12, but (a) that's a couple of years away and (b) there's a whole new market emerging here (new 120Hz HDTVs, 3d Bluray etc).

    The window of opportunity is here, any takers?

    (I'm only half-joking. Wouldn't it be awesome to beat Microsoft in their own game?)

  2. #22
    Join Date
    Oct 2008
    Posts
    6

    Default

    Quote Originally Posted by RealNC View Post
    I just have to laugh at the responses here. Who do you think you people are? Seriously. Your community (as in "Linux community", whatever that is to you, to me it's the money behind Novell and Red Hat coupled with a few lunatics) is irrelevant. When are you going to grasp that?
    Who is this guy? I've never heard of him, so none of his post matters to me.

    Really, though, only the rich deserve to express their opinions.

  3. #23
    Join Date
    Dec 2008
    Posts
    160

    Default

    Quote Originally Posted by BlackStar View Post
    quad buffer stereo.
    Ha - the first thing that came to mind was you mean 4 layers of buffering for Stereo sound on Linux... that would be a unique Linux feature that explains the lag in Skype with PulseAudio :-)

  4. #24
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by droidhacker View Post
    2) Waste resources in bad areas that could be used in more universally useful areas, like GPU-independent video decode acceleration.
    DXVA2 on linux.... that's one hell of an idea!

  5. #25
    Join Date
    Sep 2008
    Location
    Netherlands
    Posts
    510

    Default

    Quote Originally Posted by BlackStar View Post
    OpenGL drivers are so buggy it's not even funny anymore. Yes, that includes nvidia, too.
    I'm pretty sure driver developers are perfectly able to load the Direct3D state trackers with bugs too.

  6. #26
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote Originally Posted by Remco View Post
    I'm pretty sure driver developers are perfectly able to load the Direct3D state trackers with bugs too.
    Current D3D drivers are easily an order of magnitude more stable than OpenGL, not the least because they use a common HLSL compiler instead of 5 different ones.

    In fact, today I was debugging a GLSL shader that's interpreted differently by all three major vendors. With a tiny tweak, I can cause an access violation on Ati, a black screen on Nvidia and multicolored sparkly rendering on Intel (with current drivers). Three mutually incompatible interpretations of the same code - beat that!

    I dread to think what will happen if I add Mesa and OS X drivers into the mix...

  7. #27
    Join Date
    Sep 2008
    Location
    Netherlands
    Posts
    510

    Default

    Quote Originally Posted by BlackStar View Post
    Current D3D drivers are easily an order of magnitude more stable than OpenGL, not the least because they use a common HLSL compiler instead of 5 different ones.

    In fact, today I was debugging a GLSL shader that's interpreted differently by all three major vendors. With a tiny tweak, I can cause an access violation on Ati, a black screen on Nvidia and multicolored sparkly rendering on Intel (with current drivers). Three mutually incompatible interpretations of the same code - beat that!

    I dread to think what will happen if I add Mesa and OS X drivers into the mix...
    The nice thing about Mesa is that it will be used for all open source drivers. If it renders a particular shader instruction as a multicolored sparkly screen, at least it will do so across the board.

  8. #28
    Join Date
    May 2007
    Posts
    319

    Default no source for DX state trackers

    VMware won't be releasing any source for DX* state trackers.

    Zack was talking about the Gallium core getting support for DX10/11 *features* so they could build a DX10/11 state track on top of them.

  9. #29
    Join Date
    Mar 2009
    Posts
    86

    Default

    This is silly. New applications should use OpenGL, and Wine can use the DX interoperability features of OpenGL 3.2 (vertex_array_bgra, provoking_vertex, etc.). This is just wasted effort that would be better spent on OpenGL 3 support.

  10. #30
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by md1032 View Post
    This is silly. New applications should use OpenGL, and Wine can use the DX interoperability features of OpenGL 3.2 (vertex_array_bgra, provoking_vertex, etc.). This is just wasted effort that would be better spent on OpenGL 3 support.
    Only if you no clue about what GL3 and 3.2 are. They are mainly GL implementations of DX10/11 bits.

    And since VMware need to write DX10/11 state tracker anyway for their OS drivers I guess its not a wasted effort for them.

    Dave.

Posting Permissions

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