How "safe" is rpi-update at the moment ? (I've not had cause to use it for many years).dom wrote: ↑Mon Jul 01, 2019 4:39 pmWhere are you looking? It's currently only in rpi-update firmware (this update)
It will appear in apt firmware soon.
Yes, it is!!! This means the VC6 works and there is a bottleneck somewhere else. I also tested SDL2 with similar results: 37 seconds for 600 1920x1200 empty frames regardless of the driver with SW driver being slightly faster.
This little nuggest passed me by before, and indeed was the cause of most of my issues, when doing OGLES2.0 on older Pi's you can't have theOpenGL running, it causes failed to add service error. I routinely ensured I had disabled OpenGL drivers on my older Pi'sdom wrote: ↑Mon Jul 01, 2019 1:32 pmYou will get software 3d rendering if you have the legacy firmware driver enabled.
You should have fkms driver enabled (dtoverlay=v3d-fkms-vc4 in config.txt)
It is enabled by default on Pi4, and can be enabled with raspi-config on Pi2/3.
Code: Select all
--host=armv7l-raspberry-linux-gnueabihf --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-x11 --disable-video-opengl
It's always advisable to have a backup of sdcard just in case, or run it on a non-critical Pi.
Are you sure about this step? I've not got an RPi4 yet, nor have I used the Mess drivers but I'm pretty sure if you are using Mesa then you don't want to be including the legacy driver's headers, you should be including the Mesa driver's headers.
So what are the consequences of disabling this as using it seems to be a serious performance hitjcgamestoy wrote: ↑Wed Jul 03, 2019 7:11 pmDisable the compositor with the A8 option of raspi-config...
Here 60fps with glxgears running in 2 screens at 1920x1080
I've been googleing that very question, and the most informative thing I've found so far s this
My emphasis.... So nothing useful or important so not sure why it is enabled by default if it causes such a performance hit ?https://github.com/freedesktop/xcompmgr wrote: xcompmgr is a sample compositing manager for X servers supporting the
XFIXES, DAMAGE, RENDER, and COMPOSITE extensions. It enables basic
https://en.wikipedia.org/wiki/Compositi ... ow_manager
So far I've only seen a significant improvement by turning it off ! If it's going to adverslry effect openGL(ES) performance (and there seems to be an increasing interest in those) then maybe the decision needs rethinking ? Not being able to run glxgrears full screen at 60Hz is pretty disappointing performance.6by9 wrote: ↑Thu Jul 04, 2019 10:09 amGenerally we'd seen significant improvements with xcompmgr. There were a few discussions on scheduling, as the window composition stage is using also the 3D hardware, therefore your GL app has slightly less resource to do what it wants, but I hadn't previously noted a significant difference.
Also slightly improves my GLES2.0 high poly demo, but only by a few FPS.
I am the author of the emulator Retro Virtual Machine (www.retrovirtualmachine.org), and when I ported it to Linux, one of the things that most affected the performance are the "compositors", there are better and worse for example the xfce has a very high cost, although it is a good idea for 2d applications that render by software is a bad for 3d applications because it increases much the load of the GPU.PeterO wrote: ↑Thu Jul 04, 2019 10:17 amSo far I've only seen a significant improvement by turning it off ! If it's going to adverslry effect openGL(ES) performance (and there seems to be an increasing interest in those) then maybe the decision needs rethinking ? Not being able to run glxgrears full screen at 60Hz is pretty disappointing performance.6by9 wrote: ↑Thu Jul 04, 2019 10:09 amGenerally we'd seen significant improvements with xcompmgr. There were a few discussions on scheduling, as the window composition stage is using also the 3D hardware, therefore your GL app has slightly less resource to do what it wants, but I hadn't previously noted a significant difference.
Is there a way to tell it not to get in the way of updates to hardware rendered windows ?
Code: Select all
procedure TTexturebitmap.putpixel(x,y:cardinal;color:byte); // test procedure // for 2048x2048 32bit var aa:cardinal; // debug1:cardinal; begin aa:=address; asm ldr r0,x ldr r1,y and r2,r0,#0b00001111 and r3,r0,#0b00110000 orr r2,r2,r3,lsl #2 and r3,r1,#0b00000011 orr r2,r2,r3,lsl #4 //a and r3,r1,#0b00001100 orr r2,r2,r3,lsl #6 // 10 bits in r2 and r3,r0,#0b01000000 and r4,r1,#0b00010000 eor r4,r4,r3,lsr #2 orr r2,r2,r4,lsl #6 // bit 11 - xor mov r3,r0,lsl #5 tst r1,#0b00100000 mvnne r3,r3 and r3,#0b111111100000000000 orr r2,r3 and r3,r1,#0b11111100000 orr r2,r2,r3,lsl #13 ldr r3,aa add r2,r3 ldrb r3,color strb r3,[r2] end ['R0','R1','R2','R3','R4'] ; end;
I wouldn't say the texture format is weird, it's just not linear, there is a very good reason that linear formats aren't (generally) used for textures, the 3D hardware needs to read the texture at all sorts of angles and usually in small clusters. The format used will have been chosen so that nearby texels will be (ideally) close together in the cache according to how the rasteriser is expected to require them in the majority of cases.pik33 wrote: ↑Thu Jul 04, 2019 6:12 pmThis is another memory copy and the texture format in RPi3/VC4 is weird. I reverse engineered it so I was able to write a putpixel function which puts a pixel diectly in the texture memory. It looks like this (Pascal/asm):
// remark: I decided to use 2048x2048 32bit texture as 8192x2048 8-bit texture, but this means I only had to add some lines to compute a position of byte in the 32-bit word. The problem was the texture organization is not linear and looks rather as a fractal. X and Y bits have to be shifted, xored, etc, to compute an addres in the texture memory, which represents the pixel. Why?
If things didn't change in the new VC6, the copy-rectangle-to-texture function has to be slow, and the compositing video manager has to do this every frame.