duzenko
-
Posts
4149 -
Joined
-
Last visited
-
Days Won
50
Posts posted by duzenko
-
-
OKWhenever you're ready, please develop a patch to test for the appropriate GL capability, set a flag accordingly, and replace the "if (1)" check with "if ({flag-name})". Shoot me the patch, I'll test it out thoroughly, and check it into SVN when it's working. Sound good?
-
Probably not worth trying.No. I'm running 304.132 (circa 26 Sep 2016). The latest is 304.134. I'd already downloaded it 2 days ago but haven't installed it because the changelog between 304.132 and 304.134 has only 2 entries, neither of which seemed to be relevant to this issue. At some point, I will upgrade the video driver, but I didn't want to do that in the middle of testing. Something I did do (but failed to mention) -- I removed the 2nd video card (the 640GT), but it offered no improvement. I left it out for now anyway.
...
Thanks for the suggestion. I will try that at my next opportunity and report back.
They have stopped supporting 7600gt years ago, so Sep 2016 is as good as any other.
And EXT_pixel_buffer_object is not in the ext list either.
...
I wonder how many people run TDM on gt7000 generation gpu's.
I used to own one and it was great until it burned.
Happy for them if they run TDM under windows so that the pixel pack thingy is functional.
I wish there was a way to enable it under Linux but regret nVidia decided to screw the Linux guys on this one.
-
I'm no OpenGL guru but I think that's something else.GL_EXT_packed_pixels
I think we should be looking for one of these: ARB_pixel_buffer_object and EXT_pixel_buffer_object.
Apparently your Linux driver is not advertising any of these even though the hardware is probably capable so technically it's correct and the fault is in my code.
My excuse is
1 - none of the pixel pack examples on web are doing the ext check
2 - 7600gt is really old
3 - windows driver supports this ext and 7600 gt is known to be 2.1 compatible
4 - most of people with dual card system run their 3d games on the newer card
But it's still my fault of course.
Here's how it looks for me (intel 515)
-
So in the end it's what appears to be a driver bug.As an aside, I also tested with the same exact hardware, but using 2.05-beta under Windows XP. It runs fine there, which tends to make me suspect a video driver issue rather than the video hardware. Regardless, the patch needs hardening.
Is your driver the latest for this GPU?
What is the reported opengl version? I think it should be 2.1 for pixel pack.
I absolutely agree that there should have been more checks on glGetError.
I will fix that when I'm back unless someone fixes it before.
...
What happens if you replace GL_PIXEL_PACK_BUFFER with GL_PIXEL_PACK_BUFFER_EXT?
-
Will do, ETA 27.12.16.
-
Sadly, while this change did offer a nice little performance boost, it was completely blown out by Duzenko's awesome
"Pixel Pack Buffer" optimization which offered a HUGE performance boost.
Thus relegating my fix to thecategory of "a minor improvement".
Pixel pack may show more difference on a fully-clocked system, but my laptop CPU throttles all the way to 1.1GHz under full load and your optimization makes a better job in that case.
-
2
-
-
Can't comment on Baal's error since I don't have access to that forum and Baal is not posting here.
R_ParseImageProgram_r is old code that has not been changed for years. Problem could be in code that executes before that, e.g. idImage::GenerateImage but since neither you nor me can repeat the error then we can't prove it is fixed.
VC was short for videocard. I think the 640 you have as secondary output is way newer and more powerful than 7600gt.
My suspicion here is that 7600gt may not fully support the pixel pack feature on the hardware level.
So running TDM on 640 would tell us if TDM maybe is not properly checking if the driver/hardware supports the required feature before using it.
I will be traveling for the next 7 days and will be AFK most of the time. I hope it's not going to be a big inconvenience for you. I just want you to know that Linux build is priority #1 right now for me when it comes to TDM.
-
Yes, but I have no idea what version of GCC comes with Ubuntu 16.10. Can you please run 'gcc --version' and report that (both now and anytime you switch to another Linux distro for compiling)?
Thanks for the URL. It looks like it will be useful at some point.
gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
-
Where to from here?
Has the svn access been granted finally?
Should I ifdef this in the mean time?
...
Nightstalker,
you mentioned you have 7600gt as primary and a newer one as secondary.
I'm curious if recent TDM crashes when running on a newer VC monitor?
-
Parts of this discussion are not really technical IMHO and would be irrelevant flood in there
-
I did not put cvar because I did not expect any blowback and did not have access to svn
Still need to confirm that's it.
Not sure if cvar is optimal solution if it works on windows and not on linux - ifdef?
The if (1) is just a toggle-able alternative to //
I used it in a couple more places since then.
-
As for the memcpy crash.
There is one memcpy in the code I contributed:
void idRenderSystemLocal::CaptureRenderToBuffer(unsigned char* buffer)
Does it crash if you toggle the
if (1)
in there?
-
In fact, I've gone beyond that, bisecting the source code backwards from the latest SVN and building TDM many times, to try to identify the change(s) that cause the crash. But I gave up in frustration (and exhaustion) after finding a reference point (SVN #6642) that successfully compiled but, sadly, failed to actually run a mission. Since I obviously didn't make any of those SVN commits between 2.04 and 2.05 (let alone between 2.04 and latest SVN), I'm not best qualified to determine what broke the build. And I stated as much in my post about all this.
When Baal asked (on Dec 8th) for the 2.05-beta source code, which is something I was 1 breath away from doing myself, he's told to "PM taaaki". Both he and I PMed taaaki for access to the source code, myself on 10 Dec 2016. Today, 9 days later, I still have not gotten a reply to that PM.
I'm still waiting Taaki to answer my month-old request
It's not like he ignores you only. #6642 crashes for you - how about #6640 or #6637?
I could probably upload a particular svn branch if you aren't granted access in the next hours.
P.S. I really appreciate your efforts, and I admire the "do it now" spirit a lot. AFAIR Grayman warned that he has really little time this time of year.
-
NightStalker,
It's ubuntu 16.10 32-bit, default gcc that comes with it.
My web searches resulted in this
I had no time to test this just yet
One thing I should probably mention is that Compilation guide did not exactly work for me.
sudo apt-get install g++ scons libglew1.5-dev libpng12-dev libjpeg62-dev
threw errors beyond my understanding so I dropped 1.5 and 12 and 62.
-
I was going to apply it in trunk w/o testing but I was confused by people in this thread who said they had applied it.
Now I leave it to Grayman.
So, umm... Hamlet, Crinkelite, you compiled 2.04, or 2.05, or trunk?
-
NightStalker,
Can you try image_mipmapMode 0?
I also have this error when compiling trunk under 32-bit ubuntu:
In file included from game/script/Script_Doc_Export.cpp:26:0: game/script/../pugixml/pugixml.hpp:1070:2: error: reference to ‘basic_string’ is ambiguous std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > PUGIXML_FUNCTION as_wide(const char* str); ^~~ In file included from game/script/Script_Doc_Export.cpp:26:0:
-
Hm, if you had 3 fps on HD4250 before then 9 fps on 720 must absolutely feel smooth
-
@ demagogue, this gtx 720 runs TDM so well that I am not even in a rush to replace it!
How about the ship deck in Down by the riverside in 1080p?
-
Is there a stack trace maybe?But although it compiles, it won't actually run the game very well. It crashes just like the 2.05-beta does -- as soon as you try to start the mission by hitting the 'Attack' key, it aborts with a segfault from a 'memcpy()' call.
-
Absolutely cancel and reorder a similar item.
They are all more or less the same.
-
Frankly, I'm not a big C++ guy -- I avoid it whenever I can, strongly preferring good, old-fashioned C.
Neither am I but the good news is most of TDM sources are as C as C++ goes.
I would really try the qgl thing first because it's easy and can actually work.
Just get the last svn rev because I did some changes in that area today.
-
I am not a native English speaker so I can't always articulate right.
What I was trying to say is that I only compile TDM code on Windows and if any of it breaks Linux build then it's my problem and duty to fix.
Now this use_qglDisable is never seemingly used in TDM at least "Find all" in VisualStudio gives 0 matches.
My guess it is stumbling on calls of functions glViewport, glEnable, etc? What happens if you add a 'q' in the start, i.e. qglEnable, etc?
This entire 'qgl' thing is a mystery to me.
-
And, IIUC, there was a change that went into SVN that further broke things under Linux:
That's my code. What's wrong with it?
-
There is this "PCIe certified" thing that is kinda supposed to tell that any extension card is compatible with any extension slot so that consumers don't need to play game of chance with their money.
Also I remember a heated discussion about a particular Radeon sucking _more_ than 75W. One of the arguments was "NVidia does this shit right".
LOL check that piano price first
Getting 2.05-beta To Compile and Run Under Linux
in TDM Tech Support
Posted
SVN revision: 6735