LibreSOC Still Striving To Produce An Open-Source Hybrid CPU/GPU Built On OpenPOWER

[pal666]

we evaluated llvmpipe a long time ago, it has severe performance limitations

it has best performance per dollar spent though. and this hardware "is not for doom eternal". llvmpipe renders desktop just fine

[lkcl]

it has best performance per dollar spent though. and this hardware "is not for doom eternal". llvmpipe renders desktop just fine

you missed the significance of the single-threaded bottleneck. an eight core system running LLVMpipe has 7 cores sitting idle due to a critical bottleneck inherent in the design of LLVMpipe.

[lkcl]

RISC-V NDA scam...

to be fair to them, it's to protect "Commercial Confidence". for example if there are discussions where one company has to reveal their plans to sell 1 billion units as a justification before anyone will take their participation seriously, this is "Commercial Confidential", and it's perfectly reasonable to expect participants to agree to that. it was the failure to speak to us *at all* - to even enter into any kind of dialog - that was the root of the problem.

[pal666]

you missed the significance of the single-threaded bottleneck. an eight core system running LLVMpipe has 7 cores sitting idle due to a critical bottleneck inherent in the design of LLVMpipe.

i heard swr is good at multicore. in any case you have to solve driver issue one way or another, but it doesn't require designing hardware at any step. just improve llvmpipe or write something else, you have to do it anyway

[WorBlux]

the PowerVR patents expired a while back, but it's a long waiting game.

Just rampant speculation here... do you think Apple's M1 is a reverse of the original PowerVR, or that they got a design license?

well we can partly make up for that with the OoO execution (just like they do in POWER10). we can put in multiple 16-wide SIMD units for example.

But the challenge is can you keep them busy? OoO is certainly new territory for a graphics accelerator and will certainly help. Maybe you get by with 2-3 threads instead of 4-8. But of course the big boys have had a lot of time to iterate and I don't think it's reasonable to think your first version will be perfect. Nor does it need to be, just recoup the NRE and a little extra and ver. 2 and 3 can make the obvious improvements, and be the real test of this approach.

[WorBlux]

i heard swr is good at multicore. in any case you have to solve driver issue one way or another, but it doesn't require designing hardware at any step. just improve llvmpipe or write something else, you have to do it anyway

It's also heavily tied to AVX and GL compliance is incomplete. From what I can tell writing a vulkan driver, and then relying on Zink/DxVK to provide other API's is the fastest way to bring up a new graphics architecture.

[Old Grouch]

succeeds in "making llvmpipe gpu" or in "magically making it fast"?

Oddly enough, neither of those options. A commercially available and viable FLOS cpu. But I'm sure you knew that.

[pal666]

Oddly enough, neither of those options. A commercially available and viable FLOS cpu. But I'm sure you knew that.

for that you only need to take one of available opensource riscv designs and produce it. subj is about gpu.

[lkcl]

Just rampant speculation here... do you think Apple's M1 is a reverse of the original PowerVR, or that they got a design license?

Imagination let their patents expire: the announcement of the new GPU by apple was timed just after that. Imgtec's CEO went mental, and had to be told by his lawyers, "yeahh you screwed up by not keeping an eye on the patents".

But the challenge is can you keep them busy? OoO is certainly new territory for a graphics accelerator and will certainly help. Maybe you get by with 2-3 threads instead of 4-8. But of course the big boys have had a lot of time to iterate and I don't think it's reasonable to think your first version will be perfect. Nor does it need to be, just recoup the NRE and a little extra and ver. 2 and 3 can make the obvious improvements, and be the real test of this approach.

yehyeh. Jeff Bush's approach is the "guide" here - if you read his paper he created a metric "pixels / clock" and goes to some lengths to work out which stages of a Shader spend the most cycles. he was then able to try (i think) 7 different design modifications to improve on that: some of them software, some in hardware (but limited to adding general-purpose compute instructions only).

we'll replicate that approach... but include hardware 3D custom opcodes. trouble is, right now, everyone's asking, "what's the performance what's the performance" and until we have a first iteration in place (until we have replicated what Jeff did) we simply can't answer.

l.

[pal666]

It's also heavily tied to AVX and GL compliance is incomplete. From what I can tell writing a vulkan driver, and then relying on Zink/DxVK to provide other API's is the fastest way to bring up a new graphics architecture.

zink's gl compliance isn't complete either. writing vulkan driver requires writing driver, llvmpipe is already available. and you can write different gallium backend no harder than write different vulkan driver. also there's lavapipe