ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at
camus1 has quit []
camus has joined #lima
camus has quit [Remote host closed the connection]
camus has joined #lima
camus has quit [Remote host closed the connection]
camus has joined #lima
camus has quit [Remote host closed the connection]
camus has joined #lima
camus has quit []
camus has joined #lima
camus has quit []
camus has joined #lima
camus has quit [Remote host closed the connection]
yuq825 has joined #lima
sarbes has joined #lima
yuq825 has quit []
<sarbes> Hi there. I have a question about MSAA.
<sarbes> I'm tinkering with MSAA in Kodi. It sort of works, but I'm getting pretty low frame rates. About half of what it would be with MSAA disabled. But I can't quite figure out what I'm doing wrong.
<sarbes> In my first attempt, I've just set the amount of samples when creating the EGL surface. This works on my desktop with GL and GLES, and on my Odroid C2. But on the latter, the framerate tanks. I suspect that the samples take a trip through main memory.
<sarbes> For my current attempt, I'm trying EXT_multisampled_render_to_texture. Here I create a FBO and render to it. On my desktop, I'm resolving this buffer via glBlitFramebuffer(), which is not available on GLES 2.0.
<sarbes> And from here, I'm unsure how to proceed. Could you give me some pointers?
<sarbes> Or is the performance loss to be expected? ARM brags about the "almost zero" cost of MSAA 4x, so I'm a bit skeptical about that.
<anarsoul> sarbes: it's zero when resolve is done in tile buffer, i.e. without full writeout
<anarsoul> sarbes: I think you need to draw a textured quad on gles 2.0
drod has joined #lima
<sarbes> I'm not sure I can follow. I want the resolve to be happening in the tile buffer. Is there fixed function hardware for it?
<anarsoul> sarbes: use EXT_multisampled_render_to_texture then draw a textured quad
<sarbes> I'm sorry, but I don't see how I could be possibly be faster than the driver.
<sarbes> Quoting from the spec of FramebufferTexture2DMultisampleEXT():
<sarbes> "While the implicit multisample buffer is attached, color sample values are automatically resolved to a single color in the texture level each time a pixel is updated. This has the effect of making the antialiasing appear to be automatic at the application level."
<sarbes> That's almost what I want. Except for the default framebuffer, not FBOs.
<sarbes> According to ARM docs, MSAA for the default framebuffer is enabled via EGL config: This is working with Lima, except it is too slow to be usable.
<anarsoul> sarbes: IIRC ARM driver is not compliant with the spec. Anyway, lima as a gallium driver does exactly what mesa asks for, this behavior is default for all the mesa drivers
<anarsoul> technically it's possible to do in-place resolve for default fb, but it's not implemented in mesa
<anarsoul> feel free to file an issue at
<anarsoul> (however keep in mind that it won't be a lima change, it will be a behavior change for all the mesa drivers)
Daanct12 has joined #lima
<sarbes> That's too bad. Unfortunately, this makes it unsuitable for my purpose.
<sarbes> Thanks for your time.
Guest7036 has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
<anarsoul> sarbes: please file an issue at
Leopold has joined #lima
<sarbes> Will do. Is there something you would like me to put in the issue?
<sarbes> I recon this issue is applicable to all tiling GPUs?
<anarsoul> sarbes: to all the GPUs that support EXT_multisampled_render_to_texture
<anarsoul> I think what you want is in-place resolve for default fb in GLES2
<anarsoul> it's out of spec for desktop GL though
drod has quit [Remote host closed the connection]
<sarbes> Roger.
<sarbes> Bye
sarbes has quit [Quit: Leaving]