Performance of future Haiku versions

[X512]

@extrowerk

@X512, i have seen your libGL/libGL2 work, could you please tell us something about that?

libGL/libGL2 is Haiku OpenGL implementation based on OSMesa interface. It doesn’t use private Mesa interfaces or Haiku extensions (HGL). Difference between libGL and libGL2 is libGL has add on system, but libGL2 don’t. Add on system is not very useful, because add ons depends on libglapi. Add on system is fixed compared to HaikuPorts version.
Many applications including blender can work with this libGL version, but there are some strange errors, for example Miku model in blender with texture shading mode don’t work, but solid shading work. HGL libGL version have no problem with texture shading mode.
There is also strange bug [mesa] BGLView created after first BGLView not work properly · Issue #4466 · haikuports/haikuports · GitHub that present in both HGL and OSMesa, it can be bug in Mesa itself.

[X512]

@extrowerk

I would happily work on updating Blender to the lates, but AFAIK they changed the GL/GLSL requiments for 2.8x branch, if somebody can help to make it possible on Haiku, that would be great. Tested with MESA overrides, but no dice.

Note that Blender need fixes in libSDL2 context management, without it Blender crashes or freezes when opening and closing new windows. SDL2 Patches uploaded by me are incomplete, it fixes Blender, but break non OpenGL applications.

[lordmmx]

i’ve should of been more clear on which version of ubuntu i was using it was 8.04. i ran it on a pentium 2 450mhz 768mb of ram nvidia geforce mx 400 64mb 40gb hd. it ran really well it. i’ve even got compiz to work once the driver for the graphics card installed. performance wasn’t an issue until 10.04 system requirements was raised abit. i couldn’t get compiz to work because you needed a gpu with 128b of ram on it.

[Diver]

I remember having the same problem with 10.04 (and a few earlier non-LTS releases) and the same nvidia card. I think I tracked it down to the merge of Beryl and Compiz into Compiz Fusion.

Compiz | Merger of the Compiz and Beryl communities

I think it was a regression during the merge which never got fixes.

[cb88]

I had compiz running on basically the minimum config for a bit… Transmeta Crusoe 933Mhz + Radeon 7500 8MB (maybe the vram limitations were an nvidia issue?). It worked… but I prefered dwm since it used less of the system’s resources. Even a CPU renderer should be much faster than a radeon r100 GPU these days I guess the main issue would be excessive memory bandwidth hogging… by any 3D rendering on the CPU.

[win8linux]

@cb88

Haiku has in-progress Mesa LLVM multithreaded OpenGL rendering.

That’s a dead end… it is already as fast as it will ever be.

In that case, perhaps Mesa Vulkan on CPU should be considered for implementation then?

[cb88]

@win8linux

In that case, perhaps Mesa Vulkan on CPU should be considered for implementation then?

That doesn’t exist… there is a guy that wanted to do that via his Kazan project but that has never materialized. And even when it does it is extremely unlikely that it will perform any better than Mesa’s OpenGL LLVMpipe… which is memory bandwidth limited

[Zenja]

but AFAIK they changed the GL/GLSL requiments for 2.8x branch, if somebody can help to make it possible on Haiku, that would be great.

I have a cross platform app with OpenGL 3.3 and GLSL 150, and it works fine under Haiku (minus SRGB texture format). What exactly is the problem with the Blender port?

[cocobean]

I got Blender 2.80 working within terminal mode,. There was a GUI crash in SDL2 (and I think korli patched openexr, but there was something else to fix). Compiled fine a few months ago.

Going to review things again for Blender 2.81a, after playing with new intel_extreme updates.

[extrowerk]

Crashing in GLSL, don’t remember exactly, did a port long time ago, before and after 2.8 releas came out.

[X512]

@Zenja

What exactly is the problem with the Blender port?

I’m currently working on port of Mesa 19.3.2. I already get HGL working. I will check Blender 2.8 later if have time.

[X512]

I checked my experiments with Blender 2.81 and found that it crash in glFramebufferTexture, because it is NULL.

[win8linux]

There is Google’s SwiftShader which has Vulkan as one of the graphics APIs implemented on CPU:

google/swiftshader

[Zenja]

I use the following (works here):

glGenFramebuffers(1, &fFrameBufferID);
glGenRenderbuffers(1, &fRenderBufferID);
glGenTextures(1, &fTexture);

glBindFramebuffer(GL_FRAMEBUFFER, fFrameBufferID);

glBindTexture(GL_TEXTURE_2D, fTexture);
glTexImage2D(GL_TEXTURE_2D, 0, internal_format,  (GLsizei)YGetScreenSizeX(), (GLsizei)YGetScreenSizeY(), 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, fTexture, 0);

glBindRenderbuffer(GL_RENDERBUFFER, fRenderBufferID);
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT24, (GLsizei)YGetScreenSizeX(), (GLsizei)YGetScreenSizeY());
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, fRenderBufferID);

GLenum fboStatus = glCheckFramebufferStatus(GL_FRAMEBUFFER);
if (fboStatus != GL_FRAMEBUFFER_COMPLETE)
{
	switch (fboStatus)
	{
		case GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT:			Debug("GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT error\n");			break;
		case GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT:	Debug("GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT error\n");	break;
#if !defined (GL_ES_VERSION_2_0)
		case GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER:			Debug("GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER error\n");			break;
		case GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER:			Debug("GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER error\n");			break;
		case GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE:			Debug("GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE error\n");			break;
		case GL_FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS:		Debug("GL_FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS error\n");			break;
#else
		case GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS:			Debug("GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS error\n");			break;
#endif
		case GL_FRAMEBUFFER_UNSUPPORTED:					Debug("GL_FRAMEBUFFER_UNSUPPORTED error\n");						break;
		default:											Debug("GL_FRAMEBUFFER_COMPLETE error\n");							break;
	}
}
glBindFramebuffer(GL_FRAMEBUFFER, 0);

[cb88]

Didn’t know about that but some googling shows that it too performs very badly.

[win8linux]

It’s Vulkan-on-CPU. Of course it will perform badly compared to GPU-accelerated VK.

[cb88]

I mean if someone ports it why not… but larger features like real acceleration, even more network drivers, multi display improvements in app_server and drivers, and such… would be better motivation for donations from me and I imagine others too. Donations mean developers can either have more meet ups, better hardware, and or more paid work. I think the semi monthly status updates help with that too…

X512 seems to be working on some perf related things which is nice.

[waddlesplash]

@cb88

even more network drivers

We can port just about any driver from FreeBSD. So, what drivers are you missing here, that FreeBSD has? Please file tickets…

[waddlesplash]

@BeardPower

I wonder if the performance could take a hit once Haiku will reach the point of supporting a plethora of hardware.

[Citation needed.]

As @X512 mentioned, more drivers can potentially slow down the boot, but once you are booted, how will things be slower? The point of all those devices is to make the system faster or support some features, and you can disable them if you don’t need the hardware, right? The same is true on Linux.

As to why Haiku is generally faster, I quote @PulkoMandy from this old post:

@PulkoMandy

The system is not all that well optimized, uses a 15 year old compiler which does not uses any modern CPU features, and by default, the kernel is built in debug mode which makes it much slower than it could be.

How do other operating systems still manage to feel slower? I have no idea.

A lot of the “feel” of how fast Haiku is, though, is due to input latency, and on that front, we are ahead of the class purely by not doing as much buffering as other OSes.

[waddlesplash]

@X512

I’m currently working on port of Mesa 19.3.2. I already get HGL working. I will check Blender 2.8 later if have time.

I know on code reviews we can sound a bit “grumpy” in asking for changes, but, your work here and on the other fixes you’ve done is very much appreciated, thank you!