On Saturday, 30 November 2019 at 16:41:34 UTC, Gregor Mückl wrote:
> Intel Xe is supposed to be a dedicated GPU. I expect a radical departure from their x86 cores and their previous Xeon Phi chips that used a reduced x86 instruction set. Any successor to that needs more cores, but these can be a lot simpler.

Yes, so not relevant for UI right now, as most user will only have on-die GPUs (colocated on the same chip as the CPU). But if all GPU vendors are moving in the same direction then it will eventually make it to the low end.

> I'm really taking a hint from graphics here: animation studios started to use PBR (that is path tracing with physically plausible materials) same as VFX houses that do photorealistic effects. They want it that way because then the default is being correct. They can always stylize later.

Hmm... yes...  if you look to art then some of the best artists break even with correct perspective and rendering for more impactful aesthetics. There was some research done under the label "evolutionary art", where computable aesthetic measures were used for the fitness model. Not sure what the status quo is, though. Maybe NN will lead to something.

For anyone interested in how regular GPUs work, this report is pretty interesting:

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-143.pdf

It explains how Single-Instruction-Multiple-Threads execution units hides latency, by interleaving multiple threads. So, 8-32 execution units are working in lockstep, but the impact of stalls are reduced.

The typical on-die Intel GPU seems to have 8 execution units per slice and 2x 128-bit ALUs per execution unit.

On Monday, 2 December 2019 at 20:08:15 UTC, Ola Fosheim Grøstad wrote:
> The typical on-die Intel GPU seems to have 8 execution units per slice and 2x 128-bit ALUs per execution unit.

I meant 2x 128-bit FPUs (e.g. 8xFP32)

And one has to read the report to figure out how GPUs hide latency, because... they differ. Which kinda is the point, I guess.

On Friday, 29 November 2019 at 09:55:28 UTC, Basile B. wrote:

> Back to the original topic. What people don't realize is that a 100% D GUI would be a more complex project than the D compiler itself. Just the text features is a huge thing in itself: unicode, BDI.

It doesn't have to come with everything for starters.

 DlangUI was mostly one man. How's that possible? And people here have used it for commercial products.

On Tuesday, 3 December 2019 at 07:58:42 UTC, aberba wrote:
>  DlangUI was mostly one man. How's that possible? And people here have used it for commercial products.

Seems to have been derived from a C++ project he had. Also closely tied to OpenGL, which basically is a dead end at this point outside browsers (lives on as WebGL).

But yeah, a pretty big project.

On Tuesday, 3 December 2019 at 08:54:02 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 3 December 2019 at 07:58:42 UTC, aberba wrote:
>>  DlangUI was mostly one man. How's that possible? And people here have used it for commercial products.
>
>  Also closely tied to OpenGL

Is it? There are different "back ends", on Windows one can use WinAPI and on Linux SDL...

On Tuesday, 3 December 2019 at 17:35:19 UTC, thedeemon wrote:
> Is it? There are different "back ends", on Windows one can use WinAPI and on Linux SDL...

I stand corrected then, but I only found OpenGL support and no other GPU API... but I haven't given it a hard look.

On 04/12/2019 6:59 AM, Ola Fosheim Grøstad wrote:
> On Tuesday, 3 December 2019 at 17:35:19 UTC, thedeemon wrote:
>> Is it? There are different "back ends", on Windows one can use WinAPI and on Linux SDL...
> 
> I stand corrected then, but I only found OpenGL support and no other GPU API... but I haven't given it a hard look.

It supports framebuffer and OpenGL.
The OpenGL support looks like its basically just a framebuffer under the hood though...

Those "back ends" are different windowing implementations. Nothing to do with GPU API other than creating a context basically.