anholt/mesa

this repo is dead. See https://gitlab.freedesktop.org/mesa/mesa master branch for latest usable vc4 and v3d, and https://gitlab.freedesktop.org/anholt/mesa for old vc4/v3d WIP branches

mesa's Issues

PIX_FMT_YUV420P & PIX_FMT_RGBA Kodi compile issue

http://paste.ubuntu.com/15093093/

In the link above I provide the output for ./configure and errors found during make amd make -j2. even though both the errors are from separate files, its probably because of the difference in order due to multi thread compilation.
But, the error point to a common statement

DVDFileInfo.cpp:278:19: error: ‘PIX_FMT_YUV420P’ was not declared in this scope
PIX_FMT_YUV420P, nWidth, nHeight, PIX_FMT_BGRA, SWS_FAST_BILINEAR | SwScaleCPUFlags(), NULL, NULL, NULL);

DVDFileInfo.cpp:278:53: error: ‘PIX_FMT_BGRA’ was not declared in this scope
PIX_FMT_YUV420P, nWidth, nHeight, PIX_FMT_BGRA, SWS_FAST_BILINEAR | SwScaleCPUFlags(), NULL, NULL, NULL);

AND

LinuxRendererGLES.cpp:1947:32: error: ‘PIX_FMT_YUV420P’ was not declared in this scope
im->width, im->height, PIX_FMT_YUV420P,

LinuxRendererGLES.cpp:1948:32: error: ‘PIX_FMT_RGBA’ was not declared in this scope
im->width, im->height, PIX_FMT_RGBA,

Considering that i am building a stable branch and a quick google search doesn't reveal much i recon this would be the correct place to report this bug.

glsl-routing GPU hang

Reproducible GPU hang when running this piglit test. Things known so far:

• Not all of the modes produce hangs, but the first in the array does.
• It's not GFXH30 because making the primitive cover the window doesn't fix it.

aarch64 memory leak on Fedora 24 aarch24 image

Hola,

I am using kraxor's Fedora 24 image, up to date as of:

Linux qpi3 4.7.4-3-main #1 SMP PREEMPT Fri Sep 16 13:26:40 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux

I am using a cma of 256M, increasing that does not appear to change the distribution of crash timing.

dmesg shows the following in the course of the crash

[ 225.598769] alloc_contig_range: [2b100, 2b8f8) PFNs busy
[ 225.675505] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 225.844203] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 226.570088] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 226.706585] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 226.722573] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 226.734704] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 227.769305] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 227.801407] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 227.817344] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 227.830003] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 231.200351] alloc_contig_range: [2a04a, 2a04c) PFNs busy
[ 231.736439] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 231.748004] alloc_contig_range: [2a04a, 2a04b) PFNs busy
[ 231.759394] alloc_contig_range: [2a04b, 2a04c) PFNs busy
[ 236.152468] alloc_contig_range: [2a04a, 2a04c) PFNs busy
[ 236.670227] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 236.681743] alloc_contig_range: [2a04a, 2a04b) PFNs busy
[ 236.693221] alloc_contig_range: [2a04b, 2a04c) PFNs busy
[ 241.069254] alloc_contig_range: [2a04a, 2a04c) PFNs busy
[ 241.586444] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 241.597952] alloc_contig_range: [2a04a, 2a04b) PFNs busy
[ 241.609170] alloc_contig_range: [2a04b, 2a04c) PFNs busy
[ 246.005960] alloc_contig_range: [2a04a, 2a04c) PFNs busy
[ 246.520161] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 246.531782] alloc_contig_range: [2a04a, 2a04b) PFNs busy
[ 246.543340] alloc_contig_range: [2a04b, 2a04c) PFNs busy
[ 250.919096] alloc_contig_range: [2a04a, 2a04c) PFNs busy
[ 251.436457] alloc_contig_range: [2a048, 2a049) PFNs busy
[ 251.448079] alloc_contig_range: [2a04a, 2a04b) PFNs busy
[ 251.459576] alloc_contig_range: [2a04b, 2a04c) PFNs busy
[ 255.815581] artriculate[3062]: unhandled level 1 translation fault (11) at 0x300000000, esr 0x92000005
[ 255.831072] pgd = ffffffc020535000
[ 255.840464] [300000000] *pgd=0000000000000000, *pud=0000000000000000

[ 255.860794] CPU: 0 PID: 3062 Comm: artriculate Not tainted 4.7.4-3-main #1
[ 255.874215] Hardware name: Raspberry Pi 3 Model B (DT)
[ 255.885992] task: ffffffc01ea62580 ti: ffffffc01ea94000 task.ti: ffffffc01ea94000
[ 255.900388] PC is at 0x7f9f22d7b4
[ 255.910790] LR is at 0x7f9f22d79c
[ 255.920841] pc : [<0000007f9f22d7b4>] lr : [<0000007f9f22d79c>] pstate: 20000000
[ 255.935063] sp : 0000007feeb54470
[ 255.945148] x29: 0000007feeb54470 x28: 0000000000000000
[ 255.957289] x27: 0000000000000000 x26: 0000000036d74700
[ 255.969389] x25: 0000000000000001 x24: 0000000036d82df0
[ 255.981212] x23: 0000007feeb544c0 x22: 0000007f990c4718
[ 255.992949] x21: 0000000000000040 x20: 0000007feeb544d0
[ 256.004620] x19: 0000000036d5eff0 x18: 000000000000d800
[ 256.016273] x17: 0000007f9f3ddfa0 x16: 0000007f9f22d774
[ 256.027813] x15: 4c00000000000000 x14: 00188eb6a3000000
[ 256.039266] x13: ffff000000000000 x12: 0000000000000000
[ 256.050836] x11: 0000000000000018 x10: 0101010101010101
[ 256.062337] x9 : 0000000000000050 x8 : 0000007f990c4718
[ 256.073817] x7 : 0000007f990c4718 x6 : 0000000036d5eff0
[ 256.085299] x5 : 0000007f990c4320 x4 : 0000007f990c4310
[ 256.096717] x3 : 0000000036d80600 x2 : 0000007f990c4320
[ 256.108149] x1 : 0000000000000003 x0 : 0000000300000000

I am using a custom QML application which runs for days at a time on the original pi. I have not isolated the memory leak to vc4, or mesa and there is clearly some chance this is a Qt aarch64 issue. I have not even run this against vc4 on a non-aarch64 build to see if I can reproduce this there.

Just raising this here incase anything pops out, and because I am more than happy to aid in investigating this issue if there is broader interest.

vc4: No 3D texture support

Lots of desktop piglit tests fail because of this. We're going to need to upload them to a 2D texture and do the filtering manually.

vc4: Need to flatten small IF statements

Since our branching is so much more expensive than in other drivers, it's more important for us to flatten if statements than (say) i965. The opt-peephole-sel flattens some extremely simple if statements, but if things have ALU operations in them then that pass doesn't do anything.

We need to write a new NIR pass like nir_opt_peephole_sel that takes some threshold of ALU instruction count, finds IF statements with fewer than that many instructions, and moves the SSA defs out of then/else and turns the following phi nodes into bcsels.

This impacts glmark2 -b conditionals:fragment-steps=5:vertex-steps=0 and should almost double performance in it.

vc4: Don't flush on incremental clears.

Sometimes apps will do a glClear(COLOR) then a glClear(DEPTH), without rendering in between, and we shouldn't do a scene store/load for that.

vc4: Copy propagate VPM reads into their usage if only used once.

vc4: Fix up and use nir_lower_indirect_derefs.c

To handle shaders that index arrays with a non-constant expression, we're using PIPE_SHADER_CAP_INDIRECT_INPUT_ADDR=0 (and _OUTPUT and _TEMP). This makes glsl/lower_variable_index_to_cond_assign.cpp happen, which turns the array index into a sort of binary search over the possible index values to load/store the appropriate value of the variable. Since we don't support IF statements, the tree gets flattened and we end up with way more comparison math than we should have.

We have a corresponding NIR pass to use in nir_lower_indirects.c, but IF lowering happens earlier at the GLSL IR level. We could provide a flag to switch the pass from emitting a binary search if tree to emitting a bunch of bcsels instead. Once we did that, we could tell GLSL that we do indirects, lower it in vc4_shader_state_create(), and probably get some shader-db wins.

Raspbian integration (two libGLES side-by-side)

@anholt: Please let me know if there is a more apt venue for reporting those! I was informally in contact with Matt from the Raspberry Pi foundation, told him about the we're having with the latest release, and he pointed me to your (amazing!) new feedback mechanism for the driver.

The recent Raspbian release ships with two libGLESv2.so implementations, which seems to break at least JOGL (2.3.2) as well as the GStreamer that comes with the distribution.

This seems to illustrate the problem:

ldconfig -p | grep GLES
libGLESv2.so.2 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2
libGLESv2.so (libc6,hard-float) => /opt/vc/lib/libGLESv2.so

JOGL will ask the linker first for libGLESv2.so.2 (and would later fall back to libGLESv2.so) - so the Mesa one gets loaded, even though we're on BC IV.

Installing gstreamer1.0-tools and running gst-launch-1.0 playbin uri=file:///opt/vc/src/hello_pi/hello_video/test.h264 gives a SIGSEGV. Running sudo aptitude remove libgles1-mesa libgles2-mesa libgl1-mesa-dri magically solves this, suggesting a similar issue.

As developer, I want to be able to make my application run on the old, as well as the new driver - allowing the user to try both. JOGL is already capable of interfacing with both (as well as with other hardware) - the only thing that we'd need is a clear way of knowing which GLES{,2} implementation to use.

I'd love to just be able to use the linker (e.g. with some /etc/ld.so.conf reordering when enabling/disabling the new driver), to get the desired implementation. But it'd be good to know the plans in Raspbian for that, so that we can prepare.

vc4: MESA_shading_language_glsl130-like extension

X could get a big RGB-antialiased text performance improvement from GL_ARB_blend_func_extended, but we can't expose it without part of GLSL 1.30. However, we can't support all of 1.30 (instancing, for example).

vc4: Copy propagate VPM reads into VPM writes

If a VS input gets routed directly to a VS output, we'll move from the VPM read register to a temporary and move the temporary to the VPM write register.

VPM reads routed directly to VPM write are the exception to the rule that you can't talk to more than one external function in an instruction, so we should avoid the temporary.

vc4: Route fs_inputs through NIR

If we relayout the NIR outputs to be scalar operations, and remove unused output channels being stored according to fs_inputs, we could dead code eliminate more in the VS.

vc4: Add support for glInvalidateFramebuffer()

This would let apps tell us that we can avoid storing the depth/stencil contents, saving memory bandwidth.

vc4: Avoid unpack/repack of writing texture fetches to the output color.

See glsl-fs-texture2d.shader_test

vc4: Force cubemap clamp mode?

Need to decide if I want to follow i965 behavior and make cubes always clamp-to-edge.

VC4 Font rendering issue with Qt5

Hello!

I tried the new Raspbian from February on a Pi2 and activated the experimental new drivers. Great work, really! Finally Stellarium works in usable speed. However, fonts are garbled in many situations (all in-viewport labels. Fonts on GUI panels are OK). I cannot say whether this is a VC4 driver issue or Qt must fix that? Fonts are garbled also e.g. in qtcreator. Fonts are ok in non-vc4 mode, but this is software-renderer speed, much too slow to be useful. I also built Qt5.6, but apps built with it don't want to start (black window only?).
Any insight, help, solution? Thanks!
gzotti (Stellarium team)

vc4: Bad bunny rendering in glmark2

From https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=135790:

See https://www.youtube.com/watch?v=yVuIAmf8OEU

vc4: Bad KiCad rendering

From https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=135790:

Fill mode broken:
http://79.125.115.174/pics/kicad1.png

GL_POLYGON_MODE stuff?

vc4: Use normal ALU operations for texture setup

Right now texture coordinates get moved in with a normal MOV. If we extend other ops to take an optional texture uniform, we could reduce instruction count in the FS.

vc4: Defer FBO flushing across binds.

Likely GLBenchmark performance improvement. If you bind a new FBO as a render target, we'd rather not flush our current rendering, since it means we'd have to store those tiles now, and reload them when we come back to rendering to that FBO. Instead, we should attach command lists to FBOs, and only flush those command lists when the FBO is used as the source for some other operation (texturing or CPU mapping)

vc4: stencil blits unsupported

We can't export stencil because only the first dword of the value written to TLB_STENCIL is used. We could still texture from stencil with 8 passes to fill each bit of the stencil buffer. See vc4-stencil-blit for some of the driver bits necessary.

vc4: Work around register allocation failure with uniform control flow

Some of the DEQP GLES2 tests fail due to register allocation failure, and they're using a uniform for their loop trip count. We could probably reduce register pressure if we could unroll. so maybe when we fail to compile we should try (for this specific draw call) replacing the uniform loads used in control flow with constant loads and compiling that way so that the loop can get unrolled. If the uniforms don't actually change, this could potentially even be reasonably fast.

This will need the nir loop unrolling to land to be really useful.

vc4: No support for DDX/DDY

This might be doable with the MUL output rotation support

vc4: reorder FS varyings to interpolate directly into texture setup.

The VS doesn't care much what order it outputs, so we potentially could sort our FS inputs so that interpolation goes directly into a fetch.

vc4: Missing ETC1 support

Have a branch, just need to add kernel-side validation support.

vc4: Missing GLSL non-constant loop support

Biggest feature project for v3d at this point.

X: Low performance on LXDE's pcmanfm selection rectangles

I found it out while reading some fancy dmesg logs on my RPi3 with GL driver enabled.
How to reproduce:

1. Start X11 and stay on the desktop.
2. Grab some area large enough (2/3 of the screen).
3. Frame is going to get pretty slow and laggy.

Yea, it's not a problem itself because it's just a smoothness issue, but I believe something really messy is going on after such a simple action, because of these logs:
[ 2269.351131] vc4-drm soc:gpu: failed to allocate buffer with size 946176 [ 2269.682454] vc4-drm soc:gpu: failed to allocate buffer with size 3010560 [ 2269.780828] vc4-drm soc:gpu: failed to allocate buffer with size 1056768 [ 2269.782802] vc4-drm soc:gpu: failed to allocate buffer with size 1056768 [ 2269.782872] vc4-drm soc:gpu: failed to allocate buffer with size 1056768 [ 2269.786145] [drm:vc4_validate_bin_cl [vc4]] *ERROR* 0x00000000: packet 112 (VC4_PACKET_TILE_BINNING_MODE_CONFIG) failed to validate [ 2269.791092] vc4-drm soc:gpu: failed to allocate buffer with size 1077248 [ 2269.791163] vc4-drm soc:gpu: failed to allocate buffer with size 1077248 [ 2269.794115] [drm:vc4_validate_bin_cl [vc4]] *ERROR* 0x00000000: packet 112 (VC4_PACKET_TILE_BINNING_MODE_CONFIG) failed to validate [ 2269.796577] vc4-drm soc:gpu: failed to allocate buffer with size 1056768 [ 2269.796648] vc4-drm soc:gpu: failed to allocate buffer with size 1056768 [ 2269.799633] [drm:vc4_validate_bin_cl [vc4]] *ERROR* 0x00000000: packet 112 (VC4_PACKET_TILE_BINNING_MODE_CONFIG) failed to validate [ 2269.800149] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.800229] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.802319] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.802379] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.805062] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.805298] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.810274] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.810357] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.810740] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.811020] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.815098] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.815333] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.818591] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.818671] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.820081] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.820344] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.824405] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.824472] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.825065] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.825125] vc4-drm soc:gpu: failed to allocate buffer with size 3874816 [ 2269.878325] vc4-drm soc:gpu: failed to allocate buffer with size 1056768 [ 2269.878437] vc4-drm soc:gpu: failed to allocate buffer with size 1056768 [ 2269.878474] [drm:vc4_validate_bin_cl [vc4]] *ERROR* 0x00000000: packet 112 (VC4_PACKET_TILE_BINNING_MODE_CONFIG) failed to validate [ 2269.878836] vc4-drm soc:gpu: failed to allocate buffer with size 1077248 [ 2269.878898] vc4-drm soc:gpu: failed to allocate buffer with size 1077248 [ 2269.886150] [drm:vc4_validate_bin_cl [vc4]] *ERROR* 0x00000000: packet 112 (VC4_PACKET_TILE_BINNING_MODE_CONFIG) failed to validate [ 2269.954415] vc4-drm soc:gpu: failed to allocate buffer with size 1064960 [ 2269.959146] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.959347] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.963551] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.963614] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.964342] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.964404] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.968520] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.968583] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.972295] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.972354] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.973469] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.973528] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.975294] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.975351] vc4-drm soc:gpu: failed to allocate buffer with size 2150400 [ 2269.975379] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA: [ 2269.975384] [drm] num bos allocated: 626 [ 2269.975388] [drm] size bos allocated: 212388kb [ 2269.975392] [drm] num bos used: 624 [ 2269.975396] [drm] size bos used: 208188kb [ 2269.975400] [drm] num bos cached: 2 [ 2269.975404] [drm] size bos cached: 4200kb [ 2269.976735] vc4-drm soc:gpu: failed to allocate buffer with size 2150400

vc4: discards in control flow broken

Apparently I didn't even try to implement it. Shouldn't be hard, and there's a test: glsl-fs-discard-04.

vc4: GPU/system hang in OO calc?

From: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=135790

OpenOffice calc crashed using the new GPU driver, totally locked the pi solid so I powered it off(probably should have tried plugging in a network cable or serial to see if remote login was possible?)

Anyways I have no idea how to try and trace such a problem, the sheet was about 6 columns by 55 rows and I was just starting to input and copy a formula into multiple cells.

vc4: Add multithreaded register allocation mode

If you use half the register space(ra0-15, rb0-15), you can do a hyperthreading-style switch to another shader dispatched to the same QPU, to hide texture fetch latency. This could be a big performance win.

Enabling OpenGL (on Raspbian) breaks OpenGL ES (in X and console-only apps)

Hi,

Is it expected behaviour that if OpenGL support is enabled then OpenGL ES applications can no longer run ?

There's a bit of a trail starting here: RPi-Distro/raspi-config/#21

Regards
Wayne

vc4: Schedule instructions in branch delay slots

We're wasting 3 instructions per branch with NOPs, when we could schedule useful things there.

mupen64 high CPU usage

I am testing an application (mupen64plus with the GLideN64 graphics plugin) using the closed source driver and this driver. When I use this driver, the CPU usage is much higher, to the point that performance suffers on some games (when CPU gets to 95%+ busy, whereas using the closed source driver it wouldn't be higher than 60-70%)

I profiled the application using google-perftools, and __driDriverGetExtensions_vc4 is using anywhere from 12-22% of the CPU time, with nouveau_drm_screen_create being the next highest at 8-12% (they are the top 2 functions for CPU usage).

I guess my other question would be: why is it not using vc4_drm_screen_create?

This is with the latest version of Raspbian, so Mesa 11.1.0 I believe

vc4: glGenerateMipmaps is slow

Due to gallium using baselevel for glGenerateMipmaps(), we end up with fallback copies every time it's called.

Possible solutions:

• Skip shadow baselevel when the slice is 4k aligned and first==last to reduce the problem. Only works when level 0 is power of two sized.
• Make gallium blits use sampling with fixed LOD.

glmark2 -b terrain is a testcase for this.

vc4: Reports nonzero OQ bits

gallium doesn't give the driver control of this, unfortunately. piglit tests fail, and apps don't get a chance to make correct choices.

File descriptor leak?

I've been debugging a problem with my application holding on to a file descriptor for /dev/dri/card0 when I want to close it and tear down all DRM-related resources. For a longer description of the problem, see this message on the mesa-users ML.

When I call gbm_create_device(), the Mesa library code dup()s the passed file descriptor twice. When I call gbm_device_destroy(), and then close() the original FD, one FD is left pointing at /dev/dri/card0. From debugging with GDB, it seems like the orphaned FD is produced by dup() here: https://github.com/anholt/mesa/blob/master/src/gallium/winsys/vc4/drm/vc4_drm_winsys.c#L33

I can't see where that FD is meant to be closed. I'm not familiar with the Mesa code, but I added this to vc4_screen_destroy:

close(vc4_screen(pscreen)->fd);

so that the FD is closed when the screen is destroyed, and it fixes my problem. So I suspect it's that FD being leaked. Is that the case, or should the FD be closed by some other part of the code?

vc4: Inaccurate exp2/log2

Our math unit gives you fast, inaccurate math (piglit tests fs-log2-float, fs-exp2-float). To meet GL requirements, we need to do some Newton steps for improving the accuracy of our answers. I've done this for RCP and RSQ but not LOG2 and EXP2.

vc4: Poor performance scrolling in firefox

Looking at traces of firefox 45.3's rendering of reddit.com, I see the following issues:

• an unreasonable number of flushes from the BlockHandler
• fallback trapezoid rendering directly to render target.
• PolyFillRect unscissored
• PolySegments unscissored.

GL rendering has no effect (black/empty window content)

I've tried to build mesa-12.0.0-rc2 and xorg-1.18.3 to fetch the recent updates to the mesa driver, but after I installed it and run glxgears, its window was just black, no gears/anything else was displayed. The FPS report, however, showed some values.
pi@raspberrypi ~ $ vblank_mode=0 LIBGL_DEBUG=verbose glxgears -info
libGL: OpenDriver: trying /usr/lib/arm-linux-gnueabihf/dri/tls/vc4_dri.so
libGL: OpenDriver: trying /usr/lib/arm-linux-gnueabihf/dri/vc4_dri.so
libGL: Can't open configuration file /home/pi/.drirc: No such file or directory.
ATTENTION: default value of option vblank_mode overridden by environment.
libGL: Can't open configuration file /home/pi/.drirc: No such file or directory.
libGL: Using DRI2 for screen 0
Attempting to import 300x300 b8g8r8x8_unorm with unsupported stride 1200 instead of 76
GL_RENDERER = Gallium 0.4 on VC4
GL_VERSION = 2.1 Mesa 12.0.0-rc2 (git-a7649ab)
GL_VENDOR = Broadcom
GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_polygon_offset GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_texture_env_add GL_EXT_texture_lod_bias GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_EXT_framebuffer_object GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_ATI_fragment_shader GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_fog_distance GL_APPLE_packed_pixels GL_APPLE_vertex_array_object GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_MESA_pack_invert GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_shading_language_100 GL_ARB_sync GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate GL_OES_read_format GL_ARB_color_buffer_float GL_ARB_pixel_buffer_object GL_ARB_texture_rectangle GL_EXT_pixel_buffer_object GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_ARB_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_packed_depth_stencil GL_ARB_vertex_array_object GL_ATI_separate_stencil GL_EXT_gpu_program_parameters GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_ARB_copy_buffer GL_ARB_half_float_vertex GL_ARB_map_buffer_range GL_ARB_texture_swizzle GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle GL_EXT_vertex_array_bgra GL_ARB_ES2_compatibility GL_ARB_debug_output GL_ARB_draw_elements_base_vertex GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions GL_ARB_provoking_vertex GL_ARB_sampler_objects GL_ARB_texture_multisample GL_EXT_provoking_vertex GL_ARB_get_program_binary GL_ARB_robustness GL_ARB_separate_shader_objects GL_ARB_compressed_texture_pixel_storage GL_ARB_internalformat_query GL_ARB_map_buffer_alignment GL_ARB_texture_storage GL_EXT_framebuffer_multisample_blit_scaled GL_AMD_shader_trinary_minmax GL_ARB_clear_buffer_object GL_ARB_explicit_uniform_location GL_ARB_invalidate_subdata GL_ARB_program_interface_query GL_ARB_texture_storage_multisample GL_ARB_vertex_attrib_binding GL_KHR_debug GL_ARB_buffer_storage GL_ARB_internalformat_query2 GL_ARB_multi_bind GL_EXT_shader_integer_mix GL_ARB_get_texture_sub_image GL_KHR_context_flush_control
VisualID 427, 0x1ab
2282 frames in 5.0 seconds = 456.264 FPS
175 frames in 5.0 seconds = 34.893 FPS
173 frames in 5.0 seconds = 34.546 FPS
176 frames in 5.0 seconds = 35.126 FPS
175 frames in 5.1 seconds = 34.543 FPS
177 frames in 5.0 seconds = 35.243 FPS
175 frames in 5.0 seconds = 34.818 FPS
167 frames in 5.0 seconds = 33.206 FPS
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 7129 requests (7129 known processed) with 0 events remaining.
I'm using RPi Linux-4.4.y (4.4.13-v7+).
I've configured mesa like this:
./configure --prefix=/usr --libdir=/usr/lib/arm-linux-gnueabihf --sysconfdir=/etc --localstatedir=/var --with-gallium-drivers=vc4 --with-dri-drivers= --with-egl-platforms=x11,drm --enable-glx-tls --enable-xa --disable-dri3
and xorg like this:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-glamor --enable-kdrive-evdev --enable-dri2 --enable-dri3 --disable-xvfb --disable-xnest --disable-xwayland --disable-unit-tests
Maybe someone can suggest if there's something wrong with my configuration or setup.
Thanks in advance!

vc4: Jump to program end when all fragments are discarded

If a whole 16-pixel area is discarded, we could jump to the end of the program and skip the rest (particularly any remaining texture lookups). Intel saw pretty big wins from their corresponding change to do this.

We may or may not see any improvement from also conditioning texture fetches on any of the pixels in each 2x2 subspan having been not discarded.

Potential apps:

• glbenchmark 2.7: Jumps over texture sampling
• mupen64plus: Big jumps over control flow with math. Interesting case of conditional discard within control flow near the end of a program.
• glmark2: No benefit but make sure it doesn't regress (short jumps).
• minecraft: No benefit probably, but make sure it doesn't regress (medium length jumps).

vc4: partial asteroid rendering in glmark2.

From https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=135790:

See https://youtu.be/yVuIAmf8OEU?t=110

vc4: linuxcnc display bugs

From https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=135790:

linuxcnc axis gui running causes screen redraw problems in X, either whole screen is blanked or certain possibly random windows get blanked on focus.

e.g. on running 'linuxcnc' when the tk based gui configuration selector window is mapped the whole screen goes black or sometimes just the mapped window will become be black, mouse pointer is still visible, if mouse clicking finds a window and focuses it for dragging the blanked areas of screen are redrawn as the window is moved unobscuring areas lower in stacking order.

Sometimes the fully drawn screen gets mapped after dragging the window around, but after clicking subwindows (buttons) other parts of the screen or seemingly random windows will be blanked.

e.g. once axis is running moving mouse over tk buttons may map them, then clicking a button may blank the whole axis window or just a few buttons or even some of the buttons on the window manager frame for the axis window.

vc4: glmark2 -b terrain bad rendering

There are occasional flickers in the foreground, and in the background the fade-in of distant terrain looks like primitives are missing compared to i965.

vc4: crash when using plymouth + DSI (raspi 7" touchscreen)

I'm using the kernel 4.4.20-v7+ #908 (obtained from rpi-update) on a raspi 2 with the raspi 7" touchscreen. The vc4 opengl driver is enabled from raspi-config.

I've install the plymouth KMS bootscreen manager.

I can successfully boot if I plug an external HDMI monitor alone (I get the expected plymouth splashscreen) or if I plug both the DSI panel and an external monitor (in that case, I get the splashscreen on the external monitor only).

If I restart without an external monitor plugged, only a non-blinking carret eventually appears, and the raspi freezes.

If I de-install plymouth, the whole boot process works as expected, and I can start a desktop environment with working opengl on mesa.

vc4: register coloring

If we minimize raddr a/b conflicts when possible, we can get way fewer instructions generated. The register allocator could just ask us what we'd prefer for a given register choice, and we could look at what bank the other operand is in.

Split UBO upload from non-UBO upload?

Right now we upload UBO and non-UBO uniforms at draw time when any state flag affecting the uniforms is set. This works out to being basically every draw call. Hoewver, UBO uniforms change a lot less frequently, only when the corresponding program or its constant buffer changes. We could potentially reduce our memory bandwidth, and draw-time CPU overhead by only re-uploading UBO contents when things affecting those change.

glmark2 and mupen64plus don't hit this. glbenchmark2.7 does.

scrolling in firefox-esr causes pi to hang

Apologies for not supplying better technical detail, but the steps to reproduce seem to be very consistent, I have replicated these results on several raspberry pi 3's.

Get latest version of raspbian (the one from from around 2016-05-27 or noobs 1.9.2)

enable the opengl driver with raspi-config

install a copy of firefox-esr

navigate to a page that has enough content to require a decent amount of scrolling

use the mouse wheel to scroll the page (quickly if possible)

within 10-15 seconds of more or less continuous scrolling (or therin abouts) the raspberry pi will crash and can only be brought back by cycling the power.

Turning off the opengl driver and this bug goes away.

                Cheers and thanks for writing this driver, it rocks :)

Use double-buffer non-ms mode?

There's a flag in bin/render config, whose presence is indicated by a field in V3D_IDENT2, for setting up our rendering to use half the tile buffer at a time. This lets stores stream out to memory while the next tile is being loaded, potentially reducing stalls. The simulator I have doesn't support it, and the current closed driver doesn't use it. We should still probably investigate it to see what it does to performance.

Omxplayer with VC4 = only sound, no video

In RPi 2 with Raspbian, Omxplayer doesn't show video when VC4 is enabled; only plays video's sound.
Testing video files with stock video driver, plays flawless.
Tried a lot of configurations without success.
I guess this can be marked as a bug.

vc4: nir_op_ffloor and nir_op_ffract broken for > INT_MAX values.

We're doing these using a truncate implementation that's based on i2f(f2i(arg)), which should fail outside of the integer representable range.

Project: Extend the piglit tests to cover these cases, and fix the lowering. Possibly move the lowering to NIR.