If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
*cough* *cough* ... an english version of the code doesn't exist lol from what was said that would be a project. Perhaps I am wrong but kickstarter seems to be ok with such projects I didn't see anything in the guidlines I thintk it would be how you defined it though... pay to open souce titaniumGL vs Project to release titaniumGL source and translate it to english. Then it would have a defined beginning and end... the release of the source and completion of being translated to english.
Oh well... you guys were practically devolving into a flame war so I figured I might suggest some possible solution and as you said other sites definitly do allow such projects. I mean for crying out loud get a life people! I was reading stuff on the kwin developer's blog about TDE and basically how he is pissed off at them for renaming kwin to twin (sensible thing to do really..) and how he is throwing a tantrum and refusing to tell timothy pearson where some of the code he has changed will supposedly lead to twin not starting up X.x.
Oh well at least the guys working on mesa and X seem to generally have decent control over thier egos
*carry on* ... this is phoronix after all king of page views
-64-bit version released.
-fixed some stability issues
-TitaniumGL software renderer now uses packet-based out-of-order rendering, wich allows to incrase the number of rendering threads
-Software rendered version can now utilize up to 24 cores.
-TitaniumGL now uses smaller memory stack
-1.5x-2x speed-up in the software renderer when using 4 core computers
-There is a modern and a legacy versions, compiled with different gcc-s. Legacy version is for old distributions.
i hope this version will fix the crash problems on vesa driver too. at least it worked okay for me.
get it while its hot:
#0 0x00007ffff767375e in HaromszogRenderel_szuperthread () from /home/foo/Downloads/TitaniumGL/64bit/libGL.so.1
#1 0x00007ffff767b3eb in haromszogekki_szuperthread () from /home/foo/Downloads/TitaniumGL/64bit/libGL.so.1
#2 0x00007ffff767b724 in haromszogek0ki_szuperthread () from /home/foo/Downloads/TitaniumGL/64bit/libGL.so.1
#3 0x00007ffff675cdd2 in start_thread () from /usr/lib/libpthread.so.0
#4 0x00007ffff5604cdd in clone () from /usr/lib/libc.so.6
But with intel and MESA_GL_VERSION_OVERRIDE=1.4 minetest it runs.
Performance is meh, but it's probably not far from what a software renderer can do, even when rendering rather inaccurate. Fonts are not accurate, sort of an interlacing effect. supertuxkart sort of renders mostly correctly ~1-2 fps, maniadrive renders pretty much incorrectly with heavy jumps between frames, ~1 fps.
openarena on 640x480 has sort of playable fps. On a related note, openarena by default will start in fullscreen and disable your second monitor and exiting it will leave you with cloned screens instead of side by side like you had set up before. Guys, it's 2013. Get this right, please.
By the way, when running minetest in gdb, there is a huge number of threads created and destroyed that scroll by. And by huge I mean huge. Maybe you can get more performance when reusing threads.
hi, thanks, i will check that game, becouse that crash should not happen on that place.
reusing threads was alreday in plan, but for security reasons, not yet tryed how it perform.
(also there is not so huge amout of threads executed, so it should not affect negatively the performance)
also, what computer do you have? supertuxkart should be playable on a recent 4 core cpu (20 fps+)
but it's probably not far from what a software renderer can do
oh.. well... umm.. there is 10-40x faster rasterer algos exist than my algo
in the last year somebody shown a raster algorithm that consumes only 4-10 clock per pixel (including texturing)
if the really smart peoples would put they head together, to write a very fast software rasterizer, it would basically outperform on 4 cores every graphics card and igp's cheaper than 200 usd. however, when a very fast software renderer appears, nvidia and amd outbuys them immediately, and digs them very deeply (nobody would hear from them any more). for obvious reasons.
-Well a few days still left until 2014, whatever
-Added mip-mapping support for the software renderer
-5-25% generic performance gain
-Fixed some ,,dotting'' bugs with the software renderer
-Fixed some segmentation fault bugs (texture upload forgot to lock rendering...)
-Fixed a memory-pool related crash on linux
-32 bit binary now compiled again with i686 flag
-Software renderer now supports up to 128 threads instead of 24