Re: [Mesa-dev] [RFC] ralloc: use jemalloc for faster GLSL compilation
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] [RFC] ralloc: use jemalloc for faster GLSL compilation
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] [PATCH 0/3] Enable GL 3.2 support for i965, bump Mesa version.
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
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
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
Re: [Mesa-dev] [PATCH 0/3] Enable GL 3.2 support for i965, bump Mesa version.
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
[Mesa-dev] Mesa 10.4 still reports only OpenGL 3.0 on SNB
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] Mesa 10.4 still reports only OpenGL 3.0 on SNB
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] XPutImage performance off cliff running glamor on top of radeonsi >= 17.3.0
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] [ANNOUNCE] mesa 18.0.0-rc4
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
Re: [Mesa-dev] [RFC] radeonsi: guard against indexbuf not being set
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] [RFC] radeonsi: guard against indexbuf not being set
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 =
largestIBO = 1512
#9 0x75ec1070 in QSGRenderer::renderScene(QSGBindable const&)
(this=0x591f08e0, bindable=...) at
scenegraph/coreapi/qsgrenderer.cpp:243
bindTime =
