Re: [Mesa-dev] [RFC] radeonsi: guard against indexbuf not being set

[Clemens Eisserer]

Hi Marek and Roman,

> Set this environment variable to disable multithreading:
> GALLIUM_THREAD=0

Thanks, so at least I get now a proper stacktrace (at the bottom).

I am no OpenGL expert, the only thing I find suspicious is that the
last function before entering mesa code actually has a parameter
indexbuf set to 0x58b32b18, while in si_draw_vbo indexbuf=0.
However, those two might be completly unrelated indexbuf variables of course.

Best regards, Clemens


Thread 1 "kwin" received signal SIGSEGV, Segmentation fault.
si_draw_vbo (ctx=0x590ed3e0, info=0x7fffd020) at si_state_draw.c:1372
1372} else if (sctx->b.chip_class <= CIK &&
#0  0x7fffc37fa890 in si_draw_vbo (ctx=0x590ed3e0,
info=0x7fffd020) at si_state_draw.c:1372
sctx = 0x590ed3e0
rs = 
indexbuf = 0x0
dirty_tex_counter = 
rast_prim = 
index_size = 2
index_offset = 0
#1  0x7fffc352180c in u_vbuf_draw_vbo (mgr=0x584c57a0,
info=) at util/u_vbuf.c:1142
pipe = 0x590ed3e0
start_vertex = 
min_index = 
num_vertices = 
unroll_indices = 0 '\000'
used_vb_mask = 
user_vb_mask = 
incompatible_vb_mask = 0
new_info =
  {index_size = 10 '\n', mode = PIPE_PRIM_POINTS,
primitive_restart = 0, has_user_indices = 0, vertices_per_patch = 0
'\000', start = 0, count = 16, start_instance = 0, instance_count =
16, drawid = 0, index_bias = 1486497808, min_index = 21845, max_index
= 1494143968, restart_index = 21845, index = {resource =
0x7fffc37cf21c , user = 0x7fffc37cf21c
}, indirect = 0x10001,
count_from_stream_output = 0x10}
#2  0x7fffc32aeb9f in st_draw_vbo (ctx=,
prims=0x7fffd100, nr_prims=, ib=0x7fffd0e0,
index_bounds_valid=, min_index=,
max_index=, tfb_vertcount=0x0, stream=0, indirect=0x0)
at state_tracker/st_draw.c:227
st = 0x58be7170
info =
  {index_size = 2 '\002', mode = PIPE_PRIM_TRIANGLE_STRIP,
primitive_restart = 0, has_user_indices = 0, vertices_per_patch = 3
'\003', start = 1, count = 4, start_instance = 0, instance_count = 1,
drawid = 0, index_bias = 0, min_index = 0, max_index = 4294967295,
restart_index = 21845, index = {resource = 0x0, user = 0x0}, indirect
= 0x0, count_from_stream_output = 0x0}
i = 
start = 1
#3  0x7fffc3271d58 in vbo_validated_drawrangeelements
(ctx=ctx@entry=0x589e1280, mode=mode@entry=5,
index_bounds_valid=index_bounds_valid@entry=0 '\000',
start=start@entry=0, end=end@entry=4294967295, count=count@entry=4,
type=5123, indices=0x2, basevertex=0, numInstances=1, baseInstance=0)
at vbo/vbo_exec_array.c:925
vbo = 
ib = {count = 4, index_size = 2, obj = 0x58fab6e0, ptr = 0x2}
prim = {mode = 5, indexed = 1, begin = 1, end = 1, weak = 0,
no_current_update = 0, is_indirect = 0, pad = 0, start = 0, count = 4,
basevertex = 0, num_instances = 1, base_instance = 0, draw_id = 0,
indirect_offset = 1}
#4  0x7fffc32724cf in vbo_exec_DrawElements (mode=5, count=4,
type=5123, indices=0x2) at vbo/vbo_exec_array.c:1075
ctx = 0x589e1280
#5  0x75ec9d5f in QOpenGLFunctions::glDrawElements(unsigned
int, int, unsigned int, void const*) (indices=,
type=5123, count=, mode=,
this=0x591f09b8)
at /usr/include/qt5/QtGui/qopenglfunctions.h:752
offset = 
i = 0
gn = 
sms = 0x5932aed0
attrNames = 0x76382e10

e = 
dirty = 
indexBase = 0x0
indexBuf = 0x58b32b18
material = 
program = 
batch = 0x58b32ae0
this = 0x591f08e0
#6  0x75ec9d5f in
QSGBatchRenderer::Renderer::renderMergedBatch(QSGBatchRenderer::Batch
const*) (this=0x591f08e0, batch=0x58b32ae0) at
scenegraph/coreapi/qsgbatchrenderer.cpp:2360
offset = 
i = 0
gn = 
sms = 0x5932aed0
attrNames = 0x76382e10

e = 
dirty = 
indexBase = 0x0
indexBuf = 0x58b32b18
material = 
program = 
batch = 0x58b32ae0
this = 0x591f08e0
#7  0x75ecafa5 in QSGBatchRenderer::Renderer::renderBatches()
(this=this@entry=0x591f08e0) at
scenegraph/coreapi/qsgbatchrenderer.cpp:2569
b = 
i = 2
r = {x1 = , y1 = , x2 =
, y2 = 2159}
renderOpaque = 
renderAlpha = 255
#8  0x75ed06f4 in QSGBatchRenderer::Renderer::render()
(this=) at scenegraph/coreapi/qsgbatchrenderer.cpp:2763
timer = {t1 = -9223372036854775808, t2 = -9223372036854775808}
timeRenderLists = 0
timePrepareOpaque = 0
timePrepareAlpha = 0
timeSorting = 0
timeUploadOpaque = 0
timeUploadAlpha = 0
largestVBO = 

Re: [Mesa-dev] [RFC] radeonsi: guard against indexbuf not being set

[Clemens Eisserer]

Hi,

>> This is a RFC because I don't really know what I'm doing here. But we
>> have this problem with AMD and KWin already for quite a long time and
>> I hope it can be fixed now.
> If index_size > 0, indexbuf should always be non-NULL. This is a bug
> somewhere else.

I've also been bitten by this bug - is there any way to disable the
multi-threading, so I get at least a reasonable stacktrace?

Thanks, Clemens
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] mesa 18.0.0-rc4

[Clemens Eisserer]

Hi,

> The fourth release candidate for Mesa 18.0.0 is now available.

Too bad it will ship with regression 105171 unfixed :/

- Clemens
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] XPutImage performance off cliff running glamor on top of radeonsi >= 17.3.0

[Clemens Eisserer]

Hi,

The following change towards 17.3.0 seems to cause servre performance
regressions in radeonsi for glamor based workloads when XPutImage is
involved (typically quite common for X11 apps):
https://bugs.freedesktop.org/show_bug.cgi?id=105171

I didn't notice it until recently, when Fedora27 was updated to 17.3.4 :/

x11per -putimage10 regressed from 75 kOps/s to 22 kOps/s after this
patch running Xephyr with vblank disabled.

before:
 40 reps @   0.0130 msec ( 77000.0/sec): PutImage 10x10 square

after:
 12 reps @   0.0457 msec ( 21900.0/sec): PutImage 10x10 square


Best regards, Clemens


8b3a257851905ff444d981e52938cbf2b36ba830 is the first bad commit
commit 8b3a257851905ff444d981e52938cbf2b36ba830
Author: Marek Olšák 
Date:   Tue Jul 18 16:08:44 2017 -0400

radeonsi: set a per-buffer flag that disables inter-process sharing (v4)

For lower overhead in the CS ioctl.
Winsys allocators are not used with interprocess-sharable resources.

v2: It shouldn't crash anymore, but the kernel will reject the new flag.
v3 (christian): Rename the flag, avoid sending those buffers in the BO list.
v4 (christian): Remove setting the kernel flag for now

Reviewed-by: Marek Olšák 

:04 04 b775b6b0ea5b971d2165a644ea8912c120f54431
2e4b2737f37ede2bbdbbe6815fe0fa562177c2b7 M  src
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] ralloc: use jemalloc for faster GLSL compilation

[Clemens Eisserer]

Hi,

> The GLSL compiler can be slowed down significantly by keeping 5x
> LLVMContext in memory between compilations in radeonsi. The fact that
> radeonsi can indirectly slow down the GLSL compiler (but not LLVM) is
> a strong indication that we have a problem.

This will mean there will be two heap regions in virtual adress space.
As high-performance malloc implementations are quite greedy releasing
memory back to the kernel - wouldn't it be good to have at least some
numbers regarding memory footprint before making jemalloc the default?

Br, Clemens
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] ralloc: use jemalloc for faster GLSL compilation

[Clemens Eisserer]

Hi Marek,

> The diff is -10.5% for a full shader-db run.

Interesting finding, did you also have a look at the memory footprint (rss)
during the shader-db Run (average and Spikes)?

Br, Clemens
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 10.4 still reports only OpenGL 3.0 on SNB

[Clemens Eisserer]

Hi Ki'Sak,

 Tools like glxinfo should be giving you two lines that report what is
 exposed, you should look for OpenGL core profile version string: as well
 as OpenGL version string:

And so it, no idea how I could have missed it:
 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.4.0

Thanks a lot for the pointer and your patience.

Best regards, Clemens
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Mesa 10.4 still reports only OpenGL 3.0 on SNB

[Clemens Eisserer]

Hi,

I just noticed mesa 10.4 still only reports OpenGL 3.0 compatibility
on my SNB notebook:

 OpenGL version string: 3.0 Mesa 10.4.0

Is there something wrong with my setup or is OpenGL-3.0 the best I can
get with Sandybridge for now?

Thanks and best regards, Clemens
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] Enable GL 3.2 support for i965, bump Mesa version.

[Clemens Eisserer]

Hi Kenneth,

 export MESA_GL_VERSION_OVERRIDE=3.2
 export MESA_GLSL_VERSION_OVERRIDE=150

 These make the driver claim OpenGL 3.2 and GLSL 1.50 support, even
 though it's incomplete.

 OilRush ought to work fine with those set.

 I haven't tried Dear Esther since it doesn't appear that there's a
 native Linux client in Steam yet.  But you could give it a try.

I've just tried dear esther with mesa 10.0.3 and the overrides you
suggested and all I get is still:

X Error of failed request:  GLXBadFBConfig
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  34 ()
  Serial number of failed request:  186
  Current serial number in output stream:  185

Seems in this case I got fooled, thinking my 1-2y old GPU would have
compareable opengl support to the windows version.
Although in general intel's linux drivers are really great, in this
regard I am stuck with a game I bought and can't play :/

Regards, Clemens
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] Enable GL 3.2 support for i965, bump Mesa version.

[Clemens Eisserer]

Hi,

 I believe geometry shaders are all we would have to implement for Sandy
 Bridge.  Unfortunately, geometry shaders work pretty differently on Sandy
 Bridge, so getting them to work won't be a slam dunk.  Here's roughly what
 would have to be done:

This is too sad - I had the impression mesa-10 would bring opengl-3.3
to my SNB laptop I bought last year.
I usually don't play computer games, but recently bought two games
refusing to start (dear esther and oil rush) because both require ogl
= 3.2.

Regards, Clemens
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 9.2 release candidate 2

[Clemens Eisserer]

Hi,

 I have verified building from the .tar.bz2 file by doing:

 tar -xjf Mesa-9.2.0-rc1.tar.bz2
 cd Mesa-9.2.0-rc1
 ./configure --enable-gallium-llvm --with-llvm-shared-libs
 make -j6

I tried to compile it on Fedora-19 + updates-testing with:
  ./configure --with-dri-drivers=i965 --with-gallium-drivers=
--enable-32-bit --enable-64-bit
  gmake

and ended up with:

[ce@localhost Mesa-9.2.0-rc2]$ gmake
CDPATH=${ZSH_VERSION+.}:  cd .  /bin/sh
/home/ce/Mesa-9.2.0-rc2/bin/missing --run aclocal-1.12 -I m4
/home/ce/Mesa-9.2.0-rc2/bin/missing: line 51: aclocal-1.12: command not found
WARNING: 'aclocal-1.12' is missing on your system.  You should only need it if
 you modified 'acinclude.m4' or 'configure.ac'.  You might want
 to install the Automake and Perl packages.  Grab them from
 any GNU archive site.
 cd .  /bin/sh /home/ce/Mesa-9.2.0-rc2/bin/missing --run
automake-1.12 --foreign
/home/ce/Mesa-9.2.0-rc2/bin/missing: line 51: automake-1.12: command not found
WARNING: 'automake-1.12' is missing on your system.  You should only need it if
 you modified 'Makefile.am', 'acinclude.m4' or 'configure.ac'.
 You might want to install the Automake and Perl packages.
 Grab them from any GNU archive site.
CDPATH=${ZSH_VERSION+.}:  cd .  /bin/sh
/home/ce/Mesa-9.2.0-rc2/bin/missing --run autoconf
/usr/bin/m4:aclocal.m4:1379: cannot open `m4/libtool.m4': No such file
or directory
/usr/bin/m4:aclocal.m4:1380: cannot open `m4/ltoptions.m4': No such
file or directory
/usr/bin/m4:aclocal.m4:1381: cannot open `m4/ltsugar.m4': No such file
or directory
/usr/bin/m4:aclocal.m4:1382: cannot open `m4/ltversion.m4': No such
file or directory
/usr/bin/m4:aclocal.m4:1383: cannot open `m4/lt~obsolete.m4': No such
file or directory
autom4te: /usr/bin/m4 failed with exit status: 1
gmake: *** [configure] Error 1


Regards, Clemens
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 9.2 release candidate 2

[Clemens Eisserer]

After performing autoreconf -fi I get a bit further:

/usr/bin/ld: .libs/entry.o: relocation R_X86_64_32S against
`_glapi_Dispatch' can not be used when making a shared object;
recompile with -fPIC
.libs/entry.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
gmake[4]: *** [libglapi.la] Error 1

Sorry for the spam...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev