Gallium3D OpenCL GSoC Near-Final Status Update

[bridgman]

BTW if you use Rxxx terminology didn't we already ship R900 ?

R6xx - HD2xxx, HD3xxx
R7xx - HD4xxx
R8xx - HD5xxx aka Evergreen
R9xx - HD6xxx aka Northern Islands

Now you get to guess about numbers as well as names

[Silverthorn]

in easy words amd switch from VLIW+SIMD to an RISC+SIMD Design.

means bigger chip and more heat but easier to write drivers for it.

for opensource drivers this is a good news because of the lag of manpower..

Lack of manpower isn't entirely true. It's more a lack of money/funding. There are probably plenty of people who which to work (full time) on an open source project like this, as long as they get a decent salary.

[89c51]

Lack of manpower isn't entirely true. It's more a lack of money/funding. There are probably plenty of people who which to work (full time) on an open source project like this, as long as they get a decent salary.

lack of manpower usually refers to the current situation. ie small amount of payed devs + contributors


of course you cannot demand from anyone to work for free unless he wants to.

[bridgman]

in easy words amd switch from VLIW+SIMD to an RISC+SIMD Design.

Yeah, I guess, but that implies RISC is new, which it isn't. Probably more clear to say VLIW + RISC + SIMD to RISC + SIMD, at which point RISC becomes redundant so you drop it out anyways.

[bridgman]

means bigger chip and more heat but easier to write drivers for it.

Hmm... the easiest chip to write drivers for is the one that is already supported by the drivers we have. The new architecture is easier to write applications for, but on balance it's probably harder to write drivers for the new architecture than for the old one.

The new architecture does open up the possibility of using some new tools in the driver stack (ie ripping out what already works and putting something new and unfamiliar in its place then going through another few years of learning curve) but that doesn't align with any definition of "easy" I have ever used

[bridgman]

if you can answer this question with yes then it is easier : "would it be more complex and harder to learn of amd do the same new architecture with VLIW ?"

then its easy compared to an VLIW version.

I'm not having much luck parsing the question. What does "it" refer to ? Driver development (harder) or application development (easier) ?

[bridgman]

the question is not the existet architecture it's not about the old or the new architecture its about a fiktional architecture. if you build a fiktional architecture with the same feature set and useing VLIW insteat of a risc part would it be easier to build a driver for it ? you claim thats its harder to write a driver for an risc architecture than for an VLIW one.

If we are comparing fictional parts the question is even harder to answer, since programming difficulty usually doesn't come from the basic architecture but rather from all the things you have to add (eg fixed function hardware for textures and for export) to make the architecture run real fast on specific workloads such as graphics. VLIW parts map naturally onto graphics since you can deal with all the components in a single instruction group, and things like texture and export processing are easier because all the components are lined up nicely in the hardware. Assuming the same team designed both parts on the same process, same die size, at the same time, my guess is that the VLIW part would be easier to program for graphics and the non-VLIW part would be easier to program for compute.

but all i read in the past calls me that if there is the same featureset an VLIW cpu is allways harder to get optimations.

It's harder to optimize for full utilization of VLIW hardware, but since the peak performance of VLIW hardware is usually higher than non-VLIW hardware on the same die area (because relatively more of the space can be used for ALUs) the question is whether it is harder to optimize VLIW hardware to the same performance level you would get from an equivalently sized non-VLIW part.

As always, the final answers depend on the workload -- if you are talking about simple-to-medium complexity graphics which naturally contain a lot of float3 and float4 operations then the same amount of optimization work would probably get you higher performance on the VLIW part. For compute, it's the other way round - float4 operations aren't all that common unless they are coded into the application, so non-VLIW is easier to optimize for and you can probably get higher performance from the same silicon area with non-VLIW.

It's probably worth mentioning that everything you read about VLIW CPUs refers to compute, not graphics -- I haven't seen similar analyses of VLIW vs non-VLIW GPUs running typical graphics workloads.

[bridgman]

Did you happen to see a movie called "The Last Boy Scout", with Bruce Willis ?

If so, we're at that scene in the strip club where, after some increasingly unfriendly discussion... (other guy) "you're starting to pi** me off"... (Willis's character) "it's about f-ing time"... puts hand up to shake and introduces himself. Now we can talk.

VLIW has all kinds of benefits -- there's a reason we're still using it across the board today -- it's a no-brainer for graphics and even offers the best performance in hand-tweaked compute apps. The questions are (a) whether we can rely on hand-tweaked compute apps as GPU compute becomes more common, (b) whether compiler technology can eliminate the need to hand-tweak application code in the future, and (c) whether it's possible to create a non-VLIW implementation which can maintain most of the advantages of VLIW.

[bridgman]

i think i need to watch the movie first to unterstand you..

What I meant was "now you've argued both for and against VLIW, we're ready to talk about nuances, compromises and tradeoffs". When you are dealing with both compute and graphics, one architecture isn't obviously better than the other, and what you want is somewhere in between.

long discussion for an simple point AMD just want an easier to handle Architecture. and "Less" hand optimizations in code meas "easier" and you still think its harder to write driver for it ?

Again, you keep combining things and looking for absolutes where they don't exist. Writing a graphics driver stack will probably be harder, writing a compute driver stack will probably be easier. That's not the point though -- nobody changes architectures to make writing drivers easier. The point is that writing performant compute *applications* will be easier on a non-VLIW architecture.

[plonoma]

Hello,

I've uploaded a new version of the documentation online at http://people.freedesktop.org/~steck...ver/index.html . The front page now says that OpenCL 1.1 is implemented, many new classes are documented, and I directly uploaded the documentation from my computer instead of producing it on the Freedesktop.org server. It is now beautiful !

Thank you.
It looks great, good work/job. ( I really mean that.)