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
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
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
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
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
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
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 there's a
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
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
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
12 matches
Mail list logo
