Quoting: mr-eggthere must be some sort of obvious driver bottleneck here on AMD. The fact that it catches up at ultra and that overall the performance is holding quite well.

fAilMD again. Keep hearing about the opensource drivers catching up to catalyst, then we remember catalyst is a lot slower than it should be. How are AMD going to manage to get all existing openGL games ( 1400 ) upto scratch and ready for SteamOS ? Vulcan may help new titles but Vulcan is only going to be supported on the latest cards and that leaves all 1400 ( maybe near 2000 ) by the time they get the performance right, games in a weak or broken position.

honestly, Valve should of made SteamOS exactly as they have done now, but with a fixed performance baseline using a 780Ti/980Ti and allowed for AMD as a option just because its possible. Then each year support better and faster Nvidia cards.

Which is sort of happening but they should just come out and state it as a target. It might at the very least get AMD to wake up.

being equal on Ultra would probably mean something completely different. from my experience this would be limit at which rest of the computer can feed to gpu, but that would only be possible to be sure about if benchmark included cpu utilization.

when you hit cpu bottleneck it doesn't matter if you have Titan X or Iris 4000. computer simply cannot feed frames which could be rendered on gpu and you end up with under utilized gpu where both will render same amount of frames as long as they can since limitation is elsewhere

also, there is one shiny spot in future. Vulkan and its simpler drivers should be able to create equal standings for all vendors. AMD is probably betting on the fact that next gen could finally enable them to catch up with times and get rid of ATi past with terrible drivers

View this comment - View article - View full comments

Quoting: mmstickI tried Witcher 2 on Linux one month ago and it still runs significantly worse than running the Windows copy through Wine with Gallium Nine. Indeed, I would very much prefer that non-native ports are abolished henceforth and never allowed onto Steam. Non-native ports are not the way, nor will they ever be. Fixing a bug in a native port is easy, but resolving a bug in a non-native port? I don't think so. Either do a port correctly the first time or don't do a port at all. No port is better than a bad port.

you do realize that you're one of minority and you don't even realize what you claim?

since you use galium nine, you're using OSS drivers. OSS drivers already have lower performance and when you stuck them with one additional layer like wine conversion of directx to opengl, you're bound to have performance problems. but, those performance claims are only valid in case like yours

galium nine avoids whole conversion to opengl. it is also only usable to people running OSS and AMD (no clue about Nouveau, if it needs recklocking then it might as well ignore it because Maxwell doesn't support even basic one).

galium nine is useless to people with
- Intel
- people with AMD running Catalyst
- people with NVidia
in short, galium nine is useless to majority of people. everyone else has much better luck with command stream or eON than with possibility that does not exist for them

View this comment - View article - View full comments

flash required? guess i'll wait for recording, there is no way in hell i'm installing that crap

View this comment - View article - View full comments

Quoting: maodzedunSo none of the big engine developers have made commitments to Vulkan so far - no CryEngine, Unreal or Unity 5. Worrisome. At the same time DX12 games will begin coming out this month (well there was technically one last month... sort off). At the same time Vulkan is not released yet. The more they take their sweet time, the more developers will get comfy with DirectX12. I wonder when do we reach the point of no return. Valve will really have to pull an ace from their sleeve or the Steam Machine premiere will be quite anticlimactic.

according to Tim Sweeney, Vulkan on UE4 is already in full swing of development

update: also, it would make no sense at all to go with DX12 and Vulkan at once being that they are similar. just looking at their slides you can see how deep they are in DX9 and old principles. the slide, DX12 running in 1 thread says everything. multithreading is same important to Vulkan too and without it... neither DX12 nor Vulkan can work efficiently

View this comment - View article - View full comments

Quoting: SabunFrom the slides (since there's now way currently to actually see the live presentation), it would seem their ONLY focus is DX12. That really sucks. DX12 will only benefit the Windows Desktop platform and possibly Xbox One.

This leaves out:
1. Android
2. iOS
3. Linux desktop
4. Mac OSX desktop

They write in the slides that DX12 forced them to cleanup code, which benefited all the other platforms as well. I doubt it's anything truly significant though.

This will mean near future versions will still have the hampered OpenGL 2.1 code they're using for Linux. This was a disappointment to me, since I make use of Unity3D almost every day. I was looking forward to more OpenGL pro-activeness with the recent announcement of the Linux IDE in the works.

no, it doesn't suck even the least. unlike previous where DX and OpenGL were different in basics like simple coordinate system, this time around they are both
- based on Mantle (according to DICE developer, porting between DX12 and Vulkan is much more trivial than it was from DX to OpenGL)
- they use almost same approaches all around
- DX12 final spec is out, Vulkan is not yet
- cleanup code is significant, mostly to the fact Unity was DX centric. even difference between DX11 and DX12 is huge compared to DX12 and Vulkan

best thing Linux could do is forget OpenGL and move to next big thing as fast as possible. just implementing OpenGL in Mesa with Vulkan would solve 99% of problems OpenGL has since it would be singular implementation across all vendors and cards that are Vulkan compatible, which is most of the cards out there. maybe not as fast as native driver, but in 2 years it won't matter anyway since hardware is getting faster and faster

View this comment - View article - View full comments

Quoting: Zelox

Quoting: vulture

Quoting: ZeloxI hope vulkan can and will support sli and multimontor setups.
At the moment linuxs is useless when it comes to sli and gaming with more then one montior.

Sadly.

no, it won't. sli/crossfire is obsoleted by both vulkan and directx12. with those you can control each and every gpu (even if they are from different vendor).

sli like feature in the game will be up to developer, not up to drivers

Aah so simple, directx12 and vulcan already "supports it" kind off? I know u said sli is dead or are heading that way. But if u simplefi the it a bit.
The developer have to press the ON button so I can use both gpus and the reselution I want in there game.

And for me as a user, I will be able to have the option in the games setup menu, to change to a bigger reselution, and thats it. If the game supports more then 1 screen / higher reselution.

This is like the main reason I dont use linux 24/7 when I game.
Sry for my english, been a long day.

SLI never had some real gains, at least not perf/money. you spent a lot of money for a little more (and then sometimes even less performance). i don't know if this analogy will work, but SLI is more or less like raid device. software only sees partition on which it can write, how this will happen is up to raid driver. but, unlike raid... SLI is far from simple to guess how to work effectively. and game only sees that one SLI setup as its graphic card.

for a driver to guess how to split workload for a game... well, it could as well be driver for each game.

with DX12/Vulkan game can use each GPU and his VRAM with direct control and full power as long as developer made it so and cpu can actually handle workload without creating bottleneck. it is much more efficient, but it also needs more developer work on enabling it.

support for multiple screens is simpler this way and yet... more complex :)

View this comment - View article - View full comments

Quoting: MyeulCThanks everyone for this information. I have one more question : since DX12 is very similar to Mantle [External Link], we can expect it to be very similar to vulkan, right ? Will it make a difference in the porting effort to vulkan ? Or is it something we don't know for sure yet?

according to DICE representative working on Vulkan, porting between the two is trivial since both use exact same approach. add to that SPIR-V (which at least for me is most interesting part) and porting is even easier. SPIR-V is intermediate language and you can create compiler that produces it from anything, HLSL included.

View this comment - View article - View full comments

Quoting: MyeulCI hope mesa devs will come up with a cross-vendor multi gpu solution for vulkan, though, unless it is exposed directly by the api ?

cross vendor multi gpu is part of Vulkan and direct access to gpu, no need for Mesa to do that

View this comment - View article - View full comments

Quoting: Eike

Quoting: Guest4) It takes a bit of effort. New API, developer experience, and approach to the engine are all factors - the last in particular may make it simply not worthwhile. Newer games on newer engines are where the first appearances are likely to be.

I've got a question as well. As far as I understood, Vulkan and the new DirectX are lower level APIs than their predecessors, and so it will make way more work to implement something in Vulkan or DirectX 12 than in OpenGL or DirectX 11. Is this correct?

yes, and no. (don't know Vulkan, but i do a lot of low level programming)

writing something in pure low level would take enormously lot of work. but, when you do that you're not just writing low level whole time. you create methods to leverage and reuse that work, so it doesn't make much difference in the end. in fact, usual amount of debugging is much lower when you work with low level, since there were no complex blocks you wouldn't have access to

but, making app like game where performance matters will never be 100% of just making it. lot of that will go into profiling and optimizing. that is something that is so much harder if you can't optimize at low level. with high level you need to create workarounds.

one another thing that will be much simpler is threading, which is not really nice with older DirectX or OpenGL. both, DirectX12 and Vulkan have threading as part of their nature

View this comment - View article - View full comments

Quoting: wolfyrionI am getting impatient with Vulkan, I want to see it in Action and I have more than 1000 questions to ask about it :o

For Example:

1.As far as I know Vulkan needs new drivers from Nvidia to utilize Vulkan api , right?
2.So Dota 2 is using source 2 but since there are no drivers that support vulkan api it means that Dota2 is not utilizing Vulkan api, that goes for all platforms, right?
3. Game Engines are going to utilize Vulkan Api? So whatever games are already on Linux are going to get new builds with Vulkan Api support? So we can see Shadow of Mordor utilizing Vulkan Api?
4. How easy or hard to convert the current games to support Vulkan API?

meh... lots of things to ask , I better stop here :P

1. no, the hardware portion is more or less the same, vulkan is equivalent to libGL
2. if there are no drivers yet, how would it?
3. not every one. making vulkan into borderlands 2 which is on Unreal 3 would not make sense from financial point, especially since 3 won't ever get Vulkan support . only new engines will probably utilize it. somewhat like UE4 has --opengl4
4. if there is no public API yet... you expect guessing?

View this comment - View article - View full comments