nelsoncs

After yet another reboot, things look good, no longer any problem, Thanks.

Also, tried to re-log to no avail.

Thanks, Josh. Just to clarify I am asking about A750/A770 cards, not necessarily the integrated graphics. Afaik both are XE architecture based.

I tried several of the benchmarks and see the Vulkan benches running fine, ultraengine and ultraengine 2023 either return immediately or give an empty window. Am I missing a win11 driver or is this gpu not supported. Thanks.

moved the .steam directory to a backup, reinstalled steam from scratch and now the lib is x64. still don't know why the heck steam decided to move me to 32 bit but... don't care now. Thanks for steering me in the right direction, aiaf. Submitted as bug report.

so, you are right except I have no idea why I have ended up with an i386 version of the leadwerks.lib. I have a backup from the leadwerks 3.2 era (before the full steam integration) and : objdump -a '~/src/Leadwerks_3_2/Library/Linux/Debug/Leadwerks.a' In archive ~/src/Leadwerks_3_2/Library/Linux/Debug/Leadwerks.a: Address.o: file format elf64-x86-64 rw-rw-r-- 1000/1000 96864 Sep 18 09:40 2014 Address.o I also tried having Steam perform the "validate cache" on my .steam install and it wants to replace 5090 files, if allowed to do this, it will still consider them invalid and rinse, repeat. So, it seems like it is possiblethis is really a problem with my steam installation

objdump -a ./libLeadwerks.a In archive ./libLeadwerks.a: Address.o: file format elf32-i386 rw-rw-r-- 1000/1000 70748 Sep 22 12:51 2015 Address.o (deleted rest of output) objdump -i '/home/develop/.steam/steam/SteamApps/common/Leadwerks Game Engine/Library/Linux/Debug/Leadwerks.a' BFD header file version (GNU Binutils for Ubuntu) 2.25.1 elf64-x86-64 (header little endian, data little endian) i386

Thanks, yes I already checked with objdump and elf64-x86-64 was top of the list. Linux: Ubuntu 15.10 uname -a: Linux higgie 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux gcc: g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)

Anyone have a clue how this has foobar'd for me? 1. updated through steam -> no effect 2. clean build -> no effect -lRakNetDLL (/home/<usr-name>/src/RakNet_PC-4.08/Lib/DLL/libRakNetDLL.so) -lopenal (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libopenal.so) -lGL (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libGL.so) -lGLU (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libGLU.so) -lsteam_api (/home/<usr-name>/.steam/steam/SteamApps/common/Leadwerks Game Engine/Library/Linux/libsteam_api.so) -lX11 (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.so) /lib/x86_64-linux-gnu/libpthread.so.0 /usr/bin/ld: skipping incompatible /home/<usr-name>/.steam/steam/SteamApps/common/Leadwerks Game Engine/Library/Linux/Debug/libLeadwerks.a when searching for -lLeadwerks /usr/bin/ld: cannot find -lLeadwerks collect2: error: ld returned 1 exit status makefile:60: recipe for target 'Server' failed make: *** [server] Error 1 Thanks.

I can assure you that is definitely not the case, Intel Wants Leadwerks and all of us to succeed. Intel is a very large ship and one that thus turns very slowly. At each level, there are priorities surrounding a very large work load. Each group, org, manager and code owner has a given set of priorities that drive the daily effort. With this in mind, I made the suggestion to try an obtain and IPS ticket because these usually one of the driving priorities for individual code owners. We also don't know what is required to reinstate the old driver set or configure the newer driver set for backwards compatibility. The simplest changes are bug fixes, but sometimes a design change or specification change is needed which can be a much more involved process (think committees, meetings and so on). In addition, any change to support Leadwerks must be QA'd to make sure nothing else breaks. So, my suggestion has been to try and get our problem into the internal ticketing system for the correct group, keep poking on the ticket every one or two weeks and hang on for the ride. hah. Anyway, I know my comments don't really resolve the issue but I hope they help to give some confidence that a resolution will occur.

Have you tried : http://www.intel.com/p/en_US/support?iid=hdr+supportf. ( You probably have). Alternatively, if you own any Intel development products or can establish a customer relatinoship with Intel that includes IPS, you may be able to get an IPS (Intel premier support) ticket. That would be the best way to get some action as the tickets typically are reviewed and as many as possible closed out each Friday.

Yes, unfortunately Valgrind is only available for Linux and Unices. It is a fantastic tool and super easy to use. I often make it my first line of debugging info for C++ because so many bugs also cause memory leaks. Probably the only real drawbacks are the slow runtime (unavoidable) and large amount of debug output.

This may be helpful, Intel has recently found a remediable issue related to Mesa. The patch may not be mainline until linux 3.18 according to the article (ubuntu 14.10 is currently at 3.16). http://news.softpedia.com/news/Massive-20-Improvement-to-Land-in-Intel-s-Mesa-Driver-Thanks-to-Valve-s-Efforts-464233.shtml

I recently updated my Leadwerks 3.1 (standalone) using the LeadwerksUpdater program under Linux. My programs now seg fault during the map loading. This includes a new empty map made using the standalone map editor which self-identifies as 3.2. The project has been cleaned and recompiled. Also note that the update broke more than one thing, even though this is not the steam version of Leadwerks, a version of libsteam_api.so was installed in the base Leadwerks directory. 1. LD_LIBRARY_PATH had to be updated. 2. the installed libsteam_api.so failed with a complaint about: ./Leadwerks: error while loading shared libraries: libsteam_api.so: wrong ELF class: ELFCLASS64 3. Replacement with the libsteam_api.so found under .steam seemed to fix the error. "Error: Map file version 29 not supported." What map version should be in use?? and How does one check the version for a given map file.

Gawd, thank you so much for lines numbers Klepto2!!