JOGL - variable performance across systems [RESOLVED]

Hi all, I was quite surprised by this.

System A: displays 13824 polygons in 30 ms

Gateway NV7200 Laptop (windows 7 professional 64-bit) -- this laptop was built over 5 years ago
AMD Turion 2.1Ghz dual core processor
Integrated ATI Radeon 3200HD graphics
4 gb ram

System B: displays 13824 polygons in 400 ms -- 'modern' hardware used (within 2 years)
Custom Build (windows 7 professional 64-bit)
Intel Core i5-3570K quad core 3.4ghz
Intel integrated HD graphics (on ASUS Z77 Sabretooth motherboard)
16 gb ram

I ran the exact same code on both systems with the exact same jogl binaries.

Where would be the starting point for me to debug this?  I'm stumped!

Edited* Also, I should mention that on System B, textures have a thin black line between them, whereas on System A, there are no lines.  Since it's the exact same code that's being used, I don't have any idea where to start debugging this either!

Edited** I just disabled texturing and the performance between systems has somewhat equalized...the same image files are being used on both systems, so I would assume that it's not the images themselves.

Thanks!

From the speeds you are stating for the Core-i5 it could easily be that you are not using the GPU at all, but render everything with the software fallback driver. First I would check if you are using the GPU by doing stg like this:

System.out.println("VENDOR: "+"GL_VENDOR:"+inGL.glGetString(GL_VENDOR)+" GL_RENDERER:"+inGL.glGetString(GL_RENDERER));
System.out.println("GL_VERSION: "+inGL.glGetString(GL_VERSION)+" GLSL_VERSION: "+inGL.glGetString(GL_SHADING_LANGUAGE_VERSION); 

If the vendor is "Microsoft" you are using the software fallback driver.

Hi Luke

You're comparing very different hardwares. Intel chipsets are known for their general "bad" performance and their less reliable OpenGL drivers. Even ATI and Nvidia chipsets for laptops in the same range are faster. Intel chipsets are a nightmare for game programmers, they are used in lots of laptops, we can't ignore them but they are really annoying. When they started supporting vertex arrays, it was so slow that even immediate mode was faster. Nowadays they still have a bad support of FBOs.

You don't indicate which drivers you use. I completely agree with Demoscene Passivist, maybe you use Microsoft GDI driver that emulates OpenGL in software with Direct3D which is quite slow.

Do you use an image whose size is not a power of 2?

Hello, thanks for the tips gouessej and Demoscene Passivist.

It turns out that Microsoft's GDI driver is being used on System B.  I suppose the next step is moving through and optimizing things until I reach a 'good enough' threshold?

The images that I am using are indeed a power of 2.  At any rate, I'd like to figure out why I'm getting the thin black lines on System B whereas no lines on System A (and System C, an Ubuntu box).  Could it be something with the GDI driver itself? (image: http://imageshack.us/a/img600/1660/linespw.png )

Luke wrote

Hello, thanks for the tips gouessej and Demoscene Passivist.

You're welcome.

Luke wrote

It turns out that Microsoft's GDI driver is being used on System B.  I suppose the next step is moving through and optimizing things until I reach a 'good enough' threshold?

I don't know the constraint of your project, it's up to you. Some software editors simply refuse to support Microsoft GDI driver, some editors don't. I show a warning (encouraging people to use a real driver) and I stop running the latest blueprint of my first person shooter when I detect this driver. It's so painful when end users complain about performance whereas it's not (y)our fault. I try to use spatial partitioning and mesh optimizations to improve performance, especially on low end machines.

Luke wrote

The images that I am using are indeed a power of 2.  At any rate, I'd like to figure out why I'm getting the thin black lines on System B whereas no lines on System A (and System C, an Ubuntu box).  Could it be something with the GDI driver itself? (image: http://imageshack.us/a/img600/1660/linespw.png )

Yes, this kind of driver is really crappy. Maybe there is a workaround but I don't see anything obvious now.

Edit. nice viewer :) good job :)

Luke wrote

It turns out that Microsoft's GDI driver is being used on System B.  I suppose the next step is moving through and optimizing things until I reach a 'good enough' threshold?

Usually if I find that I'm running the GDI driver, I go to my computer manufacturer's web site and get the latest version of the "real" driver for my hardware  It might be difficult to get good enough performance with the fallback driver.

Luke wrote

At any rate, I'd like to figure out why I'm getting the thin black lines on System B whereas no lines on System A (and System C, an Ubuntu box).  Could it be something with the GDI driver itself?

Yes, I've noticed similar problems with (for example) rendering OpenGL inside a VMWare box, where it uses a software Mesa driver instead of accessing the graphics hardware directly.

I don't know the constraint of your project, it's up to you.

The end result is going to be targeted at Android, so if all goes well I should be set.

Thanks again everyone.

You can use texture coordinates greater than 1 to draw the same quads several times in your floor. I use an optimizer I have written to detect such cases and modify my mesh. Good luck.