Comments on: Predicting the Past http://www.realtimerendering.com/blog/predicting-the-past/ Tracking the latest developments in interactive rendering techniques Mon, 17 Jun 2013 03:17:13 +0000 hourly 1 http://wordpress.org/?v=3.4.1 By: gilbazoid http://www.realtimerendering.com/blog/predicting-the-past/comment-page-1/#comment-2054 gilbazoid Fri, 30 Sep 2011 22:59:25 +0000 http://www.realtimerendering.com/blog/?p=2637#comment-2054 I kind of have the feeling that the audience for graphics APIs has changed substantially since their introduction, and the APIs don't really want to admit it. Are the APIs primarily about providing access to hardware, or are they about creating a rendering abstraction so you don't have to worry about that? They seem slightly too high level for the former and definitely too low level for the latter. Wouldn't it be reasonable to try to design future graphics card APIs with the goal of providing a good hardware abstraction? Then you could ignore whether or not it was a good abstraction of the rendering/graphics application, which would probably clean things up. Sure, still keep all the special function hardware, but make it an add-on not the core of the API. And then on the other side, push for some standard reasonably efficient graphics/rendering engine APIs that make the process of getting 3d rendered much simpler. Companies that want more performance can always write their own graphics engines, but we could admit this would be a very small number of people. I kind of have the feeling that the audience for graphics APIs has changed substantially since their introduction, and the APIs don’t really want to admit it. Are the APIs primarily about providing access to hardware, or are they about creating a rendering abstraction so you don’t have to worry about that? They seem slightly too high level for the former and definitely too low level for the latter.

Wouldn’t it be reasonable to try to design future graphics card APIs with the goal of providing a good hardware abstraction? Then you could ignore whether or not it was a good abstraction of the rendering/graphics application, which would probably clean things up. Sure, still keep all the special function hardware, but make it an add-on not the core of the API.

And then on the other side, push for some standard reasonably efficient graphics/rendering engine APIs that make the process of getting 3d rendered much simpler. Companies that want more performance can always write their own graphics engines, but we could admit this would be a very small number of people.

]]> By: palgorithm http://www.realtimerendering.com/blog/predicting-the-past/comment-page-1/#comment-2053 palgorithm Thu, 29 Sep 2011 18:11:48 +0000 http://www.realtimerendering.com/blog/?p=2637#comment-2053 Hi Eric, Totally agree. I was also interested in Samuli Laine's paper, and for the same reasons. The graphics APIs - which to be fair, are still protecting us all from a lot of unwashed hardware laundry - are increasingly getting in the way. It's even worse in mobiles/tablets. Seriously programmable graphics has been flitting in and out of the background chatter for a while. It's a great shame that Larrabee didn't come to pass, as this would have put greater focus on this topic. CUDA is the current best vehicle. The most common criticism of software graphics is the obvious performance and power implications of dropping custom hardware. But I still feel this is an unfair comparison. Comparing a hardware implementation of a graphics api to the same api but in software will always appear favourable to hardware. But we should instead be comparing what we can do with a more flexible pipeline against it's fixed hardware equivalent. This would be a subjective comparison, and currently impossible as very little serious creative effort has gone into the former. Like most things, I suspect a compromise position will succeed. You can currently mix CUDA and graphics code. It's not perfect, but it does give you the best of both worlds. You can then just see which part gets greater utilisation in practice and respond to market demand. Cheers, Sam Hi Eric,

Totally agree. I was also interested in Samuli Laine’s paper, and for the same reasons. The graphics APIs – which to be fair, are still protecting us all from a lot of unwashed hardware laundry – are increasingly getting in the way. It’s even worse in mobiles/tablets. Seriously programmable graphics has been flitting in and out of the background chatter for a while. It’s a great shame that Larrabee didn’t come to pass, as this would have put greater focus on this topic. CUDA is the current best vehicle.

The most common criticism of software graphics is the obvious performance and power implications of dropping custom hardware. But I still feel this is an unfair comparison. Comparing a hardware implementation of a graphics api to the same api but in software will always appear favourable to hardware. But we should instead be comparing what we can do with a more flexible pipeline against it’s fixed hardware equivalent. This would be a subjective comparison, and currently impossible as very little serious creative effort has gone into the former.

Like most things, I suspect a compromise position will succeed. You can currently mix CUDA and graphics code. It’s not perfect, but it does give you the best of both worlds. You can then just see which part gets greater utilisation in practice and respond to market demand.

Cheers,
Sam

]]>