Jump to content
The Dark Mod Forums
Sign in to follow this  
NightStalker

Getting 2.05-beta To Compile and Run Under Linux

Recommended Posts

Folks, I've decided to start a new thread on this since the other recent Linux threads are not really the appropriate place (IMHO) to discuss the gory details about fixing the 2.05-beta source code so that it compiles and runs under Linux.

Unfortunately, there is already some existing discussion about compiles against 2.05-beta (and "latest SVN") mixed about in these 2 threads:

To start this thread off, I'm replying to this post by duzenko.

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?

 

Good news!

I tweaked the 'if (1)' line (in 'renderer/RenderSystem.cpp') to be 'if (0)' then rebuilt and ran TDM.

Although, IMHO, this is a rather haphazard way to go about things (I'd prefer to run a debugger, with full source code available), it looks like you may have hit the nail on the head, duzenko!

Note: I'm using SVN revision #6642 to run this test since that's the only one I'd gotten to successfully build when I last gave up on this. And I'm running with the 2.04 (not 2.05-beta) PK4 resources, so this test isn't as "pure" as I'd like it to be. But the 2 missions ("Closemouthed Shadows" and "The Outpost") which had been immediately failing (at the 'memcpy()') after the "Press 'attack' to start the mission" point are now running!

Now, be aware that the crashes that Baal experienced appeared to be different than my crashes, so please don't consider this problem solved just yet! But it's an important first step.

I tried to do some further testing, but ran into limitations of my memory of certain SVN commands, so that will have to wait for another day.

  • Like 1

Share this post


Link to post
Share on other sites

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?


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

Has the svn access been granted finally?

No, but that's entirely irrelevant. I really don't need SVN write access now (but will accept the privilege, as I explained in that other thread). All I really wanted was read-only access (via SVN or any other way) to the actual 2.05-beta source code and given that grayman has already explained how he built the various 2.05-beta releases from SVN, I should be able to replicate that using the public, read-only SVN repository (once I study up on SVN a bit to refresh my aging recall!). To be clear, I have no intention of committing any changes to SVN to fix these 2.04->2.05 transition problems. I'm counting on you, duzenko, to do that, since the changes that aggravated the Linux situation are apparently yours. I'll help anywhere and everywhere I can (testing, etc), but the actual code changes made to SVN for now must be done by you. For the record, I don't understand OpenGL and/or the rendering changes you've made in this area, so I'm incredibly reluctant to mess with any of that, even just to "fix" the build.

Where to from here? [...] Should I ifdef this in the mean time?

That's up to you, IMO. Since I don't understand what's going on with your changes, I have no advice to offer. I hope your question was directed more at grayman and/or nbohr1more than at me.

 

I will say again that I don't think anyone should consider this issue 100% solved yet. Until Baal "weighs in" on whether his crashes are solved, we cannot celebrate too much.

 

Also, I want to do a lot more building and testing before even I say, with confidence, that my issues are solved.

 

Duzenko, I hope you are giving some thought as to why this 'memcpy()' is crashing under Linux (and, conversely, presumably, not under Windows). I took a quick look, but the buffer you're writing to (and presumably overflowing or using a bad pointer to) was passed as a parameter to the routine being called, so I didn't go chasing it any further. I'm counting on you to understand what's happening at a deep enough level that we're not just "wallpapering" a crude fix.

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?

This may be a bit of the language barrier, but I'm not 100% sure I understand you. What is "VC"? "Video Card"? For now, I'll assume that you're asking if TDM crashes when I use the 2nd video card as the primary. I've never tested that. It's been on my list of "curiosities, to be tested" for about 2 weeks now (EDIT: merely to see if it affects mission load times, not for crash testing), but that's WAY down on my priorities list. And, while the 2nd video card has more video RAM than the 7600GT, it has (IIRC) lower overall performance. And this setup is not for gaming, as some might have assumed, so I'm disinclined to change it. One day this video-card-changeout experiment will happen, but not soon. The only thing I'd be willing to do soon to solve a TDM problem would be to pull the 2nd video card. But I've been running TDM 2.04 (for the last 2+ weeks) with both video cards with no problems at all.

Edited by NightStalker

Share this post


Link to post
Share on other sites

Duzenko, it just occurred to me that I have not seen you post in the private "TDM Mission Beta Testing" forum's thread titled "Beta Testing 2.05". If you're not already part of that group, you should be, IMHO.

 

Since Baal's crash information was posted there, I'm going to replicate his post here, in case anyone who should be seeing it has not:

The segfault occured here:

#0  0x08102ee4 in R_ParseImageProgram_r(idLexer&, unsigned char**, int*, int*, long*, textureDepth_t*) ()
#1  0x08103037 in R_LoadImageProgram(char const*, unsigned char**, int*, int*, long*, textureDepth_t*) ()
#2  0x080fe656 in idImage::ActuallyLoadImage(bool, bool) ()
#3  0x080ef527 in idImageManager::EndLevelLoad() ()
#4  0x081457cd in idRenderSystemLocal::EndLevelLoad() ()
#5  0x080c413e in idSessionLocal::ExecuteMapChange(bool) ()
#6  0x080c4d72 in idSessionLocal::StartNewGame(char const*, bool) ()
#7  0x080c5247 in Session_Map_f(idCmdArgs const&) ()
#8  0x08055903 in idCmdSystemLocal::ExecuteCommandText(char const*) ()
#9  0x080bbb7b in idSessionLocal::HandleMainMenuCommands(char const*) ()
#10 0x080bc05c in T.1593 ()
#11 0x080bc1be in idSessionLocal::GuiFrameEvents() ()
#12 0x080c5ad3 in idSessionLocal::Frame() ()
#13 0x0805c94d in idCommonLocal::Frame() ()
#14 0x082ad83d in main ()
I could investigate further if i had the current source and a debug build.

 

I see no immediate evidence that his crash was related to the changes you made, duzenko. But if you understand this area of the code at all, could you please trace his crash backwards from the 'R_ParseImageProgram_r()' call (in file 'renderer/Image_program.cpp') to see if you can possibly explain his crash, even a little?

 

I took a quick look, but this area of the code is "Greek to me". And my testing never resulted in a crash dump that looked anything like his.

 

Any comments you have are appreciated!

Share this post


Link to post
Share on other sites

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.


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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.

OK, many thanks for looking into it. I agree that we're sort of at the mercy of awaiting more info from Baal. He hasn't logged in in several days. Let's proceed for now without his input.

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.

OK, thanks for the clarification. I will investigate this issue while you are away.

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.

That's unfortunate, but I'll do my best to proceed while you're away. Hope your travel is for pleasure and that you have a good trip! Come back well-rested -- we'll probably have some questions for you! ;):D

Share this post


Link to post
Share on other sites

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've just run 'glinfo' on the machine in question, with the 7600GT video card still in use as the primary card:

 

==> glinfo 
GL_VERSION: 2.1.2 NVIDIA 304.132
GL_RENDERER: GeForce 7600 GT/PCIe/SSE2/3DNOW!
GL_VENDOR: NVIDIA Corporation
GL_EXTENSIONS: 
   GL_ARB_color_buffer_float GL_ARB_conservative_depth
   GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers
   GL_ARB_explicit_attrib_location GL_ARB_fragment_program
   GL_ARB_fragment_program_shadow GL_ARB_fragment_shader
   GL_ARB_framebuffer_object GL_ARB_half_float_pixel
   GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_map_buffer_alignment
   GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query
   GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex
   GL_ARB_shader_objects GL_ARB_shading_language_100
   GL_ARB_shading_language_420pack GL_ARB_shadow
   GL_ARB_texture_border_clamp GL_ARB_texture_compression
   GL_ARB_texture_cube_map GL_ARB_texture_env_add
   GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar
   GL_ARB_texture_env_dot3 GL_ARB_texture_float
   GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two
   GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_swizzle
   GL_ARB_timer_query GL_ARB_transpose_matrix
   GL_ARB_vertex_buffer_object GL_ARB_vertex_program
   GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers
   GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc
   GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color
   GL_EXT_blend_equation_separate GL_EXT_blend_func_separate
   GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_Cg_shader
   GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord
   GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample
   GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters
   GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil
   GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_provoking_vertex
   GL_EXT_rescale_normal GL_EXT_secondary_color
   GL_EXT_separate_specular_color GL_EXT_shadow_funcs
   GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D
   GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc
   GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp
   GL_EXT_texture_env_combine GL_EXT_texture_env_dot3
   GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888
   GL_EXT_texture_lod GL_EXT_texture_lod_bias
   GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB
   GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_vertex_array
   GL_EXT_vertex_array_bgra GL_EXT_x11_sync_object GL_IBM_rasterpos_clip
   GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_alpha_test
   GL_NV_blend_minmax GL_NV_blend_square GL_NV_complex_primitives
   GL_NV_copy_depth_to_color GL_NV_depth_clamp
   GL_NV_fbo_color_attachments GL_NV_fence GL_NV_float_buffer
   GL_NV_fog_distance GL_NV_fragdepth GL_NV_fragment_program
   GL_NV_fragment_program_option GL_NV_fragment_program2
   GL_NV_framebuffer_multisample_coverage GL_NV_half_float
   GL_NV_light_max_exponent GL_NV_multisample_filter_hint
   GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_point_sprite
   GL_NV_register_combiners GL_NV_register_combiners2
   GL_NV_texgen_reflection GL_NV_texture_barrier
   GL_NV_texture_compression_vtc GL_NV_texture_env_combine4
   GL_NV_texture_expand_normal GL_NV_texture_lod_clamp
   GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2
   GL_NV_texture_shader3 GL_NV_vertex_program GL_NV_vertex_program1_1
   GL_NV_vertex_program2 GL_NV_vertex_program2_option
   GL_NV_vertex_program3 GL_OES_compressed_paletted_texture
   GL_OES_depth24 GL_OES_depth32 GL_OES_depth_texture
   GL_OES_element_index_uint GL_OES_fbo_render_mipmap
   GL_OES_packed_depth_stencil GL_OES_point_sprite GL_OES_rgb8_rgba8
   GL_OES_read_format GL_OES_standard_derivatives GL_OES_texture_float
   GL_OES_texture_float_linear GL_OES_texture_half_float
   GL_OES_texture_half_float_linear GL_OES_texture_npot
   GL_OES_vertex_half_float GL_SGIS_generate_mipmap GL_SGIS_texture_lod
   GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum
GL_SHADING_LANGUAGE_VERSION = 1.20 NVIDIA via Cg compiler
GLU_VERSION: 1.3
GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess 
GLUT_API_VERSION: 4
GLUT_XLIB_IMPLEMENTATION: 13

For clarity, I've split the huge line showing all the GL extensions into multiple lines, but you can see that the list includes this:

GL_EXT_packed_pixels
So I suspect that my 7600GT video card and/or the nVidia 304.132 driver is not the issue. But if there's something else I should try, please let me know.

 

Frankly, I really hope that nobody has been installing little "GL time bombs" in the code over the years, i.e. using a feature without checking for it being supported. I suspect that that could result in a lot of complaints about TDM not running on someone's PC (Windows or Linux) whereas a graceful degradation in the code would have avoided that.

Share this post


Link to post
Share on other sites

OK, after a few days of slow, careful, investigation as time was available, I think I've finally got a reasonable handle on the Linux crashes I've been seeing when running TDM 2.05-beta (and, as it turns out, when trying to run the hacked build I'd made from "latest SVN").

TLDR: Duzenko's "lightgem" patch (added via SVN rev #6635, specifically the portion that went into 'renderer/RenderSystem.cpp', BugTracker #4395) needs "hardening".

The consistent crashes I've been seeing right after pressing "attack" on the "Press 'attack' to start the mission" screen is indeed coming from the performance-enhancing "lightgem patch", but it's not where we were assuming. That is, it's in a 'memcpy()' call, but not the one that's directly in the patch. It seems to be in a 'memcpy()' call being executed as a result of a call made by the patch to this OpenGL library routine:

qglReadPixels(rc->x, rc->y, rc->width, rc->height, GL_RGB, GL_UNSIGNED_BYTE, 0);

This is based in part on evidence from examining the source code from the Mesa implementation of OpenGL.

But the reason TDM is crashing in that routine is because of one of several undetected 'GL error' conditions in a few of the earlier GL-related calls added by the patch, with 'qglBindBufferARB()' being the 1st of several that actually fail.

(This all took me a while because I had to learn enough OpenGL to make sense of things. I've never been a "GL guy" and hadn't even looked at any OpenGL code in over 13 years!)

Gory details: The failure of the initial 'qglBindBufferARB()' call, because of the use of the 'GL_PIXEL_PACK_BUFFER' enumeration as the 1st parameter, means that the 'qglReadPixels()' call's last parameter (0 in this patch's case) is NOT representing what the patch author thinks it is! Without the earlier GL calls succeeding, this call basically tries to pass a buffer location 0 (rather than the expected offset of 0) to the 'qglReadPixels()' routine which tries to 'memcpy()' using that bad pointer, resulting in the segmentation faults that I'm seeing.

So, the proper fix for this is to "harden" this patch's code by replacing the useless "if (1)" check with a check for GL 'pixel pack' capability. For optimal speed of execution in the area of the patch, there should be some code added to the part of the TDM code (presumably in 'R_CheckPortableExtensions()', in file 'renderer/RenderSystem_init.cpp') that checks for GL capabilities once, at GL initialization. Then that flag should be used in place of the existing "if (1)" check.

I've been running with this part of the patch disabled and have not encountered a single crash under Linux (using mostly 32-bit Slackware 14.2 but also testing briefly, both compiled and running, under 32-bit Slackware 13.1). I want to do more testing (with more missions than just "Closemouthed Shadows" and "The Outpost"), but so far, all has been fine, so I'm reasonably confident in my recommendations here.

For the record, I've seen no crashes like Baal has seen, so I still think that we must be prepared for that to be a different issue.

In retrospect, this patch should really not have gone into SVN. It was exactly the sort of "GL time bomb" that I mentioned in my previous post, awaiting an innocent victim with the right hardware+driver combination to come along. I wonder if there are other such 'GL time bombs' in the code. I hope not. :(

Some additional thoughts: As mentioned in my previous post, my GeForce 7600GT video card and 32-bit nVidia 304.132 driver advertise (via the 'glinfo' app) what appears to me (maybe naively) to be the necessary capability ('GL_EXT_packed_pixels') to successfully implement a call like this one in the patch:

qglBindBufferARB(GL_PIXEL_PACK_BUFFER, pbo);

And yet it consistently fails on that call with the GL error "GL_INVALID_ENUM", meaning that the use of 'GL_PIXEL_PACK_BUFFER' is not a valid case on this hardware+driver setup! So I don't think that the "GL capability" check that gets added to the GL initialization process should use the presence of 'GL_EXT_packed_pixels' as a "green light" to make such calls. I think it's far safer to do a sample, 1-shot "qglBindBufferARB(GL_PIXEL_PACK_BUFFER, pbo);" call and check the GL error condition, setting the "packed pixel capability flag" accordingly.

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.

So, if you folks can wait for duzenko to return and harden this patch, then I'll move on to looking into Baal's crashes (to the extent possible, with relatively little information). If not, I could try to come up with a patch to harden this "lightgem" code myself. Just let me know.

For anyone who's made it this far, sorry for the lengthy explanation. But I like to be thorough and I like to have things well documented.

If I've missed anything, please let me know.

  • Like 1

Share this post


Link to post
Share on other sites

Brilliant. I suggest waiting for duzenko. Bring him up to speed so he knows the fix, and let him fix it, since it's in his code. Verify the fix, check in the changes to the trunk, post the rev number(s).

 

You should move on to Baal's problem when you have the time.

 

Excellent analysis.

Share this post


Link to post
Share on other sites

Brilliant. I suggest waiting for duzenko. Bring him up to speed so he knows the fix, and let him fix it, since it's in his code.

Wilco.

Verify the fix, check in the changes to the trunk, post the rev number(s).

As far as I know, I only have read access to the private SVN. Taaaki hasn't told me otherwise. He said he'd grant me write access if you were OK with it. I told him I'm OK with whatever you folks decided to grant (read-only or read/write). I've verified that I can read, but have never tried to write.

You should move on to Baal's problem when you have the time.

Wilco.

Excellent analysis.

Glad you liked it. :)

 

I cannot promise the same for Baal's issue, though. That one might be tough since I cannot duplicate it. But we'll see. I'll PM him for more info. He's been on the forum, but hasn't said anything recently about his crash(es).

Share this post


Link to post
Share on other sites

Not to clutter up the discussion, but a very informative read. Thanks for the detail. I'm not a coder, but I do love reading and understanding what is going on behind the scenes.

  • Like 1

Share this post


Link to post
Share on other sites

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.

So in the end it's what appears to be a driver bug.

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?


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

@grayman: Taaaki has now granted me SVN write access. I appreciate your input to him on that.

So in the end it's what appears to be a driver bug.

It seems to be. But it also seems unlikely, but certainly not impossible, that such a major bug would go undetected. I suppose it could also be a difference between Linux's use of Mesa to implement OpenGL and whatever Windows uses, but that would start to quickly exceed my expertise.

Is your driver the latest for this GPU?

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.

What is the reported opengl version? I think it should be 2.1 for pixel pack.

Already reported ("GL_VERSION: 2.1.2 NVIDIA 304.132") in my post #8, above.

 

I should have mentioned it in my earlier post, but I'd already researched the necessary OpenGL version(s) needed for the various calls from your patch. I thought I had it all in my browser still, but cannot seem to find it now. But my recollection was that my reported GL version number was adequate in all cases.

I will fix that when I'm back unless someone fixes it before.

Sounds good... IIUC, the 2.05 release has been delayed until January. So our current plan is still the one shown in grayman's post #10, above.

What happens if you replace GL_PIXEL_PACK_BUFFER with GL_PIXEL_PACK_BUFFER_EXT?

Thanks for the suggestion. I will try that at my next opportunity and report back.

Share this post


Link to post
Share on other sites

GL_EXT_packed_pixels

I'm no OpenGL guru but I think that's something else.

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)

post-3508-0-19213900-1482576895_thumb.png


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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.

Probably not worth trying.

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.


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

Hey,

 

sry for the stupid question but how does one obtain the 2.05 beta branch if you wanna take a look at it? I am not so versed in using subversion but would like to try looking at the issue, i am using Fedora 25 so this might give you some more information on yet another development stack.

 

Greetings,

 

damiel

Share this post


Link to post
Share on other sites

Thanks for the suggestion. I will try that at my next opportunity and report back.

OK, I tried this and it offered no improvement, as you predicted. But it was easy enough to test, so I did it anyway just to be thorough. To be clear, I did the test only in a little hacked OpenGL program that I use to implement the same code that your patch does. It's simply way faster to test this way than building TDM, running it, and waiting for a mission to load every time I want to test tweaks to your patch. But, rest assured... my lengthy write-up above was based on many tests using both the OpenGL test app and using TDM.

1 - none of the pixel pack examples on web are doing the ext check

True, but very few of the OpenGL examples I see on the Internet do any sort of error checking, and certainly not in a portion of the code that's continuously executed. I know you're not suggesting as much, but I don't think we should ever use that approach as our guideline or standards. The TDM precedent that we must follow (IMHO) is to check the capabilities once, at GL initialization time, setting flags for later use in the code that's speed-sensitive but dependent on OpenGL version and/or capabilities.

2 - 7600gt is really old

Also true, but it still runs TDM just fine and I think you'd all agree that we should be as inclusive of older but still-capable video hardware as we can reasonably be.

4 - most of people with dual card system run their 3d games on the newer card

Undoubtedly true, but remember... this is not a gaming system (and I'm not a "gamer"). Take good advantage of guys like me with older hardware (and, in the rare case where I might fire up Windows [XP], older OSes) to root out any bad assumptions that may have slipped into the TDM code and/or the build process.

 

At the risk of confusing things, this is what my main PC (with built-in 'GeForce 6150SE' video, using the open-source 'Nouveau' video driver) reports:

 

 

==> glinfo
GL_VERSION: 2.1 Mesa 11.2.2
GL_RENDERER: Gallium 0.4 on NV4C
GL_VENDOR: nouveau
GL_EXTENSIONS: 
   GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color
   GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture
   GL_EXT_polygon_offset GL_EXT_subtexture GL_EXT_texture_object
   GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture
   GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters
   GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters
   GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp
   GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp
   GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_multitexture
   GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat
   GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix
   GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays
   GL_EXT_secondary_color GL_EXT_texture_env_add
   GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias
   GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent
   GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_SUN_multi_draw_arrays
   GL_ARB_texture_border_clamp GL_ARB_texture_compression
   GL_EXT_framebuffer_object GL_EXT_texture_env_combine GL_EXT_texture_env_dot3
   GL_MESA_window_pos GL_NV_packed_depth_stencil GL_NV_texture_rectangle
   GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow
   GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3
   GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_EXT_stencil_two_side
   GL_EXT_texture_cube_map GL_NV_depth_clamp GL_NV_fog_distance
   GL_APPLE_packed_pixels GL_APPLE_vertex_array_object GL_ARB_draw_buffers
   GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_shader_objects
   GL_ARB_vertex_program GL_ARB_vertex_shader GL_ATI_draw_buffers
   GL_ATI_texture_env_combine3 GL_EXT_depth_bounds_test GL_EXT_shadow_funcs
   GL_EXT_stencil_wrap GL_MESA_pack_invert GL_NV_primitive_restart
   GL_ARB_depth_clamp GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel
   GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_shading_language_100
   GL_ARB_sync GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object
   GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate
   GL_OES_read_format GL_ARB_pixel_buffer_object GL_ARB_texture_rectangle
   GL_EXT_pixel_buffer_object GL_EXT_texture_mirror_clamp
   GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_framebuffer_blit
   GL_EXT_packed_depth_stencil GL_ARB_vertex_array_object GL_ATI_separate_stencil
   GL_ATI_texture_mirror_once GL_EXT_gpu_program_parameters
   GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_OES_EGL_image
   GL_ARB_copy_buffer GL_ARB_half_float_vertex GL_ARB_map_buffer_range
   GL_ARB_texture_swizzle GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle
   GL_EXT_vertex_array_bgra GL_NV_conditional_render GL_ARB_ES2_compatibility
   GL_ARB_debug_output GL_ARB_draw_elements_base_vertex
   GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions
   GL_ARB_provoking_vertex GL_ARB_sampler_objects GL_EXT_provoking_vertex
   GL_EXT_texture_snorm GL_MESA_texture_signed_rgba GL_ARB_get_program_binary
   GL_ARB_robustness GL_ARB_separate_shader_objects GL_ARB_timer_query
   GL_ARB_compressed_texture_pixel_storage GL_ARB_internalformat_query
   GL_ARB_map_buffer_alignment GL_ARB_texture_storage
   GL_AMD_shader_trinary_minmax GL_ARB_clear_buffer_object
   GL_ARB_explicit_uniform_location GL_ARB_invalidate_subdata
   GL_ARB_program_interface_query GL_ARB_vertex_attrib_binding GL_KHR_debug
   GL_ARB_buffer_storage GL_ARB_multi_bind GL_ARB_texture_mirror_clamp_to_edge
   GL_ARB_get_texture_sub_image GL_KHR_context_flush_control
GL_SHADING_LANGUAGE_VERSION = 1.20
GLU_VERSION: 1.3
GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess 
GLUT_API_VERSION: 4
GLUT_XLIB_IMPLEMENTATION: 13

 

 

Notice that the capabilities list includes both 'GL_ARB_pixel_buffer_object' and 'GL_EXT_pixel_buffer_object'. And, indeed, on this PC, the calls that use the 'GL_PIXEL_PACK_BUFFER' enumeration as a parameter do not generate any errors. So I think you're 100% correct about the need for the "GL_{ARB,EXT}_pixel_buffer_object" capability and I now alter what I said in my earlier post to hereby suggest that we check for that extension rather than implementing my cruder, earlier suggestion of using a 1-shot test-call to "qglBindBufferARB(GL_PIXEL_PACK_BUFFER, pbo);".

 

Please note that the tests on my main PC with the built-in 'GeForce 6150SE' video were also done with a simple OpenGL test app and not the TDM app (because this PC is running 64-bit Slackware 14.2, without multi-lib [32-bit] capabilities, and cannot build or run TDM).

 

Most importantly, please don't beat yourself up too much over this, duzenko. While I still don't think the patch should have been put into SVN as it was, we can and will work together to fix this. While I spent more time on this than I would have preferred, I learned a lot in the process and I'll venture a guess that you did too. So let's forget about any "blame" or "excuses" and move forward on this, working together. I'm perfectly happy waiting until you're ready to deal with this, after your travels are over. When the time comes, just let me know how I can help. Whenever 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?

 

Don't give the issue any more thought or worry -- kick back, relax, and enjoy your time away. I'll be ready when you get back.

Share this post


Link to post
Share on other sites

sry for the stupid question but how does one obtain the 2.05 beta branch if you wanna take a look at it?

Hi, damiel... Not a stupid question at all.

 

Given your use of the phrase "development stack", I'm assuming that you actually want to compile, not just run, TDM 2.05-beta under Linux.

 

The 2.05-beta source code is tagged as such in a private TDM SVN repository. Access to it, even read-only access, requires approval from the TDM project leaders. (Personally, I would prefer the 2.05-beta source code to be part of the public repository, but I realize that there are probably good reasons that I'm not aware of for it to be private.)

 

Having said that, you could always try compiling against a checkout of the latest code from the public TDM SVN repository:

https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk

That should be reasonably similar to 2.05-beta. Be aware that you will most likely need some of the patches published in the various recent Linux-related threads. And even then, you might "hit a wall". Oh, and when it comes time to actually run your build, you'll also be lacking the runtime "resources" (textures, etc) that are new or changed since 2.04. But I would still encourage you to give it a try. You will find help here if you need it.

 

Another alternative would be to assemble an equivalent of the 2.05-beta code using the public SVN repository, although that's probably ill-advised if you're not already comfortable with SVN.

The source code for the original 2.05 package build was taken at SVN rev. 6684.

 

Subsequent builds included these merges:

 

11/26 - 6690-6694

12/2 - 6698, 6707-6710

12/11 - 6718, 6720

I'd be delighted to see another user, especially one using Fedora (since I haven't heard of anyone using it to compile TDM), join the testing and discussion! All comments and questions are welcome, as far as I'm concerned.

 

One thing that your next post, whenever that may be, should mention is the output of 'gcc --version' and some info about your video hardware, preferably with specifics about the video driver (e.g. version) being used.

 

If you're just looking to run the 2.05-beta without compiling it, then that requires access to a private sub-forum, which also requires TDM admin approval.

 

Hope to hear more from you at some point!

Share this post


Link to post
Share on other sites

sry for the stupid question but how does one obtain the 2.05 beta branch if you wanna take a look at it? I am not so versed in using subversion but would like to try looking at the issue, i am using Fedora 25 so this might give you some more information on yet another development stack.

Evening, drop Taaaki a PM asking for read only access to the SVN..

Share this post


Link to post
Share on other sites

Evening,

 

just send the pm to taaki to get access. Here some info about my hardware and soem additional stuff:

gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

As i said earlier before i am running Fedora 25, 64bit. Hardwarewise, i sport a AMD Athlon X4 640, a AMD Radeon 7850 (1GB memory) and 4 GB RAM. I use the free radeonsi driver and mesa 13.0.2 aswell as Xorg 1.19.0.

 

Yes indeed i intend on compiling the source code for 2.05beta, trying out a couple of the fixes that float around and maybe if i get make some sense out of it, try to come up with some fixes aswell. I have some experience tinkering around with the source code of dhewm3 and rbdoom3bfg.

 

Greetings,

 

damiel

 

EDIT: Forgot something: kernel version is 4.8.14 and libdrm is version 2.4.74

Edited by damiel

Share this post


Link to post
Share on other sites

Whenever 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?

OK

Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

Thanks for the additional info on your hardware.

Yes indeed i intend on compiling the source code for 2.05beta, trying out a couple of the fixes that float around and maybe if i get make some sense out of it, try to come up with some fixes aswell. I have some experience tinkering around with the source code of dhewm3 and rbdoom3bfg.

Excellent! Other than the little bit I've learned in the last 3 weeks, I have no experience with any of the Doom engines, whether original or modified. Looking forward to having you along with us!

Share this post


Link to post
Share on other sites
Don't give the issue any more thought or worry -- kick back, relax, and enjoy your time away. I'll be ready when you get back.

SVN revision: 6735

  • Like 2

Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...