If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
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 solution is MESA ... once it is used for all the platforms on Linux and up to date with latest OpenGL version, you'll just need one code path :-)
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.
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.
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.
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...
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 :-)
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.
Leave a comment: