AMD: It's Time To Open Up the GPU (gpuopen.com)

Translation:quit optimizing for Intel technology by xxxJonBoyxxx · 2016-01-26 09:05 · Score: 3, Insightful

>> AMD: It's Time To Open Up the GPU

Translation: quit optimizing for proprietary Intel technology, start developing and optimizing for AMD's proprietary technology, particularly LiquidVR, instead

call me when Intel signs up otherwise meh

Console games? by tlambert · 2016-01-26 09:05 · Score: 2, Funny

Console games? You mean like "robots" and "nethack", right? 'Cause you run them on the console, rather than in graphics mode?

Re:Console games? by Anonymous Coward · 2016-01-26 09:12 · Score: 1, Informative

XBox, Playstation, etc. You know, the gaming devices that are currently all using custom AIT cards. Oh, wait-- you were just trying to be clever.
Re:Console games? by MobileTatsu-NJG · 2016-01-26 09:33 · Score: 1

No no, 'console games' as in "games you want to play when you're finally bored with shooters".

--

"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Re:Console games? by Ungrounded+Lightning · 2016-01-26 09:40 · Score: 0

Console games? You mean like "robots" and "nethack", right? 'Cause you run them on the console, rather than in graphics mode?
Gaming console, not terminal-emulator-in-a-widow console.
I know you're probably trying to be funny. But some people may find your post confusing.

--
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Re:Console games? by aliquis · 2016-01-26 22:02 · Score: 1

No no, 'console games' as in "games you want to play when you're finally bored with shooters".
They make games you will never want to play?!

The GPU wars have only just begun by Anonymous Coward · 2016-01-26 09:07 · Score: 0

If PhysX and Hairworks being pushed by embedded developers (Nvidia offers to help make your AAA game at no cost to you!) wasn't a clue, we're getting dangerously close to seeing levels of vendor lock-in previously reserved for the consoles.

Uh, no... by __aaclcg7560 · 2016-01-26 09:09 · Score: 1

Hey, AMD, show us your new CPUs for 2016. Everything you got now is long in the tooth.

Re:Uh, no... by Austerity+Empowers · 2016-01-26 12:51 · Score: 1

long in the tooth.
But, but, the untapped potential!

w00t! by zapadnik · 2016-01-26 09:10 · Score: 3, Insightful

As an indie game developer this is fantastic news. I hope Apple also make good use of this, the Apple OpenGL drivers run at about half the speed of AMD's Windows OpenGL drivers on the same hardware (a recent Mac Pro with dual D700s under OS X and Bootcamp-ed to Windows).

Hopefully it also means that Open Source folks (FSM bless 'em) will also improve the install process for AMD/ATI drivers on Linux, if not the performance.

This is great news for those working in real time 3D.

Re: w00t! by IBME · 2016-01-26 09:34 · Score: 1

Ahh the possibilities! Nuff said. Haggling over who's who is for wankers.
Re:w00t! by Anonymous Coward · 2016-01-26 09:36 · Score: 0

It is aweful news. allowing optimisation by cards was what we had 20 years ago and it was a nightmare, it meant every piece of hardware and every new iteration of hardware would break games. We had the same problem with sound back in the day.
Re:w00t! by exomondo · 2016-01-26 10:26 · Score: 1

I hope Apple also make good use of this, the Apple OpenGL drivers run at about half the speed of AMD's Windows OpenGL drivers on the same hardware (a recent Mac Pro with dual D700s under OS X and Bootcamp-ed to Windows).
Apple have Metal, they aren't interested in OpenGL, hence the reason their drivers are so far behind.

This is great news for those working in real time 3D.
It's great if you're targeting a narrow hardware range because you can now optimize specifically for it but we've had this at the vendor level before (S3, 3Dfx, nVidia, ATi, PowerVR, Matrox, 3DLabs, etc.) and it was a nightmare. Even if the application supported your card that didn't mean it supported it particularly well, or as well as other cards. So picking a graphics card was less about how powerful the card was and more about how popular it was with developers.
Re:w00t! by zapadnik · 2016-01-26 11:22 · Score: 2

Thanks for posting. The interesting thing about the Metal framework is that it is a mixed bag of performance compared to OpenGL. In some areas there are performance benefits, but there are also losses.
http://arstechnica.com/apple/2...
Given the time required to build and maintain great products (the longer you keep something going, the more money you can make) I personally feel that "portability is THE killer feature". Hence I prefer OpenGL compared to Metal. Developing only for Apple is a losing proposition - especially for something as resource hungry as a modern jet combat simulation (which Apple has inferior hardware for anyway, sadly).

It's great if you're targeting a narrow hardware range because you can now optimize specifically for it but we've had this at the vendor level before (S3, 3Dfx, nVidia, ATi, PowerVR, Matrox, 3DLabs, etc.) and it was a nightmare. Even if the application supported your card that didn't mean it supported it particularly well, or as well as other cards. So picking a graphics card was less about how powerful the card was and more about how popular it was with developers.
The point of OpenGL is you *don't* do this. The point of Metal is you do (and you have to lots of work).
With AMD opening up the GPU it means the OpenGL driver writers can squeeze more performance out, without the application developer having to do the low-level work. This is the model I personally prefer.
Re:w00t! by exomondo · 2016-01-26 12:09 · Score: 1

I certainly do think Metal is a poor solution (being platform-specific, proprietary and not as comprehensive as Vulkan - based on knowledge of Mantle), especially when we have Khronos trying to unify the 3D graphics world and the lagging of OpenGL in comparison to Metal and DirectX will be addressed with Vulkan.

With AMD opening up the GPU it means the OpenGL driver writers can squeeze more performance out, without the application developer having to do the low-level work. This is the model I personally prefer.
The problem here is the OpenGL driver model, ultimately the real performance gains are around application-specific changes to the behavior of the driver - specifically resource management - so you end up with a monolithic driver that has a lot of application-specific code in it. Vulkan alleviates this by putting this in the hands of the application developer rather than having to rely on the driver.
Re:w00t! by zapadnik · 2016-01-26 13:01 · Score: 1

The problem here is the OpenGL driver model, ultimately the real performance gains are around application-specific changes to the behavior of the driver - specifically resource management - so you end up with a monolithic driver that has a lot of application-specific code in it. Vulkan alleviates this by putting this in the hands of the application developer rather than having to rely on the driver.
IMHO this is also a mistake. Having the application developer do driver-level resource management is a fail, IMHO. I like APIs that operate on two levels: one level is the low-level stuff, where you are required to make every decision (Vulkan); then you have another part of the *same* API that has convenience methods for very common things that nearly every application needs (as OpenGL does). Pushing more work to the application developer just so the driver developer can do less is a fail and will result in lower adoption. Isn't convenience and high adoption the goal?
Consider the case for new developers who want to use all the convenience methods of OpenGL 1 and 2, but these were stripped out in OpenGL 4 for the benefit of driver writers. This seemed like a big mistake to me, and arises from a loss of perspective from the spec stewards.
Re:w00t! by exomondo · 2016-01-26 13:52 · Score: 2

IMHO this is also a mistake. Having the application developer do driver-level resource management is a fail, IMHO.
Why exactly? Take glUniform calls for example, having the driver create its own buffer to copy that data into and then transfer that to the GPU memory is far less efficient than having the application map to the GPU directly.

I like APIs that operate on two levels: one level is the low-level stuff, where you are required to make every decision (Vulkan); then you have another part of the *same* API that has convenience methods for very common things that nearly every application needs (as OpenGL does).
The black box of the driver means that when you allocate memory on the GPU you don't know how much it is using, worse still if it fails and you get an GL_OUT_OF_MEMORY error, which could mean a few different things. Do you have no system or GPU memory left? How much do you need to free up? Instead of that you allocate the memory rather than telling the driver to do it, you already specify pretty much all the parameters when you do it in OpenGL anyway.

Pushing more work to the application developer just so the driver developer can do less is a fail and will result in lower adoption.
It's not about having the application developer do more, it's about having the driver do less and more closely mapping the application's resource usage to the GPU instead of the driver acting as an intermediate layer. You know how long you need memory for so why allow the driver to make assumptions about it?

Consider the case for new developers who want to use all the convenience methods of OpenGL 1 and 2, but these were stripped out in OpenGL 4 for the benefit of driver writers.
Maintaining useless, inefficient cruft that complicates the API is a burden on maintainers and those wishing to learn, why have a multitude of ways to do the same thing? That's just a mess.
Re:w00t! by zapadnik · 2016-01-26 17:18 · Score: 1

Why exactly? Take glUniform calls for example, having the driver create its own buffer to copy that data into and then transfer that to the GPU memory is far less efficient than having the application map to the GPU directly.
Double-handling is bad. However, the most modern programming languages are multi-threaded and you can't just give application memory to hardware without a rigmarole of pinning memory (to stop a garbage collector from moving memory around during compaction - which is fine with applications but not to give to hardware). And the performance from multi-threading is worth it - hence playing nicely with a application-level garbage collector should be considered in the design of any modern API.

The black box of the driver means that when you allocate memory on the GPU you don't know how much it is using, worse still if it fails and you get an GL_OUT_OF_MEMORY error, which could mean a few different things. Do you have no system or GPU memory left? How much do you need to free up? Instead of that you allocate the memory rather than telling the driver to do it, you already specify pretty much all the parameters when you do it in OpenGL anyway.
I have never, ever seen GL_OUT_OF_MEMORY, and I've been doing this a long time. The current OpenGL drivers are very good at managing memory, far better than most application developers. Pushing driver-level memory management to application developers is a design failure, AFAICS, as I will comment on below.

It's not about having the application developer do more, it's about having the driver do less and more closely mapping the application's resource usage to the GPU instead of the driver acting as an intermediate layer. You know how long you need memory for so why allow the driver to make assumptions about it?
It *is* about the application developer do more. That is the upshot of the API changes. Consider what it is like for people coming to OpenGL for the first time - the number of concepts that must be acquired to load a shader and render a simple 3D line or bitmap is horrendous and FAR greater than earlier OpenGL versions. The OpenGL designers have failed, and Khronos is heading completely in the wrong direction, IMHO.

it's about having the driver do less and more closely mapping the application's resource usage to the GPU instead of the driver acting as an intermediate layer.
This is the same argument for working in assembly. In this day and age it is ridiculous. Furthermore, you end up doing exactly what OpenGL was designed to avoid - writing lots of code paths for different GPU classes. This is a step backward. The ENTIRE POINT of OpenGL is to have the driver act as a hardware abstraction, and the driver writer (who is an expert in the hardware) can write optimizations so that the hundreds of thousands of application developers using OpenGL don't have to. You have the raison d'etre of OpenGL completely backward.

You know how long you need memory for so why allow the driver to make assumptions about it?
There are existing mechanisms to indicate when a buffer is no longer needed at the application level. Then the OpenGL driver decides when it is best to reclaim the memory. If the GPU architecture changes, different decisions can be made by the *driver writer* and not by the application developer. That is the point of any hardware abstraction layer.

Maintaining useless, inefficient cruft that complicates the API is a burden on maintainers and those wishing to learn, why have a multitude of ways to do the same thing? That's just a mess.
Drivers will always have to include shader compilers and/or shader bytecode interpreters - which are much more complex than simple API utilities to make application developer's life easier. Your argument is nonsense, but was put forth by phone manufacturers who wanted to skimp to create
Re:w00t! by exomondo · 2016-01-27 10:24 · Score: 1

Double-handling is bad. However, the most modern programming languages are multi-threaded and you can't just give application memory to hardware without a rigmarole of pinning memory (to stop a garbage collector from moving memory around during compaction - which is fine with applications but not to give to hardware).
You don't give application memory to hardware, you allocate GPU memory for use in your application. Why do you think you will have problems with Vulkan in terms of multi-threading?

I have never, ever seen GL_OUT_OF_MEMORY, and I've been doing this a long time.
Oh well it mustn't be a problem then, of course that's only one example. I'm hardly going to enumerate them in the hopes I find one you've hit upon.

The current OpenGL drivers are very good at managing memory, far better than most application developers. Pushing driver-level memory management to application developers is a design failure, AFAICS, as I will comment on below.
But it isn't driver-level memory management, as I already said it is about having the driver do less and that does not necessarily mean the application developer has to do more. Some more, but not a whole lot.

It *is* about the application developer do more. That is the upshot of the API changes.
But what you are not understanding is that this is not about the application developer taking on the responsibilities of the driver writer. Specifically why do you think this is the case?

Consider what it is like for people coming to OpenGL for the first time - the number of concepts that must be acquired to load a shader and render a simple 3D line or bitmap is horrendous and FAR greater than earlier OpenGL versions.
It isn't about it being easy, it is about doing it properly. An abstraction is supposed to be representative of the thing it is abstracting, OpenGL in its current state absolutely is not. Your beef is with the hardware developers, not Khronos and your advocating for it to be easy rather than effective which is a poor attitude.

This is the same argument for working in assembly.
No it absolutely is not. Your argument is that the abstraction should not be representative of the underlying hardware simply because it is too hard, that is just a cop out.

Furthermore, you end up doing exactly what OpenGL was designed to avoid - writing lots of code paths for different GPU classes.
Please provide an example. If you indeed to think this then you do not understand this at all. I suggest you go and read up on this rather than making baseless assertions.

The ENTIRE POINT of OpenGL is to have the driver act as a hardware abstraction, and the driver writer (who is an expert in the hardware) can write optimizations so that the hundreds of thousands of application developers using OpenGL don't have to.
And OpenGL is most definitely NOT an abstraction of modern hardware, the driver writer still indeed does write the hardware specific code which is precisely what a driver is.

There are existing mechanisms to indicate when a buffer is no longer needed at the application level.
Yes, poor inefficient mechanisms which leads to application-specific optimizations in drivers that become monolithic blobs.

Then the OpenGL driver decides when it is best to reclaim the memory.
And it very often gets it wrong, which is why we have so many application-specific optimizations in the drivers, this is the wrong way to do it. I would be happy to hear your arguments as to how to resolve this with the current OpenGL incarnation though?

Again, in order to save a little bit of driver effort on last-generation hardware it means that hundreds of thousands of application developers now ha
Re:w00t! by zapadnik · 2016-01-27 12:33 · Score: 1
Ok, I'll provide answers to your questions, if needed, but we have to get over a conceptual hurdle first. Ok?
Also, we are both on the same team. We both love 3D, we both like OpenGL and what it stands for (portable high-performance graphics) and want it to succeed. We both want great performance. And most of all, we want other people to also use this excellent technologies. Amirite?
Ok, so our (friendly) debate is simply about which has the greater priority: ease-of-use, verses to-the-metal performance. Yes? we are simply debating which is more important.
So my questions for you, which need to be addressed before I can answer your more specific questions, are:
1. 1) What is a the goal of an API ? as in, why use an API rather than assembly where you get maximum control and maximum performance?
2. 2) What is the meaning of the word "abstraction", and why is it important?
3. 3) Does time-to-market matter (enabled by abstraction), or is absolutely raw performance more important?
4. 4) Are there other ways to solve the driver-overhead problem, besides making the application programmer think closer to the hardware?
5. 5) If things are not easy (Einstein's, "As Simple As Possible, But No Simpler"), and new users find the technology too much effort to learn, then what is the point?
6. 6) Is the principle purpose of an API to make the API-author's life easier, or the user's life easier?
7. 7) If an API is successful then hundreds of thousands of application developers will use it, are all these more likely to understand how to make the correct series of optimized calls compared to the driver writer who knows the hardware AND API intimately?
8. 8) Are driver writers really more important than end users? really?
9. Like I said, the arguments you have advanced were all made before at the application level, between assembly and C/C++, and then again between C++ and Java/C#. It turns out that given enough time, the compiler writers and compilers can do a better job for almost all sections of code than most developers - mainly because time-to-market is main measure of success for any software (software projects don't fail because of the technology, but because the stakeholders abandoned it reached the market/users). Great design is about *simplicity* (that ASAPBUNS - "As Simple As Possible, But No Simpler") for the *end user*.
  I don't know if you are a Khronos member who has an emotional interest in this - so my apologies if I have offended you, because I appreciate the great work those guys are doing - and how they are moving OpenGL forward. All I'm saying is the success of an API has a lower weighting on raw performance and a greater weighting on ease-of-use and *longevity* (the latter being OpenGL's strength).
  Looking at Vulkan I get shudders. In terms of implementation if may well be more efficient. In terms of API *****design***** what I've seen is AWFUL. It is nearly as bad as Microsoft APIs. Seriously.
  Perhaps this comes from my mindset. I have a PhD in Physics (specifically, Astrophysics). I'm used to complexity. But the best approach to complexity is to take a reductionist stance and try to simplify ruthlessly. This is opposite to the 'computer science' mindset who talk about 'simplicity' but they make things far more complicated than they need to - except for some exception individuals who are actually good at API design. IMHO, and I fully appreciate it is merely my opinion, Vulkan is headed in the wrong direction. Hence I predict it'll go the way of Mantle and Metal. A few enthusiastic people will use it - but the greater simplicity of OpenGL probably means Vulkan will be seen as a misstep and after a few years will be slowly abandoned (like so many APIs before which promise great things but fail in terms of simplicity of design - prioritizing driver writers over end-users is a serious fail, and shows how bad at usable design the Vulkan authors are although they may be great computer scientists).
  Desi
Re:w00t! by exomondo · 2016-01-27 13:51 · Score: 1

Ok, so our (friendly) debate is simply about which has the greater priority: ease-of-use, verses to-the-metal performance. Yes? we are simply debating which is more important.
Well not really, I'm not really interested in a conceptual debate. If you could have a high performance, easy to use API then sure that would be great, so what I am trying to understand is what your specific grievances are wrt APIs like Vulkan, Mantle, Metal and DX12. Naturally somebody who has done years of OpenGL without understanding what exactly it is abstracting is going to find Vulkan difficult but that is simply because your view of how 3D graphics pipelines work is limited to what you see in the API, meanwhile the hardware that is being abstracted has changed so much that your view is completely wrong now and the API is horribly inefficient because the OpenGL machine description isn't representative of modern hardware.

So my questions for you, which need to be addressed before I can answer your more specific questions
It's a bit intellectually dishonest to suggest you cannot answer my questions without me first answering these. Clearly mine are very specific and don't need answers to your questions to be able to answer them.

I don't know if you are a Khronos member who has an emotional interest in this - so my apologies if I have offended you, because I appreciate the great work those guys are doing - and how they are moving OpenGL forward.
No, I am not.

All I'm saying is the success of an API has a lower weighting on raw performance and a greater weighting on ease-of-use and *longevity* (the latter being OpenGL's strength).
The problem that you seem to want to ignore - because learning something new is too hard - is that OpenGL is a mess of antiquated cruft that is no longer representative of the underlying hardware. I get it, those set in their ways will struggle but we can't hold back the hardware architecture with an inefficient abstraction just because some people are aversed to change.

I'm just trying to get an honest opinion through to you - because you don't seem to understand what *users* are looking for in an API. Thanks for giving some of your precious time to this debate.

Well tell me then, what specifically is wrong with Vulkan compared to OpenGL?
Re:w00t! by zapadnik · 2016-01-27 16:02 · Score: 1

Naturally somebody who has done years of OpenGL without understanding what exactly it is abstracting is going to find Vulkan difficult but that is simply because your view of how 3D graphics pipelines work is limited to what you see in the API, meanwhile the hardware that is being abstracted has changed so much that your view is completely wrong now and the API is horribly inefficient because the OpenGL machine description isn't representative of modern hardware.
You keep using the word "abstraction" without apparently understanding what it means. Which is why I asked you the question about what your understanding of the word is, and why it is important.
Furthermore, you don't seem to understand that model OpenGL has moved away from a State Machine oriented model into an object-based buffer model. The performance of modern OpenGL is horrible if you don't know what you are doing and making LOTS of inefficient calls. The 'zero driver overhead' goal is to enable this relatively inefficient style of coding to be less painful (thus enabling some effects that are otherwise expensive). The OpenGL is not "horribly" ineffecient, just less efficient for some operations while being the same or MORE efficient in others. I've already referenced you to benchmarks on this.
With regard to "understanding". As a physicist I understand the hardware at the transistor-level (and the physics of MOSFETS). As a driver writer I understand hardware devices from the kernel level. As an application developer I understand them from the "end-user" of the development chain level. I think Vulkan is broken not because I don't understand what it is trying to do, nor because I don't want to learn anything new, but because the Vulkan *design* forces more work on the developer for what has proven to be a marginal increase in performance in a limited number of cases. I'm simply pointing out that the designers of the spec have produced something that I think will fail to met their objectives and be widely adopted by the mainstream development community. This is what you seem to fail to be able to grok. I *AM* the target audience for Vulkan - and from what I've seen I think it is a step backwards in terms of design. As a result, the risk of porting my product to it is too high, because I don't perceive great longevity in this API - hence I see it as a strategic mistake to move to it, and I am sure many others see this too. At least, not while the good-enough OpenGL model is still around and still progressing.

It's a bit intellectually dishonest to suggest you cannot answer my questions without me first answering these. Clearly mine are very specific and don't need answers to your questions to be able to answer them.
False. My objects are about *design* and *level of abstraction*. You seem to think that these are not concerns for the success of a product. You also don't seem to grok what the word "abstraction" means and why APIs exist at all. You appear to be unable to separate concerns for what a driver is supposed to do verses what an API is supposed to do. Hence, your questions are at the wrong level of abstraction and you are unable to shift gears mentally to address them.

The problem that you seem to want to ignore - because learning something new is too hard - is that OpenGL is a mess of antiquated cruft that is no longer representative of the underlying hardware.
Again you don't understand the purpose of an API. The API is NOT supposed to represent the hardware. It is supposed to allow control of the hardware, relatively efficiently. The driver is the abstraction for the hardware - you keep mixing up the functions of a driver and the application API without seeming to understand the roles. And as I have stated, I have no problem learning something new - but NOT for its own sake (I have more than enough to do creating my product) and not do re-writes for marginal improvement in a limited number of areas at
Re:w00t! by exomondo · 2016-01-27 16:32 · Score: 1

Ok it is quite clear you don't know anything about Vulkan hence your inability to give any specifics on what you think is wrong with it. Not a conceptual level, when I say specific I mean specific about the API. You can't do that because you don't know anything about it, you're ranting about your own misinterpretation. So try again to be specific.

Sorry, the economics of Vulkan are not favorable for me - because the *design* of the API is horrible
Cite the specific design aspects. What parts of the API design are "horrible"? If you know what you're talking about this should be very easy.
Obviously what you need is a higher level API, which can be built atop Vulkan, DirectX, Metal and/or Mantle and that will solve your problem, it will be far less efficient but it will be easy and you won't be holding everybody else back. That's your problem solved.
Re:w00t! by Anonymous Coward · 2016-01-27 16:49 · Score: 0

Having the application developer do driver-level resource management is a fail, IMHO.
Then you will be glad to know that in vulkan the application developer does not do driver-level resource management; such things are left to the driver. The application developer still makes resource requests through the driver but is then allocated GPU memory to work with. It is kind of like having bindless graphics as a first class citizen but with the added benefit of multithreaded building of command buffers which is a huge limitation in OpenGL which is inherently serial.
Re:w00t! by zapadnik · 2016-01-27 18:27 · Score: 1

Ok it is quite clear you don't know anything about Vulkan hence your inability to give any specifics on what you think is wrong with it. Not a conceptual level, when I say specific I mean specific about the API. You can't do that because you don't know anything about it, you're ranting about your own misinterpretation. So try again to be specific.
Ok, you don't understand. True or false, Vulkan requires more work from application developers and a much greater conceptual understanding from beginnings? True or false? You know this is true, which means Vulkan is a fail out of the gate except for those CPU bound (mobile devices, but not desktop or workstation applications).

Cite the specific design aspects. What parts of the API design are "horrible"? If you know what you're talking about this should be very easy.
Well, the fact that API specification is not finalized is a hinderance. But looking at what has been released wtf should I be tracking the internal state of the GPU in application code?
VkImageMemoryBarrier
vkCmdPipelineBarrier
No matter whether I track these or not it makes ZERO difference to my application that is GPU bound. And if your application is not GPU bound you are either on a mobile device (which has shitty performance at the best of times) or you don't know what the fsck you are doing.
How will Vulkan help my existing multi-threaded, GPU-bound application get any faster - even if I spent the $100k to port it to Vulkan ? Also, I'm working in Java/JoGL as C++ is a dog and development is much slower and the tools a junk compared to the Java ecosystem?
How does Vulkan help me in any way? it does not! in fact it is a hinderance. It forces me to worry about all sorts of concerns that should be the responsibility of the driver, and optimized by the driver writer for their hardware.
So where do I get the official Vulkan 1.0 spec? it's release has been delayed and the specification is not available from Khronos. All we have are snippets of code and they look fscking AWFUL. You are ranting about vaporware whose early implementations don't live up to the hype. Vulkan takes the design mistakes of DirectX (pre-compiled shaders being a massive source of grief) and moves it to OpenGL. All so crappy mobile devices are marginally less turdish, and not only doing nothing for the high-performance GPU-bound workstation applications, but actually making the development much slower (resulting in longer time to market).
You don't even have an official finished spec to talk about - you are talking about vaporware. All you have are press releases and some beta-code that pre-dates the spec, and thus, cannot be conformant.

Obviously what you need is a higher level API, which can be built atop Vulkan, DirectX, Metal and/or Mantle and that will solve your problem, it will be far less efficient but it will be easy and you won't be holding everybody else back. That's your problem solved.
BOOM! here is the admission from you that Vulkan has already failed as a replacement for the ***application-level*** OpenGL. Instead of a three-tier system (hardware, driver, application [OpenGL]) your architecture moves to four-tier (hardware, driver, Vulkan, framework) because of the *crappy API design* of Vulkan. You know this is true but your ego is preventing you from admitting it.
Fortunately even Khronos understand this and will continue with OpenGL, while Mantle 2.0 ("Vulkan") goes the same way as Mantle 1.0 (as in, nowhere, except for fanbois).
Sorry, for GPU-bound workstation devs Vulkan is pretty much a bust out of the starting gate. You can keep your koolaid, thanks.
Re:w00t! by exomondo · 2016-01-28 09:27 · Score: 1

Ok I can see you take exception to it being harder than OpenGL and your limited use-cases will not benefit from Vulkan, but that is ok. We won't all be limited just because you are. The key problems with OpenGL are resolved with Vulkan:
-The implementation requires that application-specific optimizations be in the driver, this is wrong. Application code belongs in the application, not in the driver.
-OpenGL is inherently serial which limits the ability to exploit multi-core CPUs, whether this be unnecessary patterns that require multiple threads submitting work to a single draw thread or cases - such as mobile - where you have low single-core performance. You may not have this in your limited experience but many of us deal with applications that extend beyond the capacity of a CPU single core.
-The added flexibility gives us more control to exploit multi-GPU systems, again you might not need that but that's ok.
Now you can say you don't have these problems so therefore you don't need the added complexity, that's fine. You can use a higher level toolkit like the Visualization Toolkit for example or an engine like Unity or Unreal Engine or better yet you could use an OpenGL-like higher level API that sits atop Vulkan which could be easier to use at the cost of efficiency and flexibility. You can even continue developing in OpenGL because it will still exist for a long time to come and even when the major vendors stop supporting it there are plenty of open source driver implementations and even software implementations if you are so inclined.

But looking at what has been released wtf should I be tracking the internal state of the GPU in application code?
Because when you're working asynchronously you need to know when operations are complete. Is that really the basis for your criticisms of the API?

BOOM! here is the admission from you that Vulkan has already failed as a replacement for the ***application-level*** OpenGL. Instead of a three-tier system (hardware, driver, application [OpenGL]) your architecture moves to four-tier (hardware, driver, Vulkan, framework) because of the *crappy API design* of Vulkan.
No, with OpenGL we end up with application code in the driver, which is wrong, application-specific code does not belong in the driver. Vulkan fixes that which means for high performance applications Vulkan will be hugely beneficial and for those of you who don't need high performance you can go with one of the many options I already listed for you.
Re:w00t! by zapadnik · 2016-01-28 23:54 · Score: 1
Thanks for confirming:
1. Vulkan provides no performance benefit for desktop and workstation applications that are GPU-bound
2. Vulkan might provide a performance benefit for low-end applications, like mobile, that are CPU-bound
3. On all platforms Vulkan is more complex and development-costly than OpenGL
4. Vulkan has not yet been released
5. Vulkan requires application developer to do much of the work previously done by driver writers
6. Vulkan removes the ability for hardware vendors to provide extra driver-level optimizations for applications
7. Vulkan follows much of the design mistakes of DirectX (eg. the hideous design of capabilities querying with multiple application code-paths
8. Vulkan decreases abstraction, and is a glorified driver-level asbtraction interface, and not intended as an application-level API
9. Current initial implementations of Vulkan don't match up to the hype
Re:w00t! by exomondo · 2016-01-31 09:40 · Score: 1

Well no, you misunderstand. In fact quite clearly most of your assertions are wrong and you have obviously misinterpretted what I said, you also seem to disagree with people like Graham Sellers, Tim Foley and Cass Everitt, yet are not able to explain why.
The fact that you find memory barriers, a basic concept of asynchronous programming - that of course already exists in GLSL - to be too complex demonstrates that you aren't very experienced despite your attempts at credential-dropping. However since you aren't able to realize this on your own and you won't take my word for it I invite you to enact change if indeed your criticisms are valid:
Please post your objective criticism(s) here on the Vulkan forums. You genuinely believe your criticisms to be comprehensive and valid so please post them in the appropriate place.
Re:w00t! by zapadnik · 2016-01-31 18:36 · Score: 1

Well no, you misunderstand. In fact quite clearly most of your assertions are wrong and you have obviously misinterpretted what I said, you also seem to disagree with people like Graham Sellers, Tim Foley and Cass Everitt, yet are not able to explain why.
I got thsoe points from Vulkan powerpoint presentations. It appears you are not able to understand my explanation as to the design and economics reasons why Vulkan is useless except on low-end hardware (eg. mobile), where it does make a difference - although so does the "zero driver overhead OpenGL" techniques. The Vulkan people themselves say that Vulkan will not make any difference on GPU-constrained applications, and they themselves say that Vulkan is inappropriate unless you are CPU-constrained, plus taking more effort to develop for the same end-user functionality. Your dispute is with them, not with me - I'm merely pointing out that Vulkan is a worse choice than OpenGL for desktop and workstation application developers.

The fact that you find memory barriers, a basic concept of asynchronous programming - that of course already exists in GLSL [opengl.org] - to be too complex demonstrates that you aren't very experienced despite your attempts at credential-dropping. However since you aren't able to realize this on your own and you won't take my word for it I invite you to enact change if indeed your criticisms are valid:
I've been developing a lot of stuff in the last two decades. I've used a LOT of complex APIs, but my experience has shown me that a poorly designed API doesn't last long - think of AMD's Mantle, and Vulkan is Mantle 2.0 - if you cannot convince developers like me to use it in our products then it is dead. We eschew complexity not because we can't handle it (we can, but it doesn't excite veterans who have done it all before in the way it excites you amateurs) but because it makes poor economic an strategic sense - especially when the added complexity makes no significant performance difference on the desktop where our products are.
To use a car analogy: we have a 2013 racing car with a 6L engine, with a complex tiptronic/manumatic transmission. You are saying that if you switch to a 2015 car with a 4L engine with manual transmission then you'll get better control over cornering - which is entirely true - but you miss the fact that the point is to get from start to end in minimum time (time-to-market) and that the performance of manumatic over the long straights makes up for the few corners that a manual does a better job at. Hence you argue with the concerns of an amateur, instead of those of a professional (time-to-market, cost, ease for larger teams to work together, avoiding unnecessary complexity where possible, etc).

Please post your objective criticism(s) here [khronos.org] on the Vulkan forums. You genuinely believe your criticisms to be comprehensive and valid so please post them in the appropriate place.
That's not a bad idea. The only problem is that the opposite of love is not hate, but indifference. I see Vulkan as much of a design mistake as Mantle was. I could spend time arguing how to make it better, but what is the point trying to convince people who are so bad at API design they are completely oblivious as to what their intended audience actually need? I'd rather spend more time getting my product finished than debating with people who have closed minds and haven't been developing long enough to understand what really matters to application developers on higher-end hardware.
Seriously, you have completely failed to make the case as to why existing developments should be switched to Vulkan when Vulkan is going to cost more to use in development and make no difference to performance in GPU-bound situations. You could argue that it is not your job to convince others to use Vulkan, but that is clearly your intention as a fan of it. Fortunately even Khronos know not to bet the farm on making the s
Re:w00t! by exomondo · 2016-02-01 10:00 · Score: 1

I got thsoe points from Vulkan powerpoint presentations.
Link me to the powerpoint presentations that have those points then. I doubt they exist, they are your points and they are derived from your own misinterpretation of the information.

I'm merely pointing out that Vulkan is a worse choice than OpenGL for desktop and workstation application developers.
If that is how you feel then use one of the various alternative solutions I already outlined for you.

I've been developing a lot of stuff in the last two decades. I've used a LOT of complex APIs, but my experience has shown me that a poorly designed API doesn't last long
But it isn't poorly designed, your specific criticism is that it has memory barriers - just like GLSL does - so when you say you have all this experience yet you don't understand the basics of asynchronous programming and don't even know GLSL very well certainly calls your claims into question.

That's not a bad idea. The only problem is that the opposite of love is not hate, but indifference. I see Vulkan as much of a design mistake as Mantle was. I could spend time arguing how to make it better, but what is the point trying to convince people who are so bad at API design they are completely oblivious as to what their intended audience actually need?
No, I said post your objective criticism, the problem is you are so misinformed that you don't have one. You've gone to great effort to make baseless claims about things you clearly don't understand but then tell me you don't have time to post such things on the Khronos forum? No sorry that's just rubbish. If you really thought it was a waste of time and not that you're just going to look like an idiot then you wouldn't be spending all this time trying to convince me. Quite frankly when your only criticism of the design of the API is because it has memory barriers (and you think that is telling you the internal state of the GPU, which it isn't) then you have proven all this credential-dropping is untrue since you don't even have any experience with the basics of asynchronous programming and you think application code belongs in the driver. Every time you get backed into a corner you throw out the obviously false claim that you are expderienced, which you clearly are not.
I'm sure you'll post yet another long rant desperately trying to convince me but won't post on the Khronos forums.
Re:w00t! by zapadnik · 2016-02-01 21:36 · Score: 1

Link me to the powerpoint presentations that have those points then. I doubt they exist, they are your points and they are derived from your own misinterpretation of the information.
Here's a short summary from a Vulkan IMPLEMENTOR on where OpenGL is better than Vulkan, and vice-versa:
https://developer.nvidia.com/e...
Then if you read Graham Seller's own Powerpoint AND have experience in developing LARGE applications you can see massive potential pitfalls in using Vulkan that you won't get with OpenGL:
http://nextgenapis.realtimeren...
Of course, as an amateur you are not used to looking for indications of the limitations of an API rather than the marketing points - as doing this only comes with experience (and as I was a fanboi once but learned to look through the marketing spiel with a critical eye - a habit which it appears you have not yet developed).

If that is how you feel then use one of the various alternative solutions I already outlined for you.
Nope, OpenGL is more than sufficient - especially with the "Approaching Zero Driver Overhead" approaches and extensions. You don't seem to grok that the increased productivity of OpenGL for desktop workloads more than makes up for the few cases where Vulkan is better. For example, Vulkan produces zero benefit when rendering tessellated terrain on the GPU in my flight simulator, because the GPU is doing all the work and the use of the Vulkan command-buffer model gains nothing, but increases development cost. Hence, OpenGL is still a better option when your problem is rendering hundreds of millions of polygons per second on a discrete workstationGPU, and not submitting tens of thousands of sprites to a phone GPU with the phone's limited CPU.

But it isn't poorly designed, your specific criticism is that it has memory barriers - just like GLSL does - so when you say you have all this experience yet you don't understand the basics of asynchronous programming and don't even know GLSL very well certainly calls your claims into question.
Yes, OpenGL has that feature (so why use Vulkan?) but you don't HAVE to use that feature. This is the two-level API design I mentioned a few posts back, and why OpenGL gives you some control if you need it, plus higher-level options too - but you are not forced to do everything as if you were programming for a console with a shelf-life of a few years. Plus, on my MacPro with dual D700s the glMemoryBarrier call s not yet supported (grrrrrr crappy Apple spending effort on Metal instead).

No, I said post your objective criticism, the problem is you are so misinformed that you don't have one. You've gone to great effort to make baseless claims about things you clearly don't understand but then tell me you don't have time to post such things on the Khronos forum? No sorry that's just rubbish. If you really thought it was a waste of time and not that you're just going to look like an idiot then you wouldn't be spending all this time trying to convince me. Quite frankly when your only criticism of the design of the API is because it has memory barriers (and you think that is telling you the internal state of the GPU, which it isn't) then you have proven all this credential-dropping is untrue since you don't even have any experience with the basics of asynchronous programming and you think application code belongs in the driver. Every time you get backed into a corner you throw out the obviously false claim that you are expderienced, which you clearly are not.
Wrong. EVERYBODY says that Vulkan is more work. Everyone says that Vulkan drivers don't check for errors, which means it is easier to not only crash your application, but crash the whole damn machine - you wait until Vulkan is used in the Real World (tm). Everyo
Re:w00t! by exomondo · 2016-02-02 09:55 · Score: 1

Here's a short summary from a Vulkan IMPLEMENTOR on where OpenGL is better than Vulkan, and vice-versa
The only criticism in that article is that Vulkan comes with some added complexity, which is precisely why I pointed out that for people like you there is the higher level API built on top of Vulkan. Why is that so difficult for you to understand?

Then if you read Graham Seller's own Powerpoint AND have experience in developing LARGE applications you can see massive potential pitfalls in using Vulkan that you won't get with OpenGL
And also the massive benefits that you do get with Vulkan, so again, for people like you that can't manage the complexity and for which the benefits of Vulkan aren't an advantage there are less efficient higher level APIs for you to use.

Nope, OpenGL is more than sufficient
Not for everybody, hence the reason OpenGL (and DirectX which is wrong.

the use of the Vulkan command-buffer model gains nothing, but increases development cost.
Which is why you would use a higher level API for your use-case, problem solved. Why are you still whining about it?

Yes, OpenGL has that feature (so why use Vulkan?)
What I'm pointing out is that you citicised Vulkan for having memory barriers and now that I have educated you on the fact that OpenGL also has memory barriers you have changed your mind. You claim to be experienced yet you didn't even know this existed in OpenGL before and so criticized its existence in Vulkan. I don't expect anybody to know everything so stop pretending, you just keep looking stupid.

Sometime you should read the criticisms of the Mantle API, as this applies directly to Vulkan (which follows the same concepts), for an idea, look at this. Apple considers Metal to have better performance than Vulkan, and supposedly better than OpenGL - yet OpenGL beats Metal (and thus, Vulkan) on the discrete GPU in this benchmark
So use OpenGL (or a high level equivalent) in that case. Parallel is not always better so use the right approach for your problem, Vulkan allows this. Your issue with it is that its benefits may not be useful to you therefore they can't be useful to anybody, that is an attitude that stems from limited experience. You may be old and stuck in a rut for decades but that doesn't make you experienced.

Couple that with the fact that Apple is not supporting Vulkan (supporting OpenGL and Metal instead)
Apple's support for OpenGL is merely a token gesture, as you already pointed out they are way behind in feature support.

You think I'm "trying to convince you"? LOL !
Yes you in fact are, you respond to every one of my points and avoid my questions. Please post your criticisms on the Vulkan forums and you will see how wrong you are, apparently you "don't have time" for that but you do have time to desperately respond to me.

Vulkan is not cross-platform in the way OpenGL is (at least, it won't be for a few years).

Of course not, nobody is suggesting even getting rid of OpenGL at this stage, just having Vulkan as an option for developers for which it will be advantageous, why do you have such baseless and irrational objection to that?
Re:w00t! by zapadnik · 2016-02-02 18:03 · Score: 1

The only criticism in that article is that Vulkan comes with some added complexity, which is precisely why I pointed out that for people like you there is the higher level API built on top of Vulkan. Why is that so difficult for you to understand?
You know all that complexity in the driver Vulkans want to avoid? it now gets push to the application. EVERY application has to replicate the same optimizations - and unless you are specializing in the hardware (as driver writers do) then there are a lot of optimizations that won't be done by application developers. You fail to grok this. With regard to your suggestion of using a "higher level library" then you you are back to using something less efficient than Vulkan - which means you might as well use OpenGL (which will be faster for GPU-bound applications because the driver has so many optimizations for the specific hardware). Why is this difficult for you to understand?

And also the massive benefits that you do get with Vulkan, so again, for people like you that can't manage the complexity and for which the benefits of Vulkan aren't an advantage there are less efficient higher level APIs for you to use.
"Massive benefits" are theoretical, and for limited cases on low-end hardware that is CPU-limited. I've already given benchmarks of an API faster than Vulkan (that is, Metal - but the design tradeoffs are comparable to Vulkan) that outperforms OpenGL on low-end hardware but is completely blown-away on even mid-range discrete GPUs like the Nvidia 680 GTX that was tested. You are arguing on the basis of hype - and the REALITY of the architecture shows the implementation does not quite live up to the hype - all at the cost of increasing time-to-market, development cost, complexity and reliability.

Not for everybody, hence the reason OpenGL (and DirectX which is wrong.
I didn't say no-one could use Vulkan. I didn't say everyone must use OpenGL. I didn't say that OpenGL beats Vulkan in all cases. You are LYING when you put words into my mouth (again). It is a bad habit you really should get out of. What I did say is that Vulkan has limitations that make it worthwhile on low-end CPU-bound hardware, but not worth the effort on high-end hardware compared to OpenGL. Your fanboism drops your reading comprehension to that of a retard.

Which is why you would use a higher level API for your use-case, problem solved. Why are you still whining about it?
Which means ... drumroll ... that going to Vulkan is not worth the effort for most people, except those working on low-end hardware. Why are you unable to grok this? Vulkan is not going to be successful as you think and will go the way of Mantle.

What I'm pointing out is that you citicised Vulkan for having memory barriers and now that I have educated you on the fact that OpenGL also has memory barriers you have changed your mind. You claim to be experienced yet you didn't even know this existed in OpenGL before and so criticized its existence in Vulkan. I don't expect anybody to know everything so stop pretending, you just keep looking stupid.
You are LYING again. I said that in OpenGL you don't have to deal with memory barriers, and they are not universally supported anyway. With Vulkan you HAVE to do driver-level management (including memory barriers, but all sorts of different paths based on the hardware capabilities) - there is no avoiding it. The average application developer is not going to do this. You can refuse to listen now, but reality will bite you in the azz later. but like I said, I don't actually care - it is clear that Vulkan is going the way of Mantle - particularly with partial support on Linux and no support from Apple (who walked away from Vulkan - they can see what you cannot).

So use OpenGL (or a high level equivalent) in that case. Parallel
Re:w00t! by exomondo · 2016-02-02 18:29 · Score: 1

Yes yes more "fanboy" namecalling garbage to detract from your inability to express yourself objectively. Post your criticism in the Vulkan forums, then you will see how wrong you are. It will expose both your lack of knowledge and understanding.
We can do this in tiny steps, one at a time since large things are clearly overwhelming and enraging you:
OpenGL's model means application-specific optimization code must exist in the driver rather than the application, this is wrong. In Vulkan this application code is in the application instead of the driver.
Re:w00t! by zapadnik · 2016-02-03 16:55 · Score: 1

Yes yes more "fanboy" namecalling garbage to detract from your inability to express yourself objectively. Post your criticism in the Vulkan forums, then you will see how wrong you are. It will expose both your lack of knowledge and understanding.
Ah, after all your lies and assertions that I was supposedly unable and unwilling to learn you now want to "play the victim" card. Laughable. You are an amateur who doesn't know anything about design nor about the economics of producing a 3D application and the decision making in producing and maintaining commercial applications.

We can do this in tiny steps, one at a time since large things are clearly overwhelming and enraging you:
Here your "victim" play goes into passive-aggressive idiocy. All because you cannot refute the REAL WORLD benchmarks I gave, nor discuss the economics, nor talk about what Vulkan implementors have had to say, nor on Apple's decision to abandon Vulkan, nor AMD's decision to bot support recent hardware (should be easy if Vulkan drivers are as simple as the hype claims).

OpenGL's model means application-specific optimization code must exist in the driver rather than the application, this is wrong. In Vulkan this application code is in the application instead of the driver.
You sound exactly like a religious zealot - which, for all intents and purposes, you are. Application-level optimations are still done in OpenGL just as in Vulkan. However, in OpenGL the driver writers also have the option of assisting applications if they choose to. They don't have to, but they can (and, as it turns out, they do - because it results in faster high-end applications; resulting in not only better applications, but better drivers). In the Vulkan model the drivers are dumb. If an application developer doesn't use an optimization the Vulkan driver is too dumb to assist. The experts in the hardware (driver writers) cannot help application developers use their hardware better without any extra effort because the Vulkan model doesn't allow for this - the application developers must thus write an optimized code-path for each piece of hardware - this destroys the concept of "abstraction" where each driver can optimize for its own hardware architecture and the application doesn't have to care too much. As I said, this is bad design and a step backwards - because guys good at hardware are often crap at application design and architecture. It is a different set of skills. But as an amateur, you don't know this.

Open up your hardware then by Anonymous Coward · 2016-01-26 09:11 · Score: 0

Maybe there's monetary reasons not to but do they realize how much free software and how good their drivers would get if they just gave up the full specs to their hardware for open source devs to have? Think of all the bugs you won't have to fix because other intelligent people who are interested will do it for you. Then you hire those people to improve your graphics division.

Re:Open up your hardware then by jonwil · 2016-01-26 09:18 · Score: 1

Ummm, last I checked, AMD was second only to Intel in terms of how much they are sharing about their GPUs. Most of what they haven't shared with the guys doing the open source drivers are things they either cant share for legal reasons or thinks they intend to share as soon as everything passes the lawyers...
Re:Open up your hardware then by Anonymous Coward · 2016-01-26 09:32 · Score: 0

Most of what they haven't shared with the guys doing the open source drivers are things they either cant share for legal reasons
Well, that's the major problem, isn't it? Here's our GPU/black box, we'll give you some access to the stuff that isn't our trade secret or licensed IP. Not good enough? We'll write a graphics driver for your OS (Linux). Can't have the source code because of trade secret/licensing issues. Yeah, it's kind of sucky, but we've spent over a decade optimizing our hardware designs around DirectX calls.
Re:Open up your hardware then by Anonymous Coward · 2016-01-26 10:30 · Score: 0

Maybe there's monetary reasons not to but do they realize how much free software and how good their drivers would get if they just gave up the full specs to their hardware for open source devs to have?
The problem is that is just theorizing. They give up all their secret competitive advantage in the hope that there are a whole lot of people out there that will do a whole lot of work for them for free and pay them for the privilege by buying their graphics cards. Sure there may be some initial enthusiasm but you don't think people will grow tired of spending their free time fixing bugs for corporations that then profit from it?
Re: Open up your hardware then by Anonymous Coward · 2016-01-26 20:51 · Score: 0

Well, the x86 was an open standard and it won the market share because developers had access to optimize and compete. RIM e.g. refused to adopt to changes in the smartphone market and soon enough lost to Google and Apple. Android is also now gaining market share from Apple. Open standards are the way to go, stop being a pessimistic little bugger.
Re:Open up your hardware then by Martin+Blank · 2016-01-27 03:44 · Score: 1

It might work. John Carmack complained a few years ago about having to work through PC drivers as opposed to the essentially direct access to hardware that he got on consoles, and how essentially the exact same code path on PCs took far longer because the driver imposed all kinds of checks and penalties that he felt were unnecessary. If developers were to get access to a lower level through improved drivers, it might help boost performance. The drivers would still be needed to prevent them from doing certain things that might lock up (or outright damage) a card and crash the system, but every little bit closer to the hardware that can still be handled safely is better for everyone.

--
You can never go home again... but I guess you can shop there.

drivers first by Anonymous Coward · 2016-01-26 09:16 · Score: 0

still waiting for a decent non-blob video driver...

What? by Anonymous Coward · 2016-01-26 09:17 · Score: 5, Interesting

This has nothing to do with Intel and everything to do with getting people to adopt AMD's open standards over NVIDIA's closed standards, which is actually better for the health of the industry as a whole. What is it you expect Intel to sign up for? Their graphics products are garbage and absolutely nobody wants to use them.

Re:What? by Anonymous Coward · 2016-01-26 09:49 · Score: 0

Pretty sure that is what a lot of us think about AMD...
Re:What? by Richard_at_work · 2016-01-26 10:38 · Score: 1

In the graphics industry, technology consumers go where the performance is best - they arent going to drop performance just because the framework is open, so AMD had better be competitive on performance as well as open.
Re:What? by SuperKendall · 2016-01-26 11:20 · Score: 1, Informative

Intel graphics products these days are pretty decent and many people already do use them. You are living in a fantasy if you think otherwise...

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Re:What? by MachineShedFred · 2016-01-26 12:10 · Score: 1, Informative

and by "absolutely nobody" you actually mean "90% of the computing public that are fine with 'good enough for what I'm doing'"
Here's a hint: You don't need a $400 GPU for Netflix.

--
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Re:What? by Anonymous Coward · 2016-01-26 13:39 · Score: 1

I think AMD is just sick of Hollywood's hatred of Linux with it's MS supported Encrypted Paths & Tilt Bits that protect their dead industry.
Re:What? by Anonymous Coward · 2016-01-26 15:02 · Score: 1

Here's a hint: You don't need a $400 x86 CPU for Netflix, either.
Re:What? by Anonymous Coward · 2016-01-26 15:40 · Score: 0

If the purpose of your machine is to be a Netflix box, you can find adequate x86 CPU for less than $100.
Re:What? by kyubre · 2016-01-26 17:35 · Score: 1

My $15 Pine A64 has shipped!

--
Nothing evolves faster than the word of god in the minds of men who think themselves divinely inspired.
Re:What? by Anonymous Coward · 2016-01-26 18:31 · Score: 0

This makes me think of AMD / ATI as the US, because of this quote:
"You can always count on Americans to do the right thing - after they've tried everything else." - Winston Churchill
Hope it pans out for them. AMD is used extensively in consoles, which seems to be a common oversight for all the bashing it gets. If this can bring their PC performance on par with some of the polishing that consoles get, I say that they've done their job.
Re:What? by aliquis · 2016-01-26 20:10 · Score: 1

Here's a hint: You don't need a $400 GPU for Netflix.
and regarding to what AC, http://hardware.slashdot.org/c..., said:

Here's a hint: You don't need a $400 x86 CPU for Netflix, either.
AMD A10 7850K (3.7 GHz quad-core) with integrated graphics: $130.
AMD Athlon II 860K (3.7 GHz quad-core) without integrated graphics: $75.
Price difference for integrated graphics: $55
And for whom want to play games: GTX 750Ti $105, which are of course are better added to the $75 rather than the $130 CPU.
Re:What? by TheDarkMaster · 2016-01-26 22:46 · Score: 2

Only if you do not intend to play graphically heavy games on your computer.

--
Religion: The greatest weapon of mass destruction of all time
Re:What? by AmiMoJo · 2016-01-27 00:46 · Score: 1

In fact Intel is already getting on board with AMD's open standards like FreeSync, avoiding Nvidia's proprietary version.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:What? by KGIII · 2016-01-27 12:21 · Score: 1

While that's likely true in the majority of cases, it's not entirely true - at least for some of us. But, at the same time, I'm not sure how much that matters.
I tend to buy a lot of hardware. I'm not really sure why I do so these days. It's not like I get any real performance increases and it's not like I buy bleeding edge. I just refresh often, give away my older hardware, and like to play with new/different configurations at the bare metal level and not just at the VM level. I know, I know... It doesn't make a whole lot of sense - but it keeps me happy.
Lately, I've used just Linux on the desktop, server, and tablet (I guess). I do have a Windows phone. It's just 8 but I guess I can put 10 on it but I've not looked into it. I'm really not that much into tablets or phones - I sometimes email and surf on my phone. That's it.
Anyhow, I'd be more inclined to buy AMD graphics if they were open and worked better with Linux. I'm pretty much always just buying AMD CPUs anyhow - though I often will opt for an nVidia CPU. Sometimes ATi but mostly nVidia. I'm not sure if this is applying to ATi or not, or if it's for the GPU processing on the CPU, ala Intel. I don't even know if there's a difference - which is kind of where I'm going with this.
See, I don't game and I could give two shits about high definition movies and whatnot. I guess I've got that capacity but I don't bother. I don't think I've actually ever watched anything in 4k. I don't even bother with full 1080i or the likes unless that's what's fed to me by default. I have YouTube (which is where I watch a lot of documentaries even though I pay for Netflix and Hulu+) set to automatically play movies at 480. That's it.
I don't buy the cheapest GPU I can find. I just pick something, middle of the road, and not too new - that way I know it's probably fairly well supported. I mostly order whiteboxes and I guess, sometimes, I even have them mostly assembled for me these days. I don't know when the last time was that I bothered paying attention, trying to get the best, overclocking, or anything like that? Shit's fast enough for me now. I honestly don't even have to buy new hardware - I just do to play around and keep myself busy. Lately, I've kind of taken to setting something up, getting it running well, and then just handing it off to someone and buying myself something new. I've got more desktops and laptops than I know what to do with, they're all "fast enough."
It's not like there's a huge difference if I compile something on this year's CPU or if I compile it on one from a year ago. They're mostly the same speed. With an SSD and 16 - 32 GB of RAM then, well, I really don't need anything faster. It just doesn't matter any more. Yeah, I've bought a few PCs and decked them out with as much as 64 GB of RAM. Yay? Truth be told, I didn't notice any difference between that and 32 and barely noticed a difference between that and 16. Hell, I can get by with just 8 and be fine. 4 is a bit too low, these days, but I've done it. I don't always get rid of the oldest computer first. I kind of like to keep some around that span some of the ages. It's neat to be able to get Linux to not just run - but to run well, on a desktop with just 4 GB of RAM. Oh, I'm sure I could go smaller - I have in a VM and I have in the past.
Anyhow, to my non-point... Yeah? I guess... If it were more likely to work AND it were open then I'd probably buy it just to support the company. I already buy AMD CPUs. I've had some issues with ATi hardware and Linux in the past (screen tearing and a strange lockup - on two different cards) so I mostly avoid it out of habit. I've no idea where they are now. I just don't pay much attention and I sure as hell don't even bother paying attention to what is the latest and greatest hardware. I mostly just care about it being something different and, well, there's quite a bit that's different today so I'm able to keep myself pretty amused (that counts for something - more than some people give it credit for) and I'm always learn

--
"So long and thanks for all the fish."
Re:What? by KGIII · 2016-01-27 12:35 · Score: 1

Heh, I should have scrolled down. I made a bit of a long winded post about that and about how I'd buy it just 'cause it's open AND assuming it'd be likely to work properly without a problem. The thing is, for the most part, shit already all works without a problem. Linux, it just works. It's so different than what it used to be. Now? It generally just works. Maybe, maybe once in a while, do I need to tweak something, find and compile something with a patch, edit a config file in a text editor, or install the proprietary drivers - I don't even normally bother with those!
I figured there were more of us. Yes, I do tend to buy a bit of hardware but that's because I'm a geek. The reality is, I could probably be just fine on a 10 year old computer. 32 GB of RAM is more than enough - and I can't tell a difference when I have 64. I'm actually fine with 8 GB and could manage with 4 if I needed to. I don't game nor do I care if my documentary is in high definition - I don't watch anything else.
So, yeah, I'll buy it just to support "open" (and assuming it works). I might even, over time, buy quite a few. I won't be buying the latest and greatest GPU. I just don't bother any more. I'm only going to keep it for maybe six months and then donate it to someone or put it up while I play with something new. I don't even invest in the greatest and most powerful CPU. I just buy a reasonably speedy AMD - almost always AMD. I usually buy nVidia GPUs but I don't mind changing that. They're usually a generation or two behind, I guess. I don't even pay attention to that any more?
I don't need the latest I7. I'm fine with a reasonably modern AMD. I don't need blazing graphics - my browser's not gonna look a whole lot prettier in 4k, I know - I've checked. I don't even default to streaming video in high def. So, for what it is worth - and probably not a whole lot, I'll buy it. I still prefer my desktops and laptops - I hate the tablets (and I've tried them all - except I did kind of like a Surface Pro but I guess it's not got very good Linux support yet, but when it does that may change) and I don't really care about phones - I actually have a Windows phone as I was sick of Android. It does fine for what I use it for.
As I said above - I have no idea how much my market segment is actually worth to them, probably not a whole lot, but I'll buy it just to support "open" so long as people are reporting that they're working well and don't require that I do a whole lot to get them to work properly. So, whatever that market is worth, it's their's for the taking if they want it.

--
"So long and thanks for all the fish."
Re:What? by KGIII · 2016-01-27 13:09 · Score: 1

I don't know if I should hate you or thank you. *sighs* Here I go, ordering another couple of SBCs to play with. Why? Well, it looks like I'll be able to chuck Lubuntu 16.04 on it. Lubuntu is my favorite OS but I'm not really sure if I'll really appreciate the changes to LXQt instead of my beloved LXDE. I didn't order it just yet but I probably will be. I want to do some research and see what people are saying.
How much of the Ubuntu ecosystem is going to run native on it or will I have to either cross-compile or compile it on the PINE64? It is using the AllWinner and, to be honest, I've had less than stellar luck with enjoying their performance on tablets. However, I don't really like tablets so that might not be the fault of AllWinner.
You should keep us updated by sneaking comments into various threads so we can see what's going on in your case. I don't want to run ChromeOS, SteamOS, or Android. I want a full blown Linux and Lubuntu is a pretty good choice there because it's fairly light. I'll get maximum RAM and whatnot but 2 GB of RAM is not going to be enough if I have to compile a bunch of stuff.
So, I'll keep an eye on yet another SBC project. As this one is already shipping and had no problems with its funding, that's a good sign. They're priced rather reasonably, even for the Plus model. It does appear to lack a GPIO set but that can be remedied. I'm not really sure that it's designed to be used quite like that.
I'll have to keep an eye on yet another project. It's something that I'm not sure if I should be grateful for or if I should bitch about it. There really are a whole lot of these things out there now. I guess that's a good thing. It does, kind of, spread developer time/talent around pretty thin. I'm not entirely sure what I'd do with these but I could probably come up with an idea or ten. So thanks, I guess. ;-)

--
"So long and thanks for all the fish."
Re:What? by kyubre · 2016-01-27 13:23 · Score: 1

I'm going to make an interpretive guess, and assume that if streaming video services is your thing, you'll want to be running Android.
As for myself, I do 99% of all my work via network connections to big iron somewhere far away. My main workhorse for such things is an old T500 Lennovo running PC-BSD and the i3wm window manager (fudging awesome).
The FreeBSD port to Arm is shaping up very nicely and I wouldn't mind contributing some effort to it myself, but my rational hope is to get Arch up and running on the Pine with reasonable video for the kind of terminal work I do all day long.
None of the Chrome stick type gadgets would suit my needs, but I'm hopeful to be able to make something with the Pine A64.

--
Nothing evolves faster than the word of god in the minds of men who think themselves divinely inspired.
Re:What? by KGIII · 2016-01-29 20:16 · Score: 1

Sorry for the delayed response. I had issues. That said, I hate Android. No, I really hate it. I've not even had good interactions with it on high end tablets. I hate it so much that I have purchased a Windows phone.
It should be noted that I have not tried ChromeOS and I've never, ever, had Android that didn't rely on an OEM. That may be why I dislike it but, regardless, every interaction that I have had has been poor. I could go out of my way to try new things or, alternatively, I can go where I know I'll be happy enough. That means that, for better or worse, I'll probably end up trying to get/keep Linux on it - and not the bastard-child that is Android. I don't mind BSD. I actually like BSD but there are a couple of pieces of software that I use that keep me from migrating. Yes, they're trivial seeming and there are alternatives but I have my preferences for a reason.
That said, it's amusing that you mention the networking aspect. I am, right now, connected to my computer in Maine (via my laptop here in Florida) and posting this message from that desktop. I offload as much as I can and use virtual machines frequently. Why do I like Linux (or BSD) so much? Well, I've a pretty frail (but redundant and with options built-in) connection to my home computer. It probably shouldn't even be still working. It probably shouldn't have worked at all. Yet, I've been on wanderlust since September and here I am - with no degradation in service. Hell, I've even made some upgrades and improvements.
Arch would be viable. BSD is not actually my preference but I can live with it. From what I read, some form of Lubuntu is supposed to work and that's ideal. By pure happenstance, that's absolutely ideal - or could be. How much of the repo is going to be pre-compiled and how much will I have to sort out on my own.
I do have to wonder - is it worth my time to find a way (I've got a few bucks really, more than I will need if we gotta be honest about it) to get some hardware to someone who will compile for this? It looks like some is going to be done already but I have no idea how much and what that will look like in the end. It may seem crazy but I'd happily buy 'em some hardware to keep a current compiled state for the entirety of the repo or, at least, everything in there that is necessary AND the Lubuntu-specific software. It may seem crazy but I'd buy 'em a pretty decent rig for it. I am, technically and mistakenly, on the Lubuntu dev team and mailing list. No, I have no idea why they let me on the dev team and I actually thought I was applying for something else. I guess I could ask there. I'd seriously (I know it will help more than me) throw them some money to build something nice and cross-compile for it. I have no qualms about chucking them enough cash to buy a box with a bunch of cores and enough RAM to be meaningful.
I think I'll fire off an email over the weekend and see where that goes. Someone on the dev team is both bound to know and to know how I can help. While I do have some time, I'm not certain enough of my own skills to do much more than close my eyes and throw money at it until the problem goes away. It's not always a solution but I've had some luck with it in the past. Even a fairly decent server is not a whole lot of money these days but a really nice workstation should be adequate? They can cross-compile this all. One of the nice beefy AMDs and 64 GB of RAM should be enough, no? It has been a long time but I used to compile C on a lot less than that and it was a rather large lot of code. Depending on what was being built, it might have even taken a long time but it's not like it had to be monitored the whole time.
I'm pretty sure it would help more than just me. Yeah, I'll ask 'em in the dev mailing list tomorrow and see where it goes from there. I may end up not using it but, if nothing else, it's sure to help a bunch of people. If I've got a financial investment, I'm more likely to actually get off my ass and do some more learning. That's an added benefit.

--
"So long and thanks for all the fish."
Re:What? by kyubre · 2016-01-30 04:28 · Score: 1

I'm really rather curious as to what you can't do on BSD that you can do on Linux today, with the exception of some hardware support.
In terms of app support, there are very few useful open source projects that haven't been ported to FreeBSD/PC-BSD. The exceptions take the form of binary blobs built by vendors (Chrome, Flash, VirtualBox). But even with those, there are truly open source subsets that retain a great deal of functionality. On FreeBSD, I've switched over to Xen for virtualization and use KVM on Linux. Via libvirt and friends I can fairly effortless share VMs between Linux and FreeBSD with very similar setup scripts.
Things that rely upon Oracle Java can also be a source of frustration. That being said, there is a Centos 6 binary compatible API for FreeBSD that can run the native versions of things like the JRE and Flash.

--
Nothing evolves faster than the word of god in the minds of men who think themselves divinely inspired.

keep waiting by Anonymous Coward · 2016-01-26 09:20 · Score: 0

all 7 or 8 of you might get your wish one day.

Another year, another AMD open source 'effort' by Anonymous Coward · 2016-01-26 09:23 · Score: 0

Let's see if they actually deliver anything this time....

AMD optimizations = vendor lock-in by sanf780 · 2016-01-26 09:24 · Score: 0

You do not really want to go back to vendor APIs like twenty years ago. It did not save 3DFX then, it may not save AMD GPU division now. You really need to get Vulkan working, and you need to get GNU/Linux drivers performance and numbers of bugs to a reasonable level.

Re:AMD optimizations = vendor lock-in by JustNiz · 2016-01-26 10:09 · Score: 2

I agree with all your points, but it seems that AMD might be trying to do another end-run like they did with AMD64 extensions that are now the industry standard that even Intel copied/now use.
Re:AMD optimizations = vendor lock-in by CrashNBrn · 2016-01-26 10:30 · Score: 0

Hehehe that would be classic.
Re:AMD optimizations = vendor lock-in by Kjella · 2016-01-26 11:26 · Score: 2

You do not really want to go back to vendor APIs like twenty years ago. It did not save 3DFX then, it may not save AMD GPU division now. You really need to get Vulkan working, and you need to get GNU/Linux drivers performance and numbers of bugs to a reasonable level.
It would be very different this time, today the shader (pixel, vertex, geometry, tessellation, compute) is the core of almost all GPU processing. Twenty years ago it was all fixed-function hardware, the first programmable shader support was in DirectX 8.0 back in 2000. Basically you had high level calls and the hardware/driver could implement it however they want, so how one card did it would be totally different from the other. Today they have to run the same shader code efficiently, sure there's still some abstraction but more like compiling C to assembler.
The open source drivers have already more or less done this internally with Gallium3D, you have a low level shader API and a common graphics library implementation running on top. The difference is that Vulkan will be a client API and implemented by proprietary drivers and on proprietary platforms, which means you get ~100% availability instead of a fraction of the Linux market. But users can still pick CUDA if it works better for them, the same way many pick Windows-only software over cross-platform alternatives. It won't perform miracles for AMD...

--
Live today, because you never know what tomorrow brings
Re:AMD optimizations = vendor lock-in by Anonymous Coward · 2016-01-26 13:59 · Score: 0

do not think the current AMD is anywhere near that savvy...
Re:AMD optimizations = vendor lock-in by Anonymous Coward · 2016-01-26 14:02 · Score: 0

except that ship has sailed as nvidia's gameworks have already created exactly that.
AMD's open source alternative the OPPOSITE of what you are claiming it is. it is a potential cure for the ill of closed propitiatory vendor lock in game optimizations.

So where's all the stuff? by Fragnet · 2016-01-26 09:24 · Score: 1

Not much there is there. A couple of tools only. Hardly worthy of a big announcement.

In Soviet Russia, GPU opens you by Geoffrey.landis · 2016-01-26 09:26 · Score: 0

I think the GPU should be open, but you do have to realize that the Gosudarstvennoe Politicheskoe Upravlenie (GPU) hasn't been around since the Soviet Union ended decades ago (in fact, it merged with the NKVD back in the '30s.)

https://www.marxists.org/archi...

--
http://www.geoffreylandis.com

Re:Translation:quit optimizing for Intel technolog by indi0144 · 2016-01-26 09:31 · Score: 1, Informative

How about they open a few QA jobs and don't make available the stillborn of a software that is "Crimson" I was a loyal AMD fanboy since the K6 era, And and ATI loyal from around the same time, but my last CPU from them was a Phenom, I got tired of waiting for a decent replacement and went with intel, now I'm trying to camp with this old HD7750 because I love the passive cooling and don't really need much video performance for games, but the drivers are making it hard for me to keep supporting them, (yay new actual improvements in performance and such, too bad it crashes anytime you wan to switch a tab in the control panel and your settings get eaten by the grue randomly), truly Alpha quality right there.

AMD want to go backwards? by bloodhawk · 2016-01-26 09:32 · Score: 0

The last thing we want is for the PC to go back to the days when you had to have specific support for the graphics card in your games. PC's had to have the hardware abstracted to allow you to choose whichever card vendor/chip manufacturer you wanted without having to worry about whether it will work in your games. Consoles don't have this problem as they are fixed hardware specs and hence you can code close to the metal. Does abstraction offer the best performance? NOPE, but it is a fuck load better than worrying about compatibility for every fucking thing.

Re: AMD want to go backwards? by IBME · 2016-01-26 09:37 · Score: 1

No but you do. This has nothing to do with your detraction and more to do with making computing as a whole better.
Re: AMD want to go backwards? by Anonymous Coward · 2016-01-26 09:59 · Score: 0

This doesn't make computing better, we ditched this disastrous path 20 years ago because of the agony it creates. basically you trade of compatibility, ease of programming and simplicity in exchange for better performance. we are long past the days when every fraction of a percent of performance on the client side is an essential gain.
Re: AMD want to go backwards? by Anonymous Coward · 2016-01-26 10:25 · Score: 0

we are long past the days when every fraction of a percent of performance on the client side is an essential gain.
For average people, yes. But they don't buy expensive cards. This is a feature for AAA games and library devs. Their target market is gamers, and these guys want the performance and are willing to pay for it.
Re: AMD want to go backwards? by Anonymous Coward · 2016-01-26 10:36 · Score: 0

BULLSHIT. AAA games do not want to customise for hardware, this is a support nightmare and added cost for very little gain for them and high end gamers would get pissed off pretty damn quick as they find they have to wait for game optimisations or support because EA fucked up some optimisation for COD for their card.
Re: AMD want to go backwards? by IBME · 2016-01-26 11:33 · Score: 1

Again, try to stop thinking everything is about speed. That in a nutshell: opening up to possibilities, and the future of computing in general for consumers, is really the point here. Try imagining a computing system unlike anything heretofor. All this nonsense about how you've seen it all before is useless because the future is going to be whatever we make it. Taking in the great leaps in how powerful and small things are today and comparing it to 20 yr old hardware etc. is truly the problem. We ARE capable of better, but ONLY if we literally pool our resources. Rather simple to a simpleton.
Re: AMD want to go backwards? by IBME · 2016-01-26 11:38 · Score: 1

And maybe I didn't mention it but the pc world does not actually revolve around "games" either.
Re: AMD want to go backwards? by Anonymous Coward · 2016-01-26 11:46 · Score: 0

you need a serious reality check. While in some small niche areas optimisation with hardware level access is great, in general for consumers it is fucking aweful. This really is exactly what we saw back in the 90's with Sound hardware and Video hardware. It is a nightmare for consumers and even worse for devs. Basically AMD are losing and losing bad so they are trying to change the playing board and bring back vendor lockin.
Re:AMD want to go backwards? by Anonymous Coward · 2016-01-26 12:36 · Score: 0

The last thing we want is for the PC to go back to the days when you had to have specific support for the graphics card in your games.
You mean the days like, right now? Both DirectX and OpenGL already offer access to specific card features or extensions which drastically differ between models and vendors.
They're not talking about dropping support for standard APIs, but making the internal features more available and exposing how they work. You can still use OGL or DX to your hearts content. Even if you're not using custom interfaces, you may be able to create tighter, more optimised versions of your shaders (for example), knowing how they're compiled and executed behind the scenes.
It feels like this is more aimed at number crunching or GPGPU than games, but if a game benefits from it it is fine - and if the developers of that game choose not to support standard APIs on cards from other vendors, well, they're cutting off more than 50% of their market.
I personally have disliked ATi for a long time, as I value reliability and consistency over any raw performance edge they may have had. However, this kind of thing makes me respect them a bit more. They're trying to be more useful, targeting high-value niche applications (like large scale GPGPU clusters) which both helps their bottom line and their user community as a whole.
Re:AMD want to go backwards? by Anonymous Coward · 2016-01-26 14:05 · Score: 1

did you live under a rock for a couple of years? nvidia's gameworks has basically already created vendor lock games!
this GPUopen initiative has the potential to UNDO that damage, not cause more of it.
Re: AMD want to go backwards? by IBME · 2016-01-29 13:42 · Score: 0

I just look forward to a future where the drm, spying, ad plagued, computing world is free to innovate and progress like it is supposed to. I don't quite think amd asking for more openness and working together is tantamount to vendor lockin. But whatever ye seek ye shall find.

Re:Translation:quit optimizing for Intel technolog by ShanghaiBill · 2016-01-26 09:34 · Score: 5, Informative

Translation: quit optimizing for proprietary Intel technology

This is not targeted at Intel. It is targeted at NVidia. They are looking to the future when GPGPU is expected to be a bigger slice of the GPU market. NVidia currently dominates with their (proprietary) CUDA interface, while AMD relies on the less efficient OpenCL. More openness will help AMD (and Intel) while working against NVidia.

In almost all markets the dominant company will prefer to push their proprietary solution, while companies with smaller market shares will push openness.

Open Drivers for the cards first!! by Anonymous Coward · 2016-01-26 09:35 · Score: 0

before you worry about having open APIs and docs for running things on the video card, you need to open all the APIs and docs for controlling/configuring/running the card first.

Sounds awesome but the demos are weaksauce by Anonymous Coward · 2016-01-26 09:36 · Score: 0

It sounds like a portentous announcement then you go to the site and its just a bunch of typical devrel demos you're expect of any GPU vendor. DX11 demos, GPGPU samples? OK but that's not even slightly revolutionary.

Re: Sounds awesome but the demos are weaksauce by IBME · 2016-01-26 09:42 · Score: 1

And so is overpriced and overclocked gaming hardware. Weaksauce

Re:Translation:quit optimizing for Intel technolog by CajunArson · 2016-01-26 09:43 · Score: 2, Informative

What's all "proprietary" about Intel graphics exactly?
Their open source support in the Linux kernel is substantially better than AMD's half-assed "sorta kinda open when we feel like it for obsolete parts" approach.

Another thing about this "open" concept that nobody is really talking about amidst the cheerleading: AMD is trying to push *proprietary* AMD-only hardware features that don't fit very well with current APIs -- and that includes Vulkan, BTW, not just the old APIs.

So what are they doing? They are "open sourcing" a relatively thin layer of code that exposes their proprietary GPU features to work *outside* of any cross-platform APIs.

So basically, they open source some relatively low-value shim code for their hardware so that they have an excuse not to make bug fixes since that's been handed over to the community. Meanwhile, the "open source" AMD product is actually encouraging software developers to write code to *non-standard AMD features* that aren't part of any accepted API that would work across platforms.

Just because some code is open sourced doesn't make it a happy "open" cross-platform experience, and there needs to be a little more critical thought applied to this media event.

--
AntiFA: An abbreviation for Anti First Amendment.

Linux: the BET of operating systems by retchdog · 2016-01-26 09:45 · Score: 0

Linux is to the hardware market as BET is to the cable TV market. If you're having trouble selling your product, you can just deal with the free software crowd to up your sales for as long as you can stand it. Sure, it's not nearly as profitable, and yes, they will occasionally whine about their "rights" and inevitably accuse you of betraying some kind of confidence, but at least in the short-term they'll be so grateful for the recognition that they'll put up with your shit and do a lot of promotional work for you.

--
"They were pure niggers." – Noam Chomsky

Re:Linux: the BET of operating systems by jedidiah · 2016-01-26 09:51 · Score: 1

...except for the inconvenient fact that the "highly proprietary" Nvidia kit sells very well for Linux and is very well supported. When Linux Journal was still printed on dead trees, they had a number of ads from vendors selling big fat expensive GPU compute boxes. There was usually and ad of this sort on the back cover.
System 76 sells a box like this. Include all of the bells and whistles (including 4 GPUs) and it might be more expensive than your car.

--
A Pirate and a Puritan look the same on a balance sheet.
Re:Linux: the BET of operating systems by retchdog · 2016-01-26 10:24 · Score: 1

yeah, i don't see how that contradicts my point. it just means that nvidia's product is so desirable (for whatever reasons) that linux users are willing to deal with the proprietary drivers. AMD, in second place, wants to up their numbers by "opening" their stuff and offloading the work onto the community. there's nothing wrong with that, of course, but that's what it seems like.
and apropos of nothing, i don't own a car. i have an nvidia card in a linux box though. :)

--
"They were pure niggers." – Noam Chomsky
Re:Linux: the BET of operating systems by Gavagai80 · 2016-01-26 20:03 · Score: 1

The problem is that AMD has been talking about open GPU drivers for so many years, and yet nvidia is still the more reliable choice on Linux to avoid driver headaches.

--
This space intentionally left blank

I wonder what their motivation is by JustNiz · 2016-01-26 10:03 · Score: 1

I wonder if this is a sign that AMD have completely given up trying to compete against nVidia on outright top end performance gpu-for-gpu (which they've never managed to really pull off) and are now refocussing their strategy to compete based on openness instead. That certainly would seem to be striking at the heart of nVidias biggest perceived weakness, and would probably get them a lot of instant converts/new customers at least in the Linux world, where nVidia have traditionally been more dominant at least partially because of compute.
I bet nVidia will quickly come back with their own new announcement around an alternative "open source" initiative that will at least superficially sound good, but will "purely coincidentally" let them keep their drivers closed.

Re:I wonder what their motivation is by gweihir · 2016-01-26 19:05 · Score: 1

From actual performance comparisons, it does not look like AMD has given up at all. I also would say that HBM is not a sign of having given up either.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Translation:quit optimizing for Intel technolog by Anonymous Coward · 2016-01-26 10:04 · Score: 1

while companies with smaller market shares will push openness.

Because they want to leverage free labor, then they will close it off. Notice how Google has done it on Android (play services, core apps going closed)?

In any case this is now a challenge for the open source community, typically the open source drivers have been quite poor in comparison to the proprietary ones so now is the chance for the community to back their claims that open source is better.

Open by phorm · 2016-01-26 10:06 · Score: 1

Well, in most senses one could hope that open != proprietary, in which case it should be something *all* vendors can standardize on.
Better than three vendors with closed solutions.

Re:Translation:quit optimizing for Intel technolog by exomondo · 2016-01-26 10:15 · Score: 1

Another thing about this "open" concept that nobody is really talking about amidst the cheerleading: AMD is trying to push *proprietary* AMD-only hardware features that don't fit very well with current APIs -- and that includes Vulkan, BTW, not just the old APIs.

Seems like you're thinking of Mantle (which is of course the basis for the Vulkan work) but Vulkan - like OpenGL - will be an open specification, not proprietary.

The idea is not to fit with current APIs because current API paradigms are not well suited to modern hardware. For example a lot of the workload is serial and so cannot leverage any significant amount of the available CPU power, Vulkan (and DirectX 12) change this and allow multiple threads to do things like create and submit command buffers in parallel. Another part of it is that the resource management of the current high-level APIs is just an abstraction of the generic driver implementation so we see performance gains when the power of the hardware is exploited through explicit application-specific optimizations made in the driver by the vendor working with the game developer. Vulkan and DirectX 12 break from this by transferring the onus of low level resource management to the game developer so they can fully utilize the hardware in the way they need without being hamstrung by the driver.

How about time for consumer CPUs without a GPU??? by Anonymous Coward · 2016-01-26 10:18 · Score: 0

I do not game and I do not watch movies on my PC. I want CPU with raw horsepower, not video. Please stop forcing me to buy graphics hardware I'm never going to use. Give me a god damned CPU where the whole fuckin' die is CPU or cache.

Re:timing by greenfruitsalad · 2016-01-26 10:29 · Score: 3, Interesting

this recent behaviour of AMD (vulkan, freesync, hbm, gpuopen, etc) reminds me of the last days of Sun Microsystems. they also opened up a lot of their stuff just before they went tits-up. i sincerely hope it's not what's happening with AMD now.

Re:How about time for consumer CPUs without a GPU? by avandesande · 2016-01-26 10:31 · Score: 1

Get a pentium4 that uses a huge amount of silicon!

--
love is just extroverted narcissism

The "old" stuff isn't THAT bad... by CrashNBrn · 2016-01-26 10:44 · Score: 2

Something like this Lenovo IdeaPad Y700: AMD A10-8700P, 15.6" (1920x1080), 8 GB RAM + 4 GB Radeon R9 M380
seemed pretty decent to me, especially when your budget is less than $1500 and preferably $1000.

Re:The "old" stuff isn't THAT bad... by Arkh89 · 2016-01-26 11:14 · Score: 1

(*) Drivers not included.
Re:The "old" stuff isn't THAT bad... by __aaclcg7560 · 2016-01-26 13:15 · Score: 1

At that price point, I'll buy an Intel CPU/motherboard combo. I'm looking for an updated AM3+ processor. Although I did hear rumors of an AM4 socket coming out this year.

Re:Translation:quit optimizing for Intel technolog by MrNiceguy_KS · 2016-01-26 10:44 · Score: 1, Flamebait

Alternate translation: Would somebody who knows what they're doing please fix our crappy drivers?

--
Redundancy is good And also good.

Re:How about time for consumer CPUs without a GPU? by Anonymous Coward · 2016-01-26 11:04 · Score: 0

So stop whining and buy a HEDT i7.

It's time to give everyone a gold medal. by Snufu · 2016-01-26 11:04 · Score: 0

Said the gal winning bronze.

Re:Translation:quit optimizing for Intel technolog by RogueyWon · 2016-01-26 11:10 · Score: 4, Interesting

It's aimed at Nvidia, not Intel, and it's all about hair.

Or rather, it's all about Nvidia GameWorks, which got a lot of attention this year thanks to a number of bleeding-edge games, most notably The Witcher 3.

The horribly over-simplified tl;dr version is that Nvidia have been encouraging PC developers to use a set of closed-and-proprietary tools, which allow for some remarkably pretty in-game effects but more or less screw over AMD cards.

This, combined with the fact that Nvidia has, in general, better driver support, quieter and more power-efficient cards and, at the top end of the market, better single-card performance, has put AMD into a pretty bad place in the PC graphics card market right now. Yes, they still tend to have a slight price-to-power ratio advantage, but the quality of life drawbacks to an AMD card, combined with the GameWorks effect, has driven down their market share and, right now, makes it hard to recommend an AMD card.

There are no "goodies" or "baddies" here. Nvidia's GameWorks strategy is undoubtedly fairly dubious in terms of its ethics. At the same time, they are putting out better (and more power-efficient, so also on one level more environmentally friendly) cards (and the GameWorks effects can be VERY pretty), while AMD continues to put out cards that burn with the heat of a million fiery suns and have long-standing, unaddressed issues with their driver support.

Hey AMD, show us your new CPUs for 2016 by steveha · 2016-01-26 11:21 · Score: 5, Informative

Hey, AMD, show us your new CPUs for 2016. Everything you got now is long in the tooth.

How right you are. But their basic problem has been that they were still stuck on old semiconductor fabrication processes. Intel has spent a bunch of money on fab technology and is about two generations ahead of AMD. It didn't help that their current architecture isn't great.

I'm not a semiconductor expert, but as I understand it: the thinner the traces on the semiconductor, the higher clock rate can go or the lower the power dissipation can be (those two are tradeoffs). Intel's 4th-generation CPUs were fabbed on 22 nm process, and their current CPUs are fabbed on 14 nm process. AMD has been stuck at 28 nm and is in fact still selling CPUs fabbed on a 32 nm process. It's brutal to try to compete when so far behind. But AMD is just skipping the 22 nm process and going straight to 14 nm. (Intel has 10 nm in the pipeline, planned for 2017 release, but it should be easier to compete 14 nm vs 10 nm than 32/28 nm vs 14 nm! And it took years for AMD to get to 14 nm, while there are indications that they will make the jump to 10 nm more quickly.)

But AMD is about to catch up. AMD has shown us their new CPU for 2016; its code-name is "Zen" and it will be fabbed on a 14 nm process. AMD claims the new architecture will provide 40% more instructions-per-clock than their current architecture; combined with finally getting onto a modern fab process, the Zen should be competitive with Intel's offerings. (I expect Intel to hold onto the top-performance crown, but I expect AMD will offer better performance per dollar with acceptable thermal envelope.) Wikipedia says it will be released in October 2016.

http://www.techradar.com/us/news/computing-components/processors/amd-confirms-powerhouse-zen-cpus-will-arrive-for-high-end-pcs-in-2016-1310980

Intel is so far ahead of AMD that it's unlikely that AMD will ever take over the #1 spot, but I am at least hoping that they will hold on to a niche and serve to keep Intel in check.

The ironic thing is that Intel is currently making the best products, yet still they feel the need to cheat with dirty tricks like the Intel C Compiler's generating bad code for CPUs with a non-Intel CPUID. Also I don't like how Intel tries to segment their products into dozens of tiers to maximize money extraction. (Oh, did you want virtualization? This cheaper CPU doesn't offer that; buy this more expensive one. Oh, did you want ECC RAM? Step right up to our most expensive CPUs!)

Intel has been a very good "corporate citizen" with respect to the Linux kernel, and they make good products; but I try not to buy their products because I hate their bad behavior. I own one laptop with an Intel i7 CPU, but otherwise I'm 100% non-Intel.

I want to build a new computer and I don't want to wait for Zen so I will be buying an FX-8350 (fabbed on 32 nm process, ugh). But in 18 months or so I look forward to buying new Zen processors and building new computers.

--
lf(1): it's like ls(1) but sorts filenames by extension, tersely

Re: Hey AMD, show us your new CPUs for 2016 by Anonymous Coward · 2016-01-26 12:45 · Score: 0

So you are 90% non Intel, 75% non Intel... What's the number? Sure as shit isn't 100%.
Re: Hey AMD, show us your new CPUs for 2016 by CrashNBrn · 2016-01-26 13:04 · Score: 1

100%* Baby! Not that it matters. The wife has some Macs though.

(*) Although I don't know about my first white-box 0x86 PC, the 386, 686, and beyond have been AMD. Plus ARM, TI, etc in portable devices.
Re:Hey AMD, show us your new CPUs for 2016 by Anonymous Coward · 2016-01-26 18:33 · Score: 0

It'll probably take a day or two till it hits the english frontpage, so here's the translator link to the german news article regarding "Zen" on Tom's Hardware: Summit-Ridge/Bristol Ridge News
Re:Hey AMD, show us your new CPUs for 2016 by TheRaven64 · 2016-01-26 22:17 · Score: 1

I'm not a semiconductor expert, but as I understand it: the thinner the traces on the semiconductor, the higher clock rate can go or the lower the power dissipation can be
That was true until about 2007. Then we hit the end of Dennard Scaling. Now you get more transistors, but your power consumption per transistor remains quite similar and so you need to be more clever. That's much easier on a CPU than a GPU because CPUs run quite a wide variety of workloads and so there are lots of things you can add that will be a bit win for a subset of workloads but not consume power at other times. On a GPU, it's harder because they tend to saturate a lot more of the execution engines that they ship with.
As for higher clock rate, that's sort-of true, but bumping the clock rate has a big impact on power consumption and so you don't get very much from it either.
Also, with the newer processes the yields are often lower and so, even though you can pack more on a wafer, once it's not going to be much cheaper (especially not once you factor in the need to recoup the $100bn that you spent on R&D to get the new fab up and running - you need to amortise that across a lot of chips to make it worthwhile).
In summary, being a generation behind is far less of a disadvantage than it was a decade ago.

--
I am TheRaven on Soylent News

AMD dies it every 5 years by loufoque · 2016-01-26 11:45 · Score: 0

Every 5 years, AMD makes a big announcement like they're going to open up their technology.
None of these efforts were maintained, it felt more like "we're giving up on this old architecture, but here are the specs, in case you want to do our job in our place".

I'll be more impressed when they can commit in the long term.

Re:AMD dies it every 5 years by Anonymous Coward · 2016-01-26 14:11 · Score: 4, Insightful

except they actually have opened up their technology, and very often they've opened up NEW technology. from AMD64, to HT link to their GPU specs (resulting in open source AMD drivers rivaling the propitiatory drivers in speed, and being MILES ahead of nvidia's open source drivers (which don't even have support for ANY 9xx series cards yet)).
tressFX is going to release 3.0 soon, mantle formed the basis for vulkan and now we get openGPU.

Groovy by Anonymous Coward · 2016-01-26 12:18 · Score: 0

Works for me, if it starts of trend towards more stable open source graphics support, maybe an pivot towards security hardening of graphics software infrastructure and away from epically high framerates, whatever those are good for.

Re:Translation:quit optimizing for Intel technolog by exomondo · 2016-01-26 12:28 · Score: 1

Sure that's true for PC exclusives but you do have to remember that a lot of games these days target multiple platforms and if you're targeting the major consoles then any nVidia-specific tools/libraries are not an option.

Re:How about time for consumer CPUs without a GPU? by Blaskowicz · 2016-01-26 13:20 · Score: 1

If you fill the whole die with CPU cores and cache (plus northbridge, ring bus etc.) you end up with a CPU that needs to be in the 130W to 160W range. Now unlike 10-12 years ago the power management is competent, but it reeks of egg-frying monstrosities of old.

Alternatively let's say Intel makes it a low power chip, so that it fits with Intel's power-limited consumer motherboards. You get a choice of a 10-core processor at 2GHz, instead of a 4-core processor at 4GHz with built-in GPU. That is pretty worthless. Give me fewer cores and 4GHz.

Also you won't find a graphics card low end enough for you tastes, lest you go with an antique one on PCI slot or the simplified 2D-only VGA-only controller found on sever motherboards.

Re:Translation:quit optimizing for Intel technolog by Anonymous Coward · 2016-01-26 14:16 · Score: 0

radeonSI was a virtual match for the proprietary drivers 6 months ago (with a development patch).

but that isn't at all what openGPU is all about.

Patents? by rsilvergun · 2016-01-26 14:20 · Score: 1

How will this work without the patents? The trouble with open sourcing it is that it's almost guaranteed that AMD has stepped on a few nVidia patents. Hell the patent mess is half the reason nVidia never went whole hog on open source.

Also this does smack of desperation :(... Good luck AMD.

--
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/

Re:Patents? by gweihir · 2016-01-26 19:09 · Score: 1

I expect they will know enough on what Nvidia infringes to give them a quiet but effective warning to not go down that road.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Translation:quit optimizing for Intel technolog by tepples · 2016-01-26 16:46 · Score: 1

a lot of games these days target multiple platforms

Do Windows, OS X, GNU/Linux, Android, and iOS count as "multiple platforms"?

Re:timing by Anonymous Coward · 2016-01-26 16:50 · Score: 2, Insightful

Recent?

Do you remember what was the first operating system to get AMD64 support back in early 2000's? That's right, Linux.

Also mid-2000's when AMD purchased ATI, first thing they did was throwing out documentation for open source developers to develop better drivers, also they have invested millions in development of open Linux graphics stack, and this happened very early on. They've always been pretty open, this is not recent behavior.

Nvidia, holding like 70-80% of the market share, does afford to close things down and stuff proprietary techs down your throat, but AMD as the underdog, does not. Openess is their best bet.

Re:timing by Anonymous Coward · 2016-01-26 17:01 · Score: 0

My initial reaction was along those same lines, I didn't make the comparison to Sun but it's a good one. As a long time customer of AMD this all strikes me as strange and worrisome. Perhaps it's because if I were CEO these are the kind of moves I would make to cement the legacy of the corporation before closing up shop, allowing the community to continue the work. We need some fantastic products in 2016, so far the Fury-X hasn't worked out so great although HBM is set to make a big difference in the second generation of cards to implement it. If AMD is still around, that is.

Re:How about time for consumer CPUs without a GPU? by gweihir · 2016-01-26 19:07 · Score: 1

The Next AMD generations will offer that, on the same AM4 socket as the APUs. For the last offerings, the socket was different, but you still had both choices with AMD.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Translation:quit optimizing for Intel technolog by RogueyWon · 2016-01-26 19:24 · Score: 1

Actually, most of the games which have used GameWorks to date have been multi-platform games. For the most part, and with the odd dishonourable exception, the days of lazy, barebones PC ports are behind us. Developers are quite happy to spend time optimising PC versions, including through the use of Nvidia-specific tools/libraries.

The Witcher 3 was the highest profile example and, if you have the hardware to drive the GameWorks stuff (there is a serious performance cost), then it looks astounding next to the console versions.

Re:Translation:quit optimizing for Intel technolog by aliquis · 2016-01-26 20:03 · Score: 1

No. It's about Nvidia.

Re:Translation:quit optimizing for Intel technolog by aliquis · 2016-01-26 20:15 · Score: 1

My impression is that the AMD performance with hair comes from poorer tessellation performance on the AMD cards.

So that one could likely be solved by just making them better at tessellation.

Nvidia is of course happy throwing in lots of fur and hair in games if the performance hit is low on Nvidia cards and high on AMD cards leading to worse performance numbers for the AMD Cards in said games and more sales of Nvidia cards.

Re: Translation:quit optimizing for Intel technolo by Anonymous Coward · 2016-01-26 20:25 · Score: 0

It's not about Intel you fool, its more about Nvidia's proprietary behaviour. Team Oculus already has some very talented engineering teams trying to optimize GPU output and obviously open standards technology will assist them 100%

Re:Translation:quit optimizing for Intel technolog by Anonymous Coward · 2016-01-26 21:45 · Score: 0

https://www.youtube.com/watch?v=O7fA_JC_R5s&index=1&list=LLCJpBDIrDto4teu-dXPWEXw

Re:Translation:quit optimizing for Intel technolog by TheRaven64 · 2016-01-26 22:10 · Score: 1

What's all "proprietary" about Intel graphics exactly?
Their open source support in the Linux kernel is substantially better than AMD's half-assed "sorta kinda open when we feel like it for obsolete parts" approach.

Add to that, Intel publishes incredibly detailed ISA specs for their GPUs. They have some quite neat features in some of them, such as a two dimensional register file, where operands to instructions are identified by a base and a stripe size, so you can load four vectors horizontally (e.g. 4 pixel values) and then compute on them vertically (e.g. red values, green values, etc) without needing to do any vector shuffle operations. You can also do diagonal operations, which makes the code very dense as you rarely need to do any permute operations.

--
I am TheRaven on Soylent News

Re:Translation:quit optimizing for Intel technolog by StormReaver · 2016-01-27 00:04 · Score: 3, Insightful

There are no "goodies" or "baddies" here.

There are now. AMD, through necessity, has chosen the right path. NVidia, through ability, has chosen the wrong path.

Even now, when AMD cards perform worse than NVidia, I have started choosing AMD for both personal and professional use because of the Open Source AMD drivers. AMD's doubling down on Open Source has validated that decision, and I will likely never buy, nor recommend to my customers, another NVidia card.

I have completely inverted my recommendations for Linux video. It used to be, "buy NVidia and be done with it," since AMD's driver was a huge pain in the ass to get working on Linux. But Open Source has a powerful appeal to me, having been burned over and over again by proprietary business practices over the decades, and now my recommendation has switched to AMD for the same reason.

Re:Translation:quit optimizing for Intel technolog by Anonymous Coward · 2016-01-27 03:20 · Score: 0

This is fact. Witcher 3 is an amazing game, may be Game of the Decade. I started playing it with an AMD card. There were a whole bunch of arcane ini edits I had to make to get it to just barely perform, any cutscene video still stuttered like heck with the video getting way behind the audio towards the end of it, not to mention plenty of outright pauses in regular gameplay.

Ended up buying an nvidia card that was just maybe one gen up from that AMD card and one price slot down, and bam, game flies, no hint of bugginess anywhere.

Love that game, but those devs really doubled down on the nvidia teat for it.

Re:Translation:quit optimizing for Intel technolog by iampiti · 2016-01-27 06:06 · Score: 1

I'm not an expert on these things but I think what happens is that you have a "basic" effect if you don't have the appropiate hardware and a "pretty" one if you have. That's the case for example with Batman Arkham City: If you have an Nvidia card on a PC you get pretty but non-essential-to-gameplay graphical effects and you get simpler effects otherwise (consoles or AMD cards on PC).
tl dr: The games usually work on several platforms but have extra effects on PCs with Nvidia cards.

Re:Translation:quit optimizing for Intel technolog by Jesus_666 · 2016-01-27 08:04 · Score: 1

Actually, I got my R9 390 precisely because of quality. Nvidia had this embarrassing thing where the cards they marketed as being DX12 compatible weren't, in fact, fully compatible with DX12. Some missing functionality had to be done in software, at a noticeable performance cost. That's what made me choose AMD as I want my card to last me a few years, probably well into when DX12 will actually matter.

And it's not the first time Nvidia released a product that only technically did what it was supposed to do. I still distinctly remember the GTX 970 which had two gigs of memory, only 1.5 gigs of which you could use without significant performance losses. But hey, technically it had two gigs! You just couldn't use a quarter of the memory.

Recently, every time I was in the market for a GPU, Nvidia's offer was theoretically good but ultimately failed to impress because of some corner they'd cut without informing anyone before launch. AMD might have mediocre drivers and less explicit support from games but at least I don't have to expect zany caveats.

--
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)

Re:Translation:quit optimizing for Intel technolog by exomondo · 2016-01-27 09:42 · Score: 1

Well yes, but of course Windows, OS X & GNU/Linux are all, generally speaking, the PC platform as you can very often run 2 or more of those operating systems on the same hardware. This is not true of iOS, Android or the console operating systems.

Re:Translation:quit optimizing for Intel technolog by exomondo · 2016-01-27 09:45 · Score: 1

Yes that's pretty much correct, nVidia provides extra, easy-to-use tools to exploit their hardware so some developers will invest some time in them. But that's obviously only for extra non-essential things.

Re:Translation:quit optimizing for Intel technolog by exomondo · 2016-01-27 09:49 · Score: 1

Actually, most of the games which have used GameWorks to date have been multi-platform games.

Yes but that's only for completely non-essential things, you can't use it for anything you absolutely must have. If AMD provided something akin to GameWorks (TressFX is coming along slowly, and was even used in Tomb Raider) then developers will use that to improve the visual fidelity on AMD GPUs (including consoles).

Re: Translation:quit optimizing for Intel technolo by Redbehrend · 2016-01-27 10:07 · Score: 1

Amd is trying to do the right thing and keep the market moving into a better standard. Nvidia pays under the table to developers and gives away tons of free stuff so these game companies would use them. Nivida is closed source and how they work with the industry is killing pc vs console. Note that nvidia said they are going to use AMDs new hardware standard yet give nothing back. That's how they roll.... Take all and give us higher prices. Amd does it for money but at least they are trying to do the right thing. It's better than not trying at all....

Re:timing by Anonymous Coward · 2016-01-27 11:50 · Score: 0

LOL I took the liberty of looking at your comment history, just the first page, and have you actually ever said anything that was moderated up? 'Cause calling people a fucking moron (correct or incorrect) seems to be about all you actually contribute.

Re:Translation:quit optimizing for Intel technolog by tepples · 2016-01-27 14:59 · Score: 1

Windows, OS X & GNU/Linux are all, generally speaking, the PC platform as you can very often run 2 or more of those operating systems on the same hardware.

For a Windows-exclusive game, each player on OS X or GNU/Linux will need to buy a Windows license. For a Mac-exclusive game, each player on Windows or GNU/Linux will need to buy a Mac.

But my point is that even though AMD won the eighth console generation, a lot of games don't target consoles because the organizational overhead isn't worth it, especially games from a smaller developer that hasn't already released three pay-to-play games. And if the NVIDIA-specific libraries are also available for the Tegra chipsets, then a multi-platform release across Windows, GNU/Linux, and Android can still make use of NVIDIA-specific libraries.

Re:Translation:quit optimizing for Intel technolog by exomondo · 2016-01-27 15:45 · Score: 1

I get that you're trying desperately hard to be pedantic but how does any of that affect what I said?

Re:Translation:quit optimizing for Intel technolog by Waccoon · 2016-01-27 15:57 · Score: 1

That's all nice and well from the Linux side of things, but it's the Windows market that makes them money.

I stopped buying AMD graphics cards because the Windows drivers kept shitting themselves and making my life miserable... consistently over a period of many years. Even with their driver [branding] overhaul, it's going to take a lot of time to rebuild trust and convince me their hardware is worth buying again. That's not NVidia's fault.

Re:Translation:quit optimizing for Intel technolog by Anonymous Coward · 2016-01-27 16:12 · Score: 0

I'll believe it when I see the *full and complete set of sources released to the low level firmwares*. Writing an "open source" wrapper around a proprietary core doesn't count. AMD and Intel are guilty of sacrificing our control for there benefit. I don't want backdoors. I do want to know what the code running on my system is doing. No, having the complete set of code is not security, but you can't begin a serious conversation about security without it.

Re:Translation:quit optimizing for Intel technolog by tepples · 2016-01-28 01:52 · Score: 1

Trying again based on clarifications provided in your other posts:

if you're targeting the major consoles then any nVidia-specific tools/libraries are not an option.

But if a dev isn't yet eligible to target consoles, it's more likely to get suckered into this crap.

Re:Translation:quit optimizing for Intel technolog by exomondo · 2016-01-28 09:30 · Score: 1

But if a dev isn't yet eligible to target consoles, it's more likely to get suckered into this crap.

If a dev isn't eligible to target consoles then they aren't targeting consoles are they? (yes, that is a rhetorical question)

Re:Translation:quit optimizing for Intel technolog by Anonymous Coward · 2016-01-28 22:10 · Score: 0

> AMD continues to put out cards that burn with the heat of a million fiery suns and have long-standing, unaddressed issues with their driver support

Here we go again with the old anecdotes.
Actually the heat one is new to me, it was previously reserved for AMD CPUs. My current HD 7870 runs at 80-85C under full load, is this too much now? Used to be normal.
And what's with the driver support? I've used 5 or 6 different ATI/AMD GPUs, no long-standing issues. Granted, the Catalyst UI was crap. The new Radeon Settings is even bigger crap. Good thing there's usually no need to use those UIs.

Re:Translation:quit optimizing for Intel technolog by Anonymous Coward · 2016-01-28 22:16 · Score: 0

Just to counter your experience, I've been using ATI/AMD since x600 (2004), even on Windows XP x64. No problems.

Re:timing by Anonymous Coward · 2016-01-30 00:30 · Score: 0

Yes, LOL.

Doesn't make it any less correct. LOL.

LOL.

Slashdot Mirror

AMD: It's Time To Open Up the GPU (gpuopen.com)

152 comments