Beginner OpenGL vs DirectX
category: code [glöplog]
Slummy was resposible for allowing glCullFace(GL_FRONT_AND_BACK)
Quote:
obviously targeting a fixed environment like a mobile device is going to give a much more consistent result that trying to target GL under Windows where driver quality (stability/consistency/compatibility) can still be an issue.
Android has the same problem as Windows does, where there's all kinds of hardware with all sorts of drivers from all sorts of vendors.
GL has "Blast processing" DX has "Bit rot" lol
Scali: good thing Android isn't a popular mobile operating system with no devices, no variations and no software that uses OpenGL then. Oh, right..
On the android side.. is it actually that bad? (I still do 100% iOS dev, android hasn't caught up enough to be worth the pain still :)
I'm thinking that the "trouble devices" are hopefully the low cost crap. And the low cost crap tends to get used 90% of the time as a feature phone, not a smart phone... so they're not worth supporting. Do the higher-end devices (galaxy s*, htc etc.) have decent implementations?
I'm thinking that the "trouble devices" are hopefully the low cost crap. And the low cost crap tends to get used 90% of the time as a feature phone, not a smart phone... so they're not worth supporting. Do the higher-end devices (galaxy s*, htc etc.) have decent implementations?
Considering how the popular mobile games are mostly 2D sprite based affairs, I doubt mobile shader support is an important aspect.
True.. things like the Ouya are starting to bring these low class android devices into homes i'm sure others will try too.
Will the first console to directly support GL be the Steambox?
the little i know about android tells me there is a profile for apps, so targeting isn't as haphazard as it is for windows. (hardware is blocked at the app marketplace level)
personally, I didn't even count android as a viable platform for me,as mostly as i want to code in C for whatever i'm doing. GL support from C++ is a fairly recent addition.
Will the first console to directly support GL be the Steambox?
Quote:
Scali: good thing Android isn't a popular mobile operating system with no devices, no variations and no software that uses OpenGL then. Oh, right..
the little i know about android tells me there is a profile for apps, so targeting isn't as haphazard as it is for windows. (hardware is blocked at the app marketplace level)
personally, I didn't even count android as a viable platform for me,as mostly as i want to code in C for whatever i'm doing. GL support from C++ is a fairly recent addition.
Quote:
the little i know about android tells me there is a profile for apps, so targeting isn't as haphazard as it is for windows. (hardware is blocked at the app marketplace level)
You still have the problem of all these different OpenGL implementations, which have not been validated by anyone.
And then there's the problem that Android just doesn't receive updates. So you're pretty much stuck with the OpenGL drivers that your phone shipped with (or whatever is in an updated image, if you ever get one).
Even when there are newer/bugfixed versions of OpenGL drivers available for your phone's GPU.
That's the biggest difference between D3D and OpenGL. Firstly, D3D has a common runtime, supplied by Microsoft, so the drivers only implement a minimal subset of commands, and don't have to supply a complete HLSL compiler and that sort of thing.
Secondly, Microsoft actually has a WHQL test suite for these D3D drivers, so in general drivers just do what they're expected to do.
The Gallium3D project tries to do the same for OpenGL, but it hasn't quite caught on yet... Also shows the problem that this approach just takes a bit more abstraction overhead... Gallium3D drivers just aren't as fast as regular OpenGL ones. In D3D this overhead has already been absorbed ages ago. Not sure if the OpenGL world will ever want to take a step back performance-wise, to get the benefits of Gallium3D.
Quote:
You still have the problem of all these different OpenGL implementations, which have not been validated by anyone.
Wrong.
Quote:
And then there's the problem that Android just doesn't receive updates.
Also wrong.
Okay, then how can I update the video drivers on my Samsung Galaxy S Plus?
If I use an unofficial CyanogenMod port, there are newer drivers available... But I can't get them on the stock 2.3.6 image.
Also, who validates the OpenGL implementations, and how?
If I use an unofficial CyanogenMod port, there are newer drivers available... But I can't get them on the stock 2.3.6 image.
Also, who validates the OpenGL implementations, and how?
Quote:
Quote:the little i know about android tells me there is a profile for apps, so targeting isn't as haphazard as it is for windows. (hardware is blocked at the app marketplace level)
You still have the problem of all these different OpenGL implementations, which have not been validated by anyone.
I've read some stuff related to the Raspberry Pi about the implementation being tested. I'm pretty sure something that GL being a standard has at least a baseline of testing. Its a very common process to get those "ticks" and "logos" for release to go through this kind of testing.
So while gloom is correct that this is not a situation where zero testing happens, I also believe is is possible for deeper bugs/quirks to get through it, it shouldn't matter for the most part.
People manage to get games onto Android, usually they target iOS first as its the bigger market.
Where I work we make stuff for business use. Outside our desktop stuff we make apps for iOS and Blackberry only. We've never even had a Android sales enquiry, and Windows RT doesn't seem commercially viable either.
Quote:
Secondly, Microsoft actually has a WHQL test suite for these D3D drivers, so in general drivers just do what they're expected to do.
True. Whilst not in the gfx field, I've handled the WHQL process for several hardware devices.
Great thing is, their test suite put all the work on the client side before submission. So I could find and fix bugs on our time. I can only assume each iteration has continued to improve since I stopped working with hardware. Hell in the early days I even had to post the physical hardware from the UK to M$, the last round I did they were using encrypted logs so you don't have to!
Honestly, I think the problems on Android aren't as bad because of the filtering I mentioned (for example IIRC there is a 'tegra' flag) will stop people being able to download apps their device doesn't support, where under windows, you get an error..
Also the GL chipset manfacturers (powervr/nvidia) will be supplying a well tested implementation to multiple partners leading to a more stable platform.
I think as upper end android devices + low cost linux pc type devices start plugging into TVs and have a bit of horsepower they'll be good targets to "wow" people with demowise.
Quote:
So while gloom is correct that this is not a situation where zero testing happens, I also believe is is possible for deeper bugs/quirks to get through it, it shouldn't matter for the most part.
Well, as I already said, I had code that worked in the Android emulator (which itself was a port of working iOS code), but not on an actual phone. So in my experience it's very easy to run into OpenGL bugs, so clearly not enough testing has been done.
Quote:
Honestly, I think the problems on Android aren't as bad because of the filtering I mentioned (for example IIRC there is a 'tegra' flag) will stop people being able to download apps their device doesn't support, where under windows, you get an error..
I don't think that's quite the same thing :P
As a developer, you want your stuff to work... It's not a solution to only flag the binaries for the known working chips, and block it for all people with untested/incompatible hardware.
Quote:
Also the GL chipset manfacturers (powervr/nvidia) will be supplying a well tested implementation to multiple partners leading to a more stable platform.
That is wishful thinking. It never worked on Windows, OS X or linux, so I don't see why it would work for Android.
point taken on the first two, i'm just glad i'm not currently going anywhere near Android :)
I've got differences between simulator and iOS during development too... so its not just an Android.. (non-gl)
Because there is an extra layer between the producer and the user, they supply the people implementing it so have much bigger relationship to lose.. if their bug taints an entire line thats one thing, ruining one end users day is another..
I've got differences between simulator and iOS during development too... so its not just an Android.. (non-gl)
Quote:
Quote:Also the GL chipset manfacturers (powervr/nvidia) will be supplying a well tested implementation to multiple partners leading to a more stable platform.
That is wishful thinking. It never worked on Windows, OS X or linux, so I don't see why it would work for Android.
Because there is an extra layer between the producer and the user, they supply the people implementing it so have much bigger relationship to lose.. if their bug taints an entire line thats one thing, ruining one end users day is another..
Quote:
Because there is an extra layer between the producer and the user, they supply the people implementing it so have much bigger relationship to lose.. if their bug taints an entire line thats one thing, ruining one end users day is another..
Not sure I get what you mean here.
Isn't this exactly the same as with regular PCs? Apple, Dell, Acer, etc all just buy videochips from nVidia/AMD/Intel/whoever, who will also supply the drivers.
If the drivers have issues, then entire product lines suffer from these bugs.
But at least on Windows/OS X/linux, it is relatively easy to push out driver updates. On Android, I don't think there is such a thing as driver updates at all. I have only seen entire OS images being distributed. But this is rare. Most Android phones will only see 1 or 2 updates in their lifetime at best. Phones are seen as disposable items, and as such, so is the software on them. Not a lot of effort is put into maintaining software once it is released.
Quote:
Khronos has the CTS (conformance test suite), and most vendors have extensive internal tests. In addition to this, DrawElement has dEQP, and there's the open source Piglit.
But who actually tests the drivers? And how can I tell?
I mean, with D3D drivers, I know that they have passed validation when they are WHQL'ed. But how can I tell with OpenGL?
Also, are these tests good enough? I recall when Rage came out, my Radeon 5770 just crashed on it. I had to go through 3 'hotfix' drivers from AMD before the game finally worked. I am puzzled how this ever could have happened. Firstly, why does Bethesda release a game that obviously does not work on Radeons with official drivers. Clearly they did not test the game either... Secondly, apparently these drivers implemented functionality that was never really tested until Rage came out, and was so poorly implemented that it just crashed.
On my nVidia card, the game worked out-of-the-box with drivers that hadn't been updated in months, so much older than the drivers for my Radeon at the time (the game did not use any spectacular new OpenGL features anyway).
Scali:
The CTS is run by the vendors, but logs and needed patches are submitted so the results can be reproduced by other Khronos members. The results are not public, but you can tell by seeing if the vendor uses the OpenGL trademark. Read more here if you want: http://www.khronos.org/files/conformance_procedures.pdf
As for good-enough or not, that's a matter of opinion so I won't go into it much. The OpenGL CTS was pretty much non-existent for a lot of years, but after Khronos took over the OpenGL working group, things have progressed a lot.
So yeah, that whole "have not been validated by anyone"-statement is pretty far from the truth. I'm sure you'll try to argue that somehow the CTS doesn't count, and you somehow was right, but whatever. I also don't really care about your Rage/Android-butthurts, it's difficult and probably pointless to find out what the reason for those was. These might not even be OpenGL (ES) bugs for all I know; the standards allow for some variation in implementation. If you diagnosed it and they were indeed driver-bugs, report them to the vendors and they'll usually be fixed by the next driver-version. Or maybe they'll tell you how to work around the bug if you're stuck with an old version.
The CTS is run by the vendors, but logs and needed patches are submitted so the results can be reproduced by other Khronos members. The results are not public, but you can tell by seeing if the vendor uses the OpenGL trademark. Read more here if you want: http://www.khronos.org/files/conformance_procedures.pdf
As for good-enough or not, that's a matter of opinion so I won't go into it much. The OpenGL CTS was pretty much non-existent for a lot of years, but after Khronos took over the OpenGL working group, things have progressed a lot.
So yeah, that whole "have not been validated by anyone"-statement is pretty far from the truth. I'm sure you'll try to argue that somehow the CTS doesn't count, and you somehow was right, but whatever. I also don't really care about your Rage/Android-butthurts, it's difficult and probably pointless to find out what the reason for those was. These might not even be OpenGL (ES) bugs for all I know; the standards allow for some variation in implementation. If you diagnosed it and they were indeed driver-bugs, report them to the vendors and they'll usually be fixed by the next driver-version. Or maybe they'll tell you how to work around the bug if you're stuck with an old version.
Quote:
results are not public, but you can tell by seeing if the vendor uses the OpenGL trademark.
So basically you can't.
The vendor uses the OpenGL trademark if they have at some point in time validated some combination of hardware and software for some version of OpenGL.
Which makes the OpenGL trademark pretty useless, it's used by all major vendors on their website, product pages, spec sheets etc.
This is completely different from the WHQL where the ACTUAL drivers are SIGNED to indicate that these drivers have been tested.
Quote:
I'm sure you'll try to argue that somehow the CTS doesn't count, and you somehow was right, but whatever. I also don't really care about your Rage/Android-butthurts, it's difficult and probably pointless to find out what the reason for those was.
It is this exact pathetic attitude why 'technologies' (I use the term loosely) such as OpenGL and linux will never amount to anything.
It is impossible to have any kind of criticism on the product, no matter how just this criticism may be, because the 'people' (I use the term loosely) involved are a bunch of immature and incompetent crybabies, who can't handle any kind of criticism. If you don't even admit there is a problem in the first place, you will obviously never solve said problem.
Quote:
If you diagnosed it and they were indeed driver-bugs, report them to the vendors and they'll usually be fixed by the next driver-version.
Which would bring us to the next problem: How do you ever get those drivers to the end-users when phones don't receive updates?
Again, you're making false claims as if they were facts in a desperate attempt to validate your previous obvious false claim. I'm sorry, but I have better things to do with my time than arguing with trolls.
Scali: your language is way much beyond the level of aggression for me to be interested in taking part in this conversation. Pity, since I represent the company I work for at Khronos OpenGL ES WG
On second read, strike "Again, " from my message. I haven't seen Scali doing that exact thing before, this was cruft from me re-editing my post right before posting. Sorry about that.
Quote:
Scali: your language is way much beyond the level of aggression for me to be interested in taking part in this conversation.
Blame the OpenGL-crowd. Initially I was just trying to help, but these people keep fighting everything you say, so you don't feel like being calm and friendly anymore. Problem is they've been doing the exact same thing since 1992, so I don't have the patience to deal with it anymore.
Quote:
you're making false claims as if they were facts in a desperate attempt to validate your previous obvious false claim. I'm sorry, but I have better things to do with my time than arguing with trolls.
If you think I'm trolling, you have issues.
Anyway, it's not like I care enough about OpenGL to continue this 'debate'. You have actually validated my claims anyway, since you're clearly not interested in taking the issues I brought up seriously. They are obviously NOT false claims. You KNOW OpenGL suffers from the various issues I mentioned. You're just desperately trying to wiggle your way out of it by trying to look for 'technicalities' in the way I present these issues.
Well, whatever. Clearly this is not the API for beginners.
Reminds me of this blog I read a while ago... by some 'game developer', the amount of lies, misinformation, bias, and pathetic claims was just mindboggling:
http://scalibq.wordpress.com/2010/04/01/why-you-should-use-opengl-and-not-directx-%e2%80%93-an-analysis/
http://scalibq.wordpress.com/2010/04/01/why-you-should-use-opengl-and-not-directx-%e2%80%93-an-analysis/