Re: Stage-3.2.2: Preliminary bug fix for Intel graphics cards (DRM / DRI on i915 / 965GM)

Nice job tracking down the problem, Nikhil. A quick looksee suggests
that OpenGL is expecting practical limits on displaylist size

http://stackoverflow.com/questions/543168/limit-of-opengl-displaylist-size

but the limit on number of displaylists may be high enough for most
purposes (2**32 handles available)

http://www.opengl.org/resources/faq/technical/displaylist.htm

The "best" solution could be to compile a small a set of displaylists
per blocklist, maybe dividing the blocks in two until the local
displaylist size is not exceeded. Nikhil's solution, i.e. having
potentially many thousands of displaylists, might be slower depending
on implementation. Nikhil, can you see a slowdown drawing large maps?
If performance is OK, I'd accept a patch to go with Nikhil's approach,
since it's likely to work with more systems. Intel i965 is very
common!

best,
rtv


On Tue, Oct 19, 2010 at 12:47 AM, Nikhil Karnad <[email protected]> wrote:
> Hi all,
>
> First off, for non-Intel-graphics-card users and non-Stage-developers, this
> post might not be useful.
>
> I got a problem where Stage-3.2.2 was aborting when trying to render the 3D
> structures of the map (bitmap "insert_image_filename_here.pgm") file with a
> long backtrace ending up with the Intel i965 DRM/DRI driver's internal
> functions on Ubuntu 10.04.
>
> The quick fix on the forums was to turn DRI to "off" in xorg.conf. However,
> since I need to run 3D rendering simultaneously (e.g., rviz in ROS), I need
> direct rendering to be activated. To reproduce the error, run Stage-3.2.2 on
> an Intel 965GM chipset and load any map which will generate a lot of
> polygons, e.g. 10,000 separated "wall" pixels in a PGM file. Mine crashed
> for as low as 120 "blocks".
>
> After debugging and digging around (including compiling the latest DRM and
> Mesa drivers), it looks like the i965 DRI/DRM implementation does not handle
> large display lists well and throws a SIGABRT when trying to
> copy/move/reallocate vertex buffers.
>
> To remedy this on my local copy of Stage-3.2.2, I changed the code in
> blocks.cc and blockgroup.cc to have one 'displaylist' per block and have the
> blockgroup 'displaylist' call the containing ones hierarchically. This makes
> the error go away for the map I have (tested with up to 10,000 blocks), but
> I have not tested it for larger maps. I thought this might help others who
> have had the same problem with Intel chipsets and relatively large maps.
>
> I cc'ed the developers list since I'm open to discussion and I would be glad
> to help out.
>
> Best,
> Nikhil
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Playerstage-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>
>



-- 
Richard Vaughan
Autonomy Lab / Computing Science / Simon Fraser University

------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev