pouët.net

OpenGL 3.0

category: general [glöplog]
looking back, is there a professional game developer (here in the forum/scene) who prefers opengl?
added on the 2009-02-06 15:54:10 by Gargaj Gargaj
yep, but your sucky d3d still has to do a R3 to R0 switch everytime d3d9.dll calls your ICD.
added on the 2009-02-06 15:54:35 by nystep nystep
nothing wrong about "verifying", good practice to place a few of those every here and there.
added on the 2009-02-06 15:54:52 by superplek superplek
Not a complete workaround of course, but a good way to fight the "fix syntax error, relaunch application, see the gl black screen of death, read shader error messages, go back to code" loop, is to have dynamic reloading of shader code. You can edit your shader in vstudio and safe it to disk as usual, while the application is continuously monitoring that file, and upon detection of a change it tries to compile and link the new shader. If success, it repalces the old shader with the new one, of course. This way you can fix all your shader without relaunching the app in each bugfixing iteration.

I would die for a dx-kind of shader framework, but since the gl guys are not going to give up in their 'vision', this method does at least help me a bit to concentrate in real development.
added on the 2009-02-06 15:54:59 by iq iq
this was for rob of course.


tactlesstroll, that's exactly what I do and exactly what I want to avoid at all cost.

added on the 2009-02-06 15:56:35 by iq iq
this was for rob of course.


tactlesstroll, that's exactly what I do and exactly what I want to avoid at all cost.

added on the 2009-02-06 15:56:35 by iq iq
Quote:
yep, but your sucky d3d still has to do a R3 to R0 switch everytime d3d9.dll calls your ICD.


i dont think this even needs to be dignified with an answer :)

iq: making your own shader framework is perfectly common and good practice i'd say. regardless of api.
added on the 2009-02-06 15:59:30 by superplek superplek
iq: You'll most likely end up doing the same thing in DX9, but a bit less in DX10 (since less functions can fail).
added on the 2009-02-06 16:01:46 by kusma kusma
Quote:
i dont think this even needs to be dignified with an answer :)


haha, i hit where it hurts isn't it? ;)
added on the 2009-02-06 16:02:27 by nystep nystep
nystep: No, you hit him where you have no point. OpenGL needs just as much as D3D to go through the kernel to go to the hardware.

iq: I believe you meant Plek, right?
added on the 2009-02-06 16:04:48 by kusma kusma
no, you're just making yourself look incredibly bad by pointing out either things that aren't really benificial, simply aren't true or are identical for both apis on a certain level.

i'd sit back and revise my knowledge if i were you.
added on the 2009-02-06 16:04:54 by superplek superplek
I disagree, your driver can just put commands in a queue while remaining in R3 mode.. then a thread in R0 pulls them out..
added on the 2009-02-06 16:05:51 by nystep nystep
and the granularity of said process is for each driver and vendor to decide, and thus not directly related to the api it's implementing.

are you done now?
added on the 2009-02-06 16:07:57 by superplek superplek
mmmm, k, i have to concede that nowadays under vista it's pretty much the same. reference. but it's because nasty m$ copied the good stuff from gl! it didn't use to be always like this! i'd like especially to find an equivalent schema for windows xp driver model..
added on the 2009-02-06 16:16:31 by nystep nystep
btw -- i can see how i'm not really helping this thread :) i figure it's supposed to be a opengl 3.0 discussion thread -- not a "d3d vs ogl" thing, even though that's not really what is happening here (untrue statements need to be rectified).

so, back to the ogl 3.0 talk ppl :)
added on the 2009-02-06 16:16:43 by superplek superplek
Quote:
everyone must have forgotten that the Playstation 3 using OpenGL (ES) as its rendering engine which is a subset of OpenGL with different calls solely for the console. i think that makes it more than viable in todays market.


Cws : I don't want to break your illusions but most (serious) PS3 game developpers actually don't use it, sorry :)

As for Gimp, I don't know a single artist in our studio who would trade Photoshop for it. Gimp is nice for coders and small homemade projects but that's about it.
added on the 2009-02-06 16:22:15 by keops keops
(my message was for Guardian...sorry)
added on the 2009-02-06 16:22:22 by iq iq
i thought there were workarounds to precompile the shaders
And sorry for kusma and Plek, but there you go to the Clue Page.

Quote:
A more substantive and modern performance difference arises because of the structure of the hardware drivers provided by hardware developers. Under DirectX, IHV drivers are kernel-mode drivers installed into the operating system. The user-mode portion of the API is handled by the DirectX runtime provided by Microsoft. Under OpenGL however, the IHV driver is broken into two parts: a user-mode portion that implements the OpenGL API, and a kernel-mode driver that is called by the user-mode portion.
added on the 2009-02-06 16:28:50 by nystep nystep
Quote:
Because Direct3D IHV drivers are kernel-mode, and the user-mode code is out of the IHV’s hand, there is no chance for such optimizations to occur. Because the Direct3D runtime, the user-mode portion that implements the API, cannot have explicit knowledge of the driver’s inner workings, it cannot effectively support marshalling. This means that every D3D call that sends commands to the hardware must perform a kernel-mode switch. This has led to a number of behaviors with regard to using D3D, the most important being the need for submitting large batches of triangles in one function call.[7]

Since OpenGL’s IHV drivers have a user-mode component to them, IHVs have the ability to implement marshalling, thus improving performance. There is still kernel-mode switching, but the theoretical maximum number of switches under OpenGL implementations is simply equal to the Direct3D standard behavior.
added on the 2009-02-06 16:32:32 by nystep nystep
dude, you just cited Wikipedia
added on the 2009-02-06 16:33:59 by Gargaj Gargaj
But i reckon my mistake, under windows vista now, direct3d can be as fast as opengl.
added on the 2009-02-06 16:42:13 by nystep nystep
that wikipedia citation is a bit off in how it concludes on the potential difference in performance.

it is true that the d3d9 runtime handles the internal batching system itself (influenced by if you use a pure device or not) instead of letting vendors play a role in deciding on what to batch and what to whack through to the hardware driver directly.

this however does not mean that given any use case the theoretical performance of opengl will equal that of direct3d9. do not forget that hardware drivers are implemented with intimate knowledge of what is happening above them, and this pattern is consistent for each and every one of them (and the time spent on this mechanism, also regarding how it interacts with the os itself, is also of significance). true, for certain exotic hardware it might've been beneficial to have usermode control, but on the other hand one of the major vendors' (nv) gpus commandbuffer innards quite closely reflect the d3d call api. you can see why this is beneficial for them in turn.

there is no clear winner, performance-wise. there never was, and there isn't now. everything depends on context and situation.

added on the 2009-02-06 17:04:33 by superplek superplek
well, bla, bla..
Hopefully OpenGL 3.0 will bring something nice into the world.
As always, competitions is good, without OGL DX might have been left at Dx3 level.. what a joy, right?
added on the 2009-02-06 17:10:44 by gnilk gnilk
don't you mean DX6?
added on the 2009-02-06 17:37:47 by xernobyl xernobyl

login