• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Things that drive me nuts about OpenGL

Have steamos sat waiting to go on an ssd :)

The same as you though DM, haven't used Linux in many years (around 2007-2008) so looking forward to see how things have moved on, thank gawd we no longer have to manually edit x.org anymore though lol.

If ms go subscription based they can surely expect xp levels of piracy to make a return.
 
Why we can’t have nice things: Valve programmer discusses wretched state of OpenGL

Joel Hruska's take on the blog. :)

Let’s be clear — nobody “wins” this comparison. You’ve got one vendor deeply hostile to open source code and actively disinterested in contributing code that might help any other vendor, one vendor with good intentions, bad code, and limited resources, and one vendor for whom GL development is a strictly secondary interest. This explains in no small part why OpenGL continues to be so fragmented and erratic in the PC space — it’s extremely difficult for even a company with Valve’s resources to chase down three separate vendor drivers and integrate solutions that satisfy all three companies. Doing something that works on one Vendor’s hardware could easily break two others, which means implementing and testing three separate solutions.

The chances that this situation improves in the near term seem dim at best. One point that multiple commenters made on Geldereich’s blog is that if the desktop space is bad, the smartphone and tablet vendors are even worse. Meanwhile, one of the vendors discussed here has already launched its own new API, which likely reduces their interest in developing OpenGL support in parallel. That’s not automatically a bad thing, but it means fewer resources to devote to any single API — and the other vendors have obvious problems of their own.

Full Article
http://www.extremetech.com/gaming/1...programmer-discusses-wretched-state-of-opengl
 
Only time I use Linux really is on my Raspberry Pi and at university on the lab computers, not a huge fan of it to be quite honest and I wouldn't want to have many of the Linux distributions on my rig instead of Windows. For developing I like to use Visual Studio 2013 (best IDE out there in my opinion), the people who use Linux for developing are the nutters who like to do everything via the command line / console window :p

I won't be quick to dismiss a Windows subscription model as Office 365 is very good and a sub based Windows OS might actually work better in the long run - there would probably be more frequent updates and upgrading to the latest OS might be considerably reduced hassle. We'll see I guess, but I'm not moving from Windows any time soon for a large number of reasons :)
 
Have steamos sat waiting to go on an ssd :)

The same as you though DM, haven't used Linux in many years (around 2007-2008) so looking forward to see how things have moved on, thank gawd we no longer have to manually edit x.org anymore though lol.

If ms go subscription based they can surely expect xp levels of piracy to make a return.

Does SteamOS have TRIM enabled by default?
If so, what method does it use?
 
Couldn't say as its not installed yet, just making preparations for it, a little Google suggests it supports 2 types of trim ATM.

Also even though its listed as nvidia support only, the latest amd 14.4 driver has been added to the repo.
 
Why we can’t have nice things: Valve programmer discusses wretched state of OpenGL

Joel Hruska's take on the blog. :)



Full Article
http://www.extremetech.com/gaming/1...programmer-discusses-wretched-state-of-opengl

Let’s be clear — nobody “wins” this comparison. You’ve got one vendor deeply hostile to open source code and actively disinterested in contributing code that might help any other vendor
= Nvidia

one vendor with good intentions, bad code, and limited resources
= AMD

and one vendor for whom GL development is a strictly secondary interest
= Intel

This explains in no small part why OpenGL continues to be so fragmented and erratic in the PC space — it’s extremely difficult for even a company with Valve’s resources to chase down three separate vendor drivers and integrate solutions that satisfy all three companies. Doing something that works on one Vendor’s hardware could easily break two others, which means implementing and testing three separate solutions.

The chances that this situation improves in the near term seem dim at best

Valve need Nvidia and AMD to work together with them to make something of SteamOS.

Reading that article it almost looks like SteamOS is not really going to happen.

What a shame :(
 
Spot on.

People get too wrapped up on their choice of vendor but fail to see that a single player would be to the detriment of the PC enthusiast. No competition would result in lazy development. Drip fed on each new gen and max profit being the only goal.

As much as I favour nVidia, we still need there to be competition from AMD or even a 3rd player for a healthy market.

Sadly i think its too late and would require too much of a capital investment to see a third major gpu vender :(
I would like it to happen but just cant see it g
 
As the author:

(Of the ExtremeTech post, not the original blog post).

I don't think anyone should read the Valve story and conclude that SteamOS isn't happening. Certainly that's not what I take from it. Valve is committed to bringing SteamOS to market or it wouldn't have committed so many resources to the project (the fragmented state of OGL is hardly a state secret).

I believe this blog post is exactly what the author said it was -- a frustrated post by someone blowing off steam. That doesn't mean it isn't true -- one of the things that sets it apart is that very few people are willing to actually call out all of the involved parties quite so bluntly.

No one is giving up on OpenGL, but very few commenters are shouting that the OP is wrong, either. That suggests to me that his take on the general situation is fairly good and that there's a lot of pent-up frustration from developers that want to use OGL but find themselves stymied.

For those calling on developers to make the standard better, I'd like to offer the following:

1). Being a good programmer and attempting to develop an entirely new version of OpenGL is like the difference between a good mason and being a world-class architect and project leader. Any attempt to write a new OGL version or to handle the inevitable cat-herding that would have to happen at Khronos means more than just great programming skills -- it means a hell of a lot of people skills as well.

2). Most companies aren't going to pay you to go ride herd on the OpenGL working group. That means doing your programming work *and* attempting to improve OGL at the same time. That's not two jobs -- it's more like four.

3). Given the skyrocketing costs of game development and the plethora of platforms (Xbox 360, Xbox One, PS3, PS4, Android, iOS, PC, Wii U) it's not lazy for developers to go looking for the solutions that will let them do their jobs with a minimum of fuss. Whether you're a D3D, Mantle, OGL, or OGL ES fan, a programmer is looking for the toolset that lets them get their *game* built -- not necessarily looking to make a political or economic statement of solidarity with their API choice.
 
Just read through the thing again and notice this part in particular...

"Doing something that works on one Vendor’s hardware could easily break two others, which means implementing and testing three separate solutions."

I have expressed my concern regarding dx12 for couple of times, particularly regarding MS's ambitions for dx12 to support Xbox, mobile platform (mobile phones and tablets) and PC (laptops) at the same time. Correct me if I'm wrong, but ain't the three things mentioned about uses different OS and hardware? How is the it different to difficulty that OpenGL faces quoted above, considering it has the same issue of different hardware and vendors and try to support too many different things at the same time? Also, do we know if dx12 was written from scratch, or does it still carry (most of) 19 years worth of dx bloated code?
 
Last edited:
I think windows, xbone & windows phone all use the same kernel (back end) albeit modified to suit each device, the instruction sets should be near identical.
 
I think windows, xbone & windows phone all use the same kernel (back end) albeit modified to suit each device, the instruction sets should be near identical.
If that is the case, I honestly hope the kernel (or back end as you call it) put enough consideration on PC, rather than primarily for Xbox and mobiles device and then a make-shift for PC platform as afterthought...a mobile gaming device API with PC windows support bolted onto the end of it is the last thing we need...
 
Last edited:
Just read through the thing again and notice this part in particular...

"Doing something that works on one Vendor’s hardware could easily break two others, which means implementing and testing three separate solutions."

I have expressed my concern regarding dx12 for couple of times, particularly regarding MS's ambitions for dx12 to support Xbox, mobile platform (mobile phones and tablets) and PC (laptops) at the same time. Correct me if I'm wrong, but ain't the three things mentioned about uses different OS and hardware? How is the it different to difficulty that OpenGL faces quoted above, considering it has the same issue of different hardware and vendors and try to support too many different things at the same time? Also, do we know if dx12 was written from scratch, or does it still carry (most of) 19 years worth of dx bloated code?

This is an interesting point and is someting I wonder about Mantle too. In 5 years time will AMD still be nursing the same code base they're doing now or will they throw it away and start again?
 
This is an interesting point and is someting I wonder about Mantle too. In 5 years time will AMD still be nursing the same code base they're doing now or will they throw it away and start again?

Mantle will continue to be updated. They're aiming to keep improving it, making it able to perform more draw calls etc. I'm looking for the slides, but can't find it atm.
 
This is an interesting point and is someting I wonder about Mantle too. In 5 years time will AMD still be nursing the same code base they're doing now or will they throw it away and start again?
It's not even about Mantle (at least it's not something we'd have to concern ourselves with right now since it new and built from ground up at the moment)...OpenGL has already proves that sometimes it is much better to start from scratch than clinging onto the old and hoping to improve it. Similarly for Windows, if it's seen better days and with lots of corrupted registry etc...rather than wasting time and effort on trying to save the existing installation, it would be far simpler and more efficient to just reinstall the Windows from fresh.
 
Mantle will continue to be updated. They're aiming to keep improving it, making it able to perform more draw calls etc. I'm looking for the slides, but can't find it atm.

I'm sure that's what they thought about DirectX when they started too!

It's not even about Mantle (at least it's not something we'd have to concern ourselves with right now since it new and built from ground up at the moment)...OpenGL has already proves that sometimes it is much better to start from scratch than clinging onto the old and hoping to improve it. Similarly for Windows, if it's seen better days and with lots of corrupted registry etc...rather than wasting time and effort on trying to save the existing installation, it would be far simpler and more efficient to just reinstall the Windows from fresh.

Oh yeah, right now it's all new, but in 5 years if they keep it going it could start to suffer the same problems. Adding new stuff on top of old as they bring out each generation of cards. I mean there already seems to be a bit of a difference between the 290s and the re-badged 7000 series cards, what will it be like with another 5 generations?
Maybe it would be a good rule of thumb for everyone to just throw away their entire codebase every 5 years and start again.
In theory you have thought that the reason for going from DX 10 to 11 was so that you didn't have to support legacy stuff. Of course then you'd have to allow people to have multiple versions of DirectX so they could play older games, but at least then you make a fresh start each time.

Basically it's be nice if in 10 years time we're not sitting here remembering about when Mantle was efficient and stuff instead of the bloated mess of legacy support it's become. Although in fairness considering Mantle and FreeSync's lack of current support for 6000 series and below, legacy support doesn't seem to be something AMD are concerning themselves about! :)
 
I'm sure that's what they thought about DirectX when they started too!



Oh yeah, right now it's all new, but in 5 years if they keep it going it could start to suffer the same problems. Adding new stuff on top of old as they bring out each generation of cards. I mean there already seems to be a bit of a difference between the 290s and the re-badged 7000 series cards, what will it be like with another 5 generations?
Maybe it would be a good rule of thumb for everyone to just throw away their entire codebase every 5 years and start again.
In theory you have thought that the reason for going from DX 10 to 11 was so that you didn't have to support legacy stuff. Of course then you'd have to allow people to have multiple versions of DirectX so they could play older games, but at least then you make a fresh start each time.

Basically it's be nice if in 10 years time we're not sitting here remembering about when Mantle was efficient and stuff instead of the bloated mess of legacy support it's become. Although in fairness considering Mantle and FreeSync's lack of current support for 6000 series and below, legacy support doesn't seem to be something AMD are concerning themselves about! :)
The current dx whilst it works, its limitation is some areas is quite apparent and is far from as efficient as can be.

Why do you think Intel scrapped Pentium 4 and start over again with the Core2? Why do you think AMD is going to abandoning the FX series originated from Bulldozer and work toward a new architecture? It is the simple reason is because their options, performance increase and freedom would be limited if they insisting on hanging onto things that's not perform well enough.

With MS going to make dx12 an API for Xbox and mobiles as well, you honestly think it is a idea to build it on top of existing codes that already has limitations, struggling with just PC hardware alone?

Stop deflecting the subject and keep dragging Mantle into this saying "but Mantle is x years would have the same problem bah bah bah...". If that happen in x years time, we will worry about it then (if Mantle is still around that is...it might be gone by then who knows?). For now it's not something we have to concern about right now, but dx is.

Your comparison of Mantle vs dx is invalid anyway. Mantle is a API for PC and PC alone, but dx is going to be a API for multiple platforms. dx has always been just a PC API, but they are now moving into unknown territory with Xbox and mobiles being added to the equation as well. You honestly think it wouldn't be better for them design the dx12 from scratch than build it on top of existing dx blocks that has not been designed with support for anything but PC hardware in mind?

If MS is going to introduce a Tug of war situation for API performance between the Xbox, mobile and PC platform, at least they should give them more room or space to do it.
 
Last edited:
I'm sure that's what they thought about DirectX when they started too!



Oh yeah, right now it's all new, but in 5 years if they keep it going it could start to suffer the same problems. Adding new stuff on top of old as they bring out each generation of cards. I mean there already seems to be a bit of a difference between the 290s and the re-badged 7000 series cards, what will it be like with another 5 generations?
Maybe it would be a good rule of thumb for everyone to just throw away their entire codebase every 5 years and start again.
In theory you have thought that the reason for going from DX 10 to 11 was so that you didn't have to support legacy stuff. Of course then you'd have to allow people to have multiple versions of DirectX so they could play older games, but at least then you make a fresh start each time.

Basically it's be nice if in 10 years time we're not sitting here remembering about when Mantle was efficient and stuff instead of the bloated mess of legacy support it's become. Although in fairness considering Mantle and FreeSync's lack of current support for 6000 series and below, legacy support doesn't seem to be something AMD are concerning themselves about! :)

So we should all start worrying about that right now and do what exactly, nothing that's what.

Its the developers who have to worry and the changes we are seeing is because of the developers asking for change, if Mantle ends up being an inefficient mess in 5-10 years time if its still around the developers will do the same again.
No pain no gain!
 
Back
Top Bottom