[J-core] 2D unit

[Timothy Arceri]

On 28/02/17 11:33, Cedric BAIL wrote:
> On Mon, Feb 27, 2017 at 3:41 PM, BGB <cr88192 at gmail.com> wrote:
>> On 2/27/2017 3:35 PM, Cedric BAIL wrote:
>>> On Sun, Feb 26, 2017 at 9:35 PM, BGB <cr88192 at gmail.com> wrote:
>>>> On 2/26/2017 7:29 PM, Cedric BAIL wrote:
>>>>> We had Thursday a nice meetup after ELC and we came up with some
>>>>> ideas. Not to sure if they are good as the food and drink may have
>>>>> helped :-)
>>>>>
>>>>> One of the idea we discussed quite in depth was how to design a nice
>>>>> 2D unit that would go with the turtle. The main issue as discussed
>>>>> before on this mailing list is that most toolkit won't care about
>>>>> anything, but OpenGL and Vulkan this days. Obviously this standard are
>>>>> way to big and complex for us at this stage.
>>>> OpenGL isn't actually all that complicated per-se (yes, granted, it looks
>>>> pretty scary up-front), but what makes things more complicated here is
>>>> mostly trying to make it fast enough to be useful.
>>> Trying to just follow the standard properly is already a danting task.
>>> Look at a very good example. Intel took years to reach a point where
>>> it was covering the standard properly and they are only now catching
>>> up on speed too. The amount of work to be done on the software side is
>>> multi year before you can claim compliance with OpenGL. Vulkan may be
>>> slightly easier there, but I haven't looked at it enough to say so
>>> (And you may be able to implement OpenGL on top of Vulkan, but not
>>> OpenCL for now and you also can't do compositing with Vulkan at the
>>> moment).
>>>
>>> I am talking here about the used today OpenGL, the one with shaders
>>> everywhere. Which is pretty demanding on both software stack (to
>>> generate them efficiently) and on the GPU side to have all the needed
>>> hardware and cycle to do something useful. I think you are under
>>> estimating the work needed from, I got something on screen to Qt and
>>> Steams can use it without crashing.
>> I got Quake 3 Arena to work mostly ok with a custom-written OpenGL.
>>
>> granted, this was a subset of OpenGL 1.x, as it mostly focused on the
>> features that Quake 3 used, and skipped out on stuff that wasn't used (such
>> as display lists, etc...).
> OpenGL 1.0 was released in 1992 and the last release of the 1.x branch
> in 2003. None of them had a programmable pipeline which is what every
> toolkit and game that is used today use. I see personnally no interest
> in anything below Vulkan has most toolkit and games engine will have
> moved to it or a fully programmable pipeline by the time we are done
> doing any hardware.
>
> <snip>
>
>> another SW GL implementation (Mesa's LLVMpipe) had used LLVM basically to
>> dynamically compile parts of the software-rendering pipeline, which is a
>> fair bit fancier (than just doing a plain-C software rasterizer).
> Yes, but still it is super damn slow and would require massive rewrite
> to match a non classic CPU architecture. Also llvm is a pretty bad
> solution for GPU compilation has the goal of LLVM and a shader
> compiler are not aligned
Well that is still a topic of debate in Mesa
>   which is why Mesa has its own IR and
> optimization pass on it.
Actually the only reason the Mesa optimisation passes are not fully 
disabled for recent AMD gpus is because it would result in various 
OpenGL validation failing. This is because various tests/games etc 
depend on optimisations to be done before validation is done. e.g 
Checking max limits on varyings. If it wasn't for this the optimisations 
would have been fully disabled a while ago.

<snip>