Announcement

Collapse
No announcement yet.

Radeon Driver Picks Up VBOs, OQ Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Radeon Driver Picks Up VBOs, OQ Support

    Radeon Driver Picks Up VBOs, OQ Support

    Phoronix: Radeon Driver Picks Up VBOs, OQ Support

    There are quite a number of changes in store for Mesa 7.6, such as new state trackers for Gallium3D, other Gallium3D-specific improvements, optimized IR, and many changes to the different Mesa 3D drivers. Adding to that list, the open-source ATI R300+ driver has just picked up support for Vertex Buffer Objects and Occlusion Queries. The vbo_clean branch was merged into Mesa over the weekend, which adds hardware-based VBO support for those with newer ATI Radeon graphics cards...

    http://www.phoronix.com/vr.php?view=NzQ1OQ

  • crumja
    replied
    Originally posted by BlackStar View Post
    The ARB is also to blame here
    I agree with you on that count, though I also assign some blame to developers who use vendor-specific extensions instead of just the core ones (or pressuring for them to be made official extensions).

    Leave a comment:


  • Wyatt
    replied
    Originally posted by nanonyme View Post
    Wait, what? -funroll-loops all over again except this time with GPU's? Better tell all Gentoo users.
    Hey man, I resemble that remark! ;D

    Leave a comment:


  • whizse
    replied
    Okay, I guess (I and others who have replied?) come from another perspective. After all, I'm just one guy, I don't have users to worry about fortunately

    Anyway, for me, the Intel drivers have steadily improved with the latest releases, git master of Mesa very much so.

    It's still frightfully easy to cause the GPU to hang, needing to reboot. But tools such as intel_gpu_dump have made it much easier to create good bug reports and the developers are very friendly and responsive.

    Leave a comment:


  • BlackStar
    replied
    Originally posted by crumja View Post
    As whizse said, if you really do see bugs, file a bug report. Which extensions are you using that aren't working properly? Are you absolutely sure it's a regression in the drivers and not a problem in your configuration or application?
    Easier said than done. I do not have access to Intel hardware, so I have to rely on my users for data. Creating test cases is tricky or downright impossible (the user never answers back or you have a hard deadline and all you can do is patch the code and pray for the best.)

    Still, I do report bugs to all major IHVs regularly.

    As for application vs driver errors, if something works on AMD and Nvidia but fails on Intel and glGetError() returns blank, I am inclined to blame the Intel drivers. Especially if the error involves a blue screen or kernel panic.

    The ARB is also to blame here - a comprehensive, mandatory OpenGL conformance test should have been a priority along with OpenGL 3.0. However, they are still the same old inefficient design commitee that botched OpenGL 2.0, 3.0 and every major version in-between (VBOs, GLSL, FBOs, geometry shaders - every major addition to OpenGL has been mismanaged and delayed for ridiculous amounts of time. It's 2009 and EXT_anisotropy still hasn't made it to core, good job!)

    Leave a comment:


  • crumja
    replied
    As whizse said, if you really do see bugs, file a bug report. Which extensions are you using that aren't working properly? Are you absolutely sure it's a regression in the drivers and not a problem in your configuration or application?

    As for beta code, the only beta piece of software I am using is the kernel. Btw, switching back to 2.6.30 works as well. The only time when the Intel driver has broken something for me is the 2.6 series, which was released in order to get features out to certain customers within a deadline. Since then, the devs have worked hard to stabilize the driver.

    Leave a comment:


  • BlackStar
    replied
    Originally posted by crumja View Post
    I call BS. Well, maybe you've not encountered it, but with 2.6.31 kernel, Mesa 7.5, and 2.8.0 Intel xorg driver, I can run games through wine and linux native games (e.g. nwn, ut2004) without any problem. No rendering errors. No random crashes.
    Yeah, tell that to my users: "change your operating system, install a beta kernel and my program will work. Promise!"

    No, wait, it won't. Every single Intel release manages to break *something*, as CME kindly points out. The same holds true on the windows side, too.

    My solution: until Intel creates an OpenGL implementation that actually *works*, down the OpenGL 1.1 path they go (along with S3, Sis and every other shitty implementation out there). Even software rendering tends to work better than those drivers.

    Yes, I sound bitter because I *am* bitter. I've spent more time debugging and working around Intel driver issues than every other vendor *combined*. It doesn't help that their Windows drivers are even worse than their Linux counterparts, either.

    Leave a comment:


  • whizse
    replied
    That's too bad, but have you filed bugs?

    The Intel devs are in general very responsive and regressions are usually not that hard to track down (git bisect).

    Leave a comment:


  • .CME.
    replied
    well, i have kernel 2.6.31, mesa 7.6 and 2.8.0 intel xorg, i get the same crashes in wine (trackmania, GTAVC, odd world domination grafikdemo etc.) as with 2.6.30 + with 2.6.31 the screen is corrupted in 640x480 when using OpenGL, all these games and demos runs fine with 2.6.0, mesa 7.4 and kernel 2.6.28 :\

    Leave a comment:


  • crumja
    replied
    Originally posted by BlackStar View Post
    Let's put it this way: I've yet to encounter a single Intel driver that manages to render anything more complex than "hello world" 3d graphics. Results range from buggy rendering to outright kernel crashes.
    I call BS. Well, maybe you've not encountered it, but with 2.6.31 kernel, Mesa 7.5, and 2.8.0 Intel xorg driver, I can run games through wine and linux native games (e.g. nwn, ut2004) without any problem. No rendering errors. No random crashes.

    Leave a comment:

Working...
X