Created attachment 39259 [details]
lion_x11.jpg

Created attachment 39260 [details]
sp_x11.jpg

(In reply to comment #0)
> lion_x11: all i see is counterclockwise rotating black figure which stops if i
> move the window and then start rotating again. it disappears if i maximize
> window to fullscreen.
> sp_x11: just a black figure on white background.

I also have this bug.

Created attachment 40701 [details]
openvg 1.1 lion on r300g.jpg

this is how it looks after recent changes

Created attachment 40702 [details]
openvg 1.1 sp on r300g.jpg

heh, you can even see something here

Created attachment 40703 [details]
openvg 1.1 text on r300g.jpg

it also says:
"EGL_VERSION = 1.4 (Gallium)
using OpenVG text support
r300: Unknown TGSI/RC opcode: CLAMP
r300 FP: Compiler Error:
r500_fragprog_emit.c::translate_rgb_op(): translate_rgb_op: unknown opcode ILLEGAL OPCODE

Using a dummy shader instead.
XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0"
      after 179008 requests (179008 known processed) with 0 events remaining."

in console

Created attachment 40706 [details] [review]
possible fix

Could you possibly try this patch?

Created attachment 40710 [details]
openvg 1.1 lion with patch.jpg

holy bytes! now i can see an actual picture. but still it suspiciously rotating.

Created attachment 40711 [details]
openvg 1.1 sp with patch.jpg

Created attachment 40712 [details]
openvg 1.1 text with patch.jpg

still looks ugly but there is no error message anymore.
and it flashing black when i resizing its window, text itself is not resizing but it's there. probably just redrawing itself that ugly.

OpenVG is still being actively developed. I can't say if this bug should be attributed to us (r300g) or the state tracker (st/vega). I need some clue as to what is wrong there. Have you tried the softpipe driver?

I've just had a look at st/vega source code and found a shader which can't run on DX9-class hardware, like r500 and nv40. The shader in question is "convolution_asm" in asm_filters.h. The presence of ARL makes it require DX10-class hardware but the loop and break instructions are not nice either (not supported in shader model 2.0).

i don't know how it should look either :) i just know that before this patch and recent big changes it was just ugly black stuff in ugly white box.

we should probably ask someone who wrote those demos.
is it possible to use different gallium driver on-the-fly without X restart, library rename, etc. ?

if it should look like it looks on recent screenshots then this is, probably, _fixed_.
on r600g (R770) those demos were outright segfaulting before openvg 1.1 bump and now they look indistinguishable from those last r300g screenshots with 2 exceptions though: 
1) lion rotating much slower and much more sluggish than on r300g machine and looks more colourful.
maybe it uses software rendering for openvg for some reason and this is how it supposed to look ? i will provide a picture
2) no text in "text" demo and it says:
"EE r600_shader.c/tgsi_unsupported:868 - 25 tgsi opcode unsupported
EE r600_shader.c/r600_pipe_shader_create:339 - translation from TGSI failed !"

but this is probably not in your department and topic of another bug report which should be filled.

anyway, i'm happy that openvg can actually draw something coherent on real gallium drivers. maybe it will finally be a reason for those cairo guys to fix their drm/kms & gallium & openvg & xcb "support", for 2D GUI/DE/vector graphic editor people to utilize it and such.

Created attachment 40713 [details]
slow lion from r770 with r600g and mesa-git right after r300g-opcode-patch.jpg

there is a memory leak :(
this demo, on both r300g and r600g, eats up memory very fast (and ~5 times faster on r300g where it also rotates faster).
it also uses ~70-80% CPU time _on both_ machines.

hm. now then i look at it as two screenshots one-to-one and not two monitors side-by-side, they look identical. must have been LCD differences :(
everything else stands though.

(In reply to comment #14)
> there is a memory leak :(
> this demo, on both r300g and r600g, eats up memory very fast (and ~5 times
> faster on r300g where it also rotates faster).
> it also uses ~70-80% CPU time _on both_ machines.

Since r300g doesn't leak any memory when used as an OpenGL driver, I guess it's just st/vega that causes this.

I think r600g rotates the lion slower because it's slower than r300g. The speed of the animation seems to depedent on framerate.

Since there isn't any other r300g-specific issue with st/vega, I am closing this bug. Feel free to file a new one if you encounter any other issues. The memory leak bug should probably be filed against Mesa core.