It does seem that MS is pushing double support, which is a good sign. One of the slides mentions the importance of this for scientific applications.
I definitely like that the compute shader uses HLSL - a consistent interface for accessing the GPU. I also think it’s cool that the pixel shader can now perform scattered writes and access read-write structures (no more ping-ponging?).
Looking it over, it looks pretty general to me - there is a slide in there that mentions how it’s “optimized for client scenarios” (GAMES) - but it basically says it can use more general data structures instead of just floats, which is good for everything I’d think.
I’m definitely keeping an eye on OpenGL/OpenCL though, since I could see MS dropping support for something in an instant just because it isn’t useful in games (D3D10 has no equivalent to glLogicOp, for instance).
Even with things like “compute” shader, it still means that you add certain features to a given/fixed (pseudo programmable) pipeline model. (vertex,raster,pixel…). Which is a longer process as adding to each stage over time, will cost time, time as Cass said could be put into something, that would allow everyone to more “generally” write their own software renderers
I.e. people themselves get to design their custom pipeline more easily (depending on the given helper functionality of that -G). And the only one trying to sell that vision of this being possible in the future again is Intel with Larrabee. And eventhough noone knows how efficient of a GPU it will be, they for sure sell the idea of “custom change”.
Which is more of vision than the “faster faster” of current vendors, which we know is coming anyway. The question is more how to let people come up with new ways to make use of all that speed.
And that is harder when you stick to people thinking of what they can forge with their hammer, when they should be thinking about what to do with their hands.
nevertheless I feel the lobby again just isnt there, as “change” is always sensitive to humans. Eventhough the days of all software engines aren’t that long ago, and I still miss some of the voxel engine’s or all painted lucas looks and wowed over the palette shifting effects in the games. I hope we will see a return of the diverse look of games some day again, and not just x different approaches to making most efficient use of def. shading, ssao, more hi-res textures… but this is more of a feeling I cant back up with personal experience into the matter as others here can.
I am secretly hoping that Larrabee comes along and owns everything out there currently, but I have a number of concerns.
[ul][]It is my understanding that Larrabee still has special texture-related hardware. So what should this be called, a general purpose SIMD device that happens to have texture hardware?[] The upcoming tessellation stage requires special hardware. Can this be implemented efficiently on Larrabee?[*] Not really a concern, but just a note: I don’t believe that “shader models” will disappear completely. I believe that there will be versions of Larrabee, each with different capabilities (i.e., more shared memory, faster texture HW, etc…)[/ul]I suppose what really matters here is that enough people are interested in it and back it so that it is improved. I am excited by the idea of being able to modify a pipeline in its entirety.
The main thing I don’t like with compute shaders in DX11 is that they’re shoehorning general purpose programming into a model meant for graphics. Graphical rendering has very rigid and well-defined inputs: linear buffers and formatted textures. It has rigid and semi-defined outputs: framebuffers, or occasionally other buffer objects.
A true compute shader, like OpenCL, needs more than that. It really needs direct access to specific memory locations. It needs to be able to DMA memory dynamically. It needs to be able to use pointers and so forth. Etc.
I hope we will see a return of the diverse look of games some day again
If games don’t look particularly diverse, it is the fault of the game developers, not their tools. If everyone’s using shaders to go for photorealism, then everyone will look the same.
True, Korval, I hadn’t even thought about pointers yet.
Looking over the OpenCL spec again, it does look pretty promising. The fact that it can run across GPUs and CPUs is nice.
Call me crazy, but I would really like a consistent interface by which I can hack around on my GPU. Whether that be an implementation of the OpenGL or D3D pipeline implemented in OpenCL that I can freely edit, or D3D11…
korval, as I worked as artist before, I am well aware of the possibilties of change in the current pipeline. Yet I think there would be more diversity in looks beyond stylized toon textures/fresnel shaded stuff, if pipeline could be more custom.
though you are right, and I mentioned as well, “change” often simply doesnt happen, due to people sticking to whatever they are used to. (psuedo realism…) So probably I expect too much “innovation” even if more severe changes were possible.
Not really. What we really want are the materials and tools necessary to make our own hammers.
With that, I can make my own hammer if I need to, but if OpenGL isn’t exactly the kind of hammer I need, I can make a lump hammer instead. And if I don’t need a hammer at all, I can use those same tools to make screwdrivers and saws and speed squares.
I’m skeptical of an OpenCL-G type language successfully being designed by committee. Something like that is more likely to succeed if the first (proprietary) version comes directly from a hardware company. In graphics hardware, note GL (not OpenGL), Glide, and CUDA. Those APIs proved how something was possible and then standards grew from those successes.
Ok, Glide didn’t evolve into a standard but it demonstrated the power of consumer level hardware.
I’m sure the Larrabee API will be out before any other similar API. After that, an OpenCL-G API might arise to “compete” with its success.
There’s the obvious current analogy: CUDA to OpenCL. I’d argue that an OpenCL would not be feasible (as soon) without CUDA.
V-man, I don’t think there’s any reason to build the “conventional GL” atop CL. But for a new graphics system that is radically more flexible than GL3, CL may be a better foundation. Obviously, I have argued that it is, but others should draw their own conclusions.
I share your skepticism, pudman. It may just not be reasonable to expect true innovation from open standards bodies. Perhaps we can hope for a shorter time between proprietary and open though.
I’d personally rather see GPUs go more general purpose.
Yet I don’t see how Larrabee’s cache coherency and fine grain locking is going to continue to scale well. Plus the amount of work to manually vectorize code, hide latency, and control caches using C/C++ (+Larrabee intrinsics) to program Larrabee seems too time consuming to me. One thing our current graphics (and CUDA) APIs do right IMO is providing a programming abstraction which is both easy to program, and results in high performance code for these massively parallel machines.
The real point isn’t just to build GL on top of CL; that wouldn’t give us anything more than what we already have. The point is to ensure that something as powerful (albeit, maybe slightly less efficient) as GL can be built on CL.
Keeping them separate as they are today, means there is no single API that would expose entire GPU to programmer. Todays 3D graphics APIs and GPGPU APIs have large functionality overlap, but each side also holds exclusive access to certain areas. Resource sharing between CL and GL doesn’t alleviate the problem enough.
As long as there is fixed function stuff in GPUs, it’s desirable to have direct access to it from GPGPU APIs. In Larrabee, the only fixed-function stuff is the texture sampling unit. This is the part also already accessible from CUDA/CTM/CL, so Larrabee is all set. However, in the existing GPUs, most stuff except shaders is still fixed function.
Consider things like post transform vertex cache, producer-consumer chain between VS, GS and PS, dynamic allocation of processors for different pipeline stages, clipping, blending, depth, stencil, etc. Try to imagine implementing them in pure CL/CUDA/CTM.
This stuff is still fixed function, because this way the entire chip has better performance. If it weren’t, nVidia and Ati would have had their Larrabees 2 years ago.
Even putting aside the discussion about future of GL and 3D APIs in general, I don’t see a reason to disallow GPGPU APIs to tap to these resources.
As long as there is fixed function stuff in GPGPU, it’s desirable to have direct access to it from GPGPU APIs.
Yes, but then you’re completely non-portable. What happens when that functionality disappears in the next generation of GPUs? Or if you go from an nVidia chip to a Larrabee (which won’t have most of that)?
They most certainly do not. They don’t expose the post-T&L cache, dynamic allocation of processors, etc. The most they expose are the per-fragment operations and the rasterization stuff. Everything else is an internal optimization of the hardware.
You as a user of GL have no control or even knowledge of the post-T&L cache, for example. You cannot tell the system how many processors to allocate to task X. And so on. These are things that have been abstracted; they’re performance optimizations.
Your meaning of “expose” is different than mine. I don’t think my post indicated that I desire breaking abstractions of this stuff already provided by GL and DX.
Where did I say I need such control or even knowledge? “tap to these resources” means to be able to benefit from it’s performance, as much as a 3D API client. Just that.
Korval, really, it’s next to impossible to have discussion in your presence without you misinterpreting obvious statements and “reading between the lines” and “connecting the dots”. Perhaps I should, just for you, write my comments like EULAs, paying attention to remove even tiniest ambigities, so that I could avoid wasting time to correct you?
Many of the things we tend to view as graphics-specific could be recast into more general terms. Probably wouldn’t be too difficult to map most of the concepts in graphics to more generic constructs. Like blending… heck that’s just basic math. Stuff like depth/alpha testing… simple comparisons. Have to be pretty clever to generalize something like early-z in a meaningful way, but then maybe there’s something better that does generalize nicely (come to think of it, early-z is really just a depth-range comparison).
Anyhoo, I’m not convinced this is an either/or proposition. Greater control doesn’t rule out the possibility of graphics-specific hw features, where they make sense.
)