Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Higher speed, no problems

Higher speed, problems

Same speed, no problems

Same speed, problems

Lower speed, no problems

Lower speed, problems

[Vince]

Activated VBO crashes DF for me.
When I deactivate the extension limit in the NVidia driver, DF shows a black screen and does nothing.
Driver Version 186.18,
GeForce 8800M GTS

VBOs work on my laptop, in general (they are used in a current project at the university)

It seems it has to do with some extensions. Maybe they are too old or too new?
Which do you use?

[Footkerchief]

Report of segfaults in Ubuntu Jaunty for 40d16 HEAD, with detailed crash info etc.

[steff]

Ta chap!

FWIW, the same crash hasn't yet occurred in Jaunty 32-bit running in Virtualbox 3.0 on the same machine. It's slow though. So slooooow.

[Baughn]

The backtrace is failing because the stack has already been clobbered by the time gdb catches the crash. For better results, run under valgrind.

The crash appears to be in strcat, but that means relatively little without knowing *which* use of strcat. Please, try valgrind?

Also, there's exactly one use of strcat in the graphics code, in the code for graphical tilesets. Which is not to say that other library code doesn't call it; I'd need a backtrace for that. Still, try turning graphical tiles off, see if it matters? Or tell me if they're already off?

[steff]

Righto, valgrind it is. I can live with teh sl0w, since the alternative is Virtualbox which is currently giving me 2FPS anyway. Graphical tiles aren't installed - this is a brand new untar of the distributed version with nothing added.

[steff]

Left it overnight, since it gets essentially 0 FPS with valgrind running :-)

Select dwarf from 'u' menu, hit v, then Enter. BOOM!

Valgrind output is at http://pastebin.com/fdfda31f

[Vince]

I intercepted the OpenGL errors in VBO mode and found this:

GL ERROR - Function glMapBufferARB generated error GL_OUT_OF_MEMORY
GL ERROR - Function glMapBufferARB generated error GL_OUT_OF_MEMORY
GL ERROR - Function glMapBufferARB generated error GL_OUT_OF_MEMORY
GL ERROR - Function glUnmapBufferARB generated error GL_INVALID_OPERATION
GL ERROR - Function glUnmapBufferARB generated error GL_INVALID_OPERATION
GL ERROR - Function glUnmapBufferARB generated error GL_INVALID_OPERATION

I guess this is the symptom - but what would be the cause?
I have more than enough physical memory I guess - both system RAM (3GB) and graphic RAM (512 MB).

EDIT:
I ran the gDEBugger over it, it came with this:
VBO: http://www.file-upload.net/download-1964791/Context2-OpenGLCallsLog.html.html
STANDARD: http://www.file-upload.net/download-1964792/Context2-OpenGLCallsLog.html.html
It seems it binds textures until the memory is full.
I don't have the code, so I don't exactly know if I am correct at all, but it's my best guess.

EDIT2: the GLError OpenGL Error: glMapBufferARB - GL_OUT_OF_MEMORY occurs three times during three callings of
glMapBufferARB(GL_ARRAY_BUFFER, GL_WRITE_ONLY)
After than the unmap function fails three times, of course.
(EDIT 4: Oh, that's the same I wrote above )
Then it crashes.

[Baughn]

steff: That's a DF bug. Report it on the bug forum, to Toady; preferably so he can replicate it.

Vince:
It wouldn't be the total memory use that's a problem, just the way it's being used. It's odd, though. The game explicitly checks whether those work, and switches from VBO to standard if they don't; if you get those errors, your drivers are lying in a bad way.

What gpu is that?

Anyhow.. glMapBufferARB is meant to map GPU memory directly into the application's address space. It reduces the number of copies required, thus slightly increasing speed. Unfortunately.. well, you saw; it's not too well supported.

[Vince]

Vince:
It wouldn't be the total memory use that's a problem, just the way it's being used. It's odd, though. The game explicitly checks whether those work, and switches from VBO to standard if they don't; if you get those errors, your drivers are lying in a bad way.

Newest NVidia, 186.18

What gpu is that?

GeForce 8800M GTS
I'll try it with my other pc... Let's see...
GeForce 7600 GT crashes, too. The driver is a bit older, by the way (had no chance to check it, it is occupied right now )

Anyhow.. glMapBufferARB is meant to map GPU memory directly into the application's address space. It reduces the number of copies required, thus slightly increasing speed. Unfortunately.. well, you saw; it's not too well supported.

I know, and they can be a pain to implement, too. (I had a dependency hell with those extensions...)

[steff]

steff: That's a DF bug. Report it on the bug forum, to Toady; preferably so he can replicate it.

Duly added to my original bug report thread. Ta!

[droid]

When the adjustable grid was introduced (40d I think), I tweaked it to find the optimal size for my screen. But I haven't found out how to get things the way I want them with the new system.

I would like to use:
[FULLGRID:84:50]
and have as the default
[FULLGRID:0:0]
which would mean autofind the grid like it does in 40d16.

[Footkerchief]

^^^ Set your desired resolution in the 40d16 init.txt, and it'll figure out what grid size to start with (40d16 doesn't have a notion of a set grid size).  You can also expand the window by dragging its corners, like any other window, or you can hit the "Maximize" button in the upper right.

[Wraith]

Newest NVidia, 186.18

Isn't NVidia up to around 191.xx for that card?

[Vince]

Newest NVidia, 186.18

Isn't NVidia up to around 191.xx for that card?

GeForce 8800M GTS is a laptop card.
(And I went through the hassle modifying the inf and installing the 191.xx, but a) it didn't work either and b) the NVidia control panel doesn't install in that case)

[Baughn]

Something funny is going on there.

I've got an 8600GT myself - another laptop card - and if VBOs work here, they should definitely work for you.

Of course, I'm using linux.
What's actually failing is mapping the gpu memory into the application's address space, so maybe it's due to insufficient address space?

In that case, a 64-bit OS (like mine) would never see any problems, while a 32-bit one would be in trouble depending variously on driver specifications and total installed memory - in this case, less memory would be better.

How much memory did you say you have? Could you try pulling one of the chips, see what happens?