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 paramete
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 th
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
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 u
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 hea
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
htt
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) Mes
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
___
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 the
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 me
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
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-ga
12 matches
Mail list logo