[J-core] 2D unit

[BGB]

On 2/28/2017 12:25 AM, Cedric BAIL wrote:
> On Mon, Feb 27, 2017 at 7:27 PM, BGB <cr88192 at gmail.com> wrote:
>> On 2/27/2017 6:33 PM, Cedric BAIL wrote:
>>> On Mon, Feb 27, 2017 at 3:41 PM, BGB <cr88192 at gmail.com> wrote:
>>>
>> but, can we make something newer (even GLES2) usable with SH cores or
>> (lower-end) FPGA's?...
>>
>> I have doubts, hence why looking into stuff mostly from 15-20 years ago.
>>
>> it is a little easier to make stuff from that era work, and "I can basically
>> do this 20 year old thing" may be better than "it can't be done at all".
> But then you have no software that is using it. There is no toolkit,
> web browser or compositor that is maintained for such target. OpenGL
> 1.x is pretty much dead today. Old games is pretty much the only
> things that could take advantage of it.

this has not really been my experience.

well, at least if talking about GL 1.3 or 1.4 or similar, and not 
something like 1.0 or 1.1.


>> probably, the core (fixed function) rasterizer loops could be written in ASM
>> or similar (or maybe GLSL).
>> typically this is where most of the time goes IME.
> I am not sure about what loops you are talking about here ? On the
> GPU, 2D unit or in the CPU ?

GPU, in this case.
you would need loops basically over the pixels being drawn.

but, yeah, in my past experience (with rasterization in software) is 
that filtering, blending, and spitting out pixel data to memory has 
tended to be the vast majority of the running time (in contrast to 
things like transforming vertices or similar).

<snip>

> I have excluded discussion on any of this topic as my sole interest is
> in enabling existing software with hardware acceleration. Porting
> library specifically to this unit is highly time consuming and
> difficult to maintain. Which is why I referred to kms/drm being the
> only goal. This mean a very basic scene graph of buffer being blended
> together. As there might be some color/alpha interpolation included,
> that is the only second operation that might be useful.
>
> I understand your interest into trying to make it as general purpose
> as possible, but that is I think only useful if we can make it a
> modern GPU (Vulkan capable), otherwise sticking with optimizing for
> kms/drm would be enough in my opinion. I do not see how to provide
> meaningful and broad acceleration to the existing software eco systeme
> with what you have in mind.

I think it "may" be possible to provide something sufficient for things 
like window compositing and UI-rendering tasks.

though, granted, probably not really for running games.

can't really say for certain though.