Menu
▾
▴
mesa3d-dev
|
From: Török E. <edw...@gm...> - 2010-03-06 14:22:11
|
Hi Andre, I've been using your patch that enables pbo on r600: http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7 Are you considering enabling it in Mesa 7.8? Some games won't even start without pbo support (for example Heroes of Newerth). Even if gameplay isn't perfect (there are some rendering artifacts[1], and some effects are slow [2]) at least the game starts with that patch. [1] which is not related to your pbo patch, I see artifacts w/o it too in other games, and blender: https://bugs.freedesktop.org/show_bug.cgi?id=26735 [2] which can be turned off, like refraction Best regards, --Edwin |
|
From: Corbin S. <mos...@gm...> - 2010-03-06 19:58:38
|
HoN needs PBOs? How annoying. I'll pull in the patch if nobody else says anything, but I'd much prefer that Alex or somebody else more familiar with r600 do it. ~ C. 2010/3/6 Török Edwin <edw...@gm...>: > Hi Andre, > > I've been using your patch that enables pbo on r600: > http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7 > > Are you considering enabling it in Mesa 7.8? > > Some games won't even start without pbo support (for example Heroes of > Newerth). > > Even if gameplay isn't perfect (there are some rendering artifacts[1], > and some effects are slow [2]) at least the game starts with that patch. > > [1] which is not related to your pbo patch, I see artifacts w/o it too > in other games, and blender: > https://bugs.freedesktop.org/show_bug.cgi?id=26735 > [2] which can be turned off, like refraction > > Best regards, > --Edwin > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mesa3d-dev mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <Mos...@gm...> |
|
From: Török E. <edw...@gm...> - 2010-03-06 21:24:04
|
On 2010-03-06 21:58, Corbin Simpson wrote: > HoN needs PBOs? How annoying. It needs these: 64MB OpenGL 1.2 / GLSL 1.10 compliant video card with the following extensions present: ARB_multitexture, ARB_vertex_buffer_object, ARB_shader_objects, ARB_fragment_shader, ARB_vertex_shader, ARB_shading_language_100, ARB_pixel_buffer_object, EXT_framebuffer_object > > I'll pull in the patch if nobody else says anything, but I'd much > prefer that Alex or somebody else more familiar with r600 do it. Thanks! Best regards, --Edwin |
|
From: Alex D. <ale...@gm...> - 2010-03-06 21:42:18
|
2010/3/6 Corbin Simpson <mos...@gm...>: > HoN needs PBOs? How annoying. > > I'll pull in the patch if nobody else says anything, but I'd much > prefer that Alex or somebody else more familiar with r600 do it. > Is that patch all that's needed for pbos? I was under the impression there was more work involved, but I haven't really had a chance to look into it further. Alex > ~ C. > > 2010/3/6 Török Edwin <edw...@gm...>: >> Hi Andre, >> >> I've been using your patch that enables pbo on r600: >> http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7 >> >> Are you considering enabling it in Mesa 7.8? >> >> Some games won't even start without pbo support (for example Heroes of >> Newerth). >> >> Even if gameplay isn't perfect (there are some rendering artifacts[1], >> and some effects are slow [2]) at least the game starts with that patch. >> >> [1] which is not related to your pbo patch, I see artifacts w/o it too >> in other games, and blender: >> https://bugs.freedesktop.org/show_bug.cgi?id=26735 >> [2] which can be turned off, like refraction >> >> Best regards, >> --Edwin >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Mesa3d-dev mailing list >> Mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev >> > > > > -- > Only fools are easily impressed by what is only > barely beyond their reach. ~ Unknown > > Corbin Simpson > <Mos...@gm...> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mesa3d-dev mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > |
|
From: Török E. <edw...@gm...> - 2010-03-06 22:40:54
|
On 2010-03-06 23:42, Alex Deucher wrote: > 2010/3/6 Corbin Simpson <mos...@gm...>: >> HoN needs PBOs? How annoying. >> >> I'll pull in the patch if nobody else says anything, but I'd much >> prefer that Alex or somebody else more familiar with r600 do it. >> > > Is that patch all that's needed for pbos? I was under the impression > there was more work involved, but I haven't really had a chance to > look into it further. Mesa 7.8 branch from git + that patch makes the game start [1] w/o that patch it dies saying it needs pbo. I don't know if pbo is HW accelerated or not (it probably isn't), but it is "good enough" for this game if I turn refractions off. orm=pbuffer doesn't work in wine though (black screen) (orm=fbo either, only orm=backbuffer), but it can't work without this patch either. [1] just confirmed that it works with 7.8 too, not just master. After remembering to remove libtxc_dxtn.so, which I installed for testing. (libtxc_dxtn doesn't work: unsupported texture format in setup_hardware_state failed to validate texture for unit 0). Best regards, --Edwin |
|
From: Ian R. <id...@fr...> - 2010-03-06 23:00:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Török Edwin wrote: > Hi Andre, > > I've been using your patch that enables pbo on r600: > http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7 > > Are you considering enabling it in Mesa 7.8? At this point the 7.8 branch is open for bug fixes *only*. The announcement that the 7.8 branch would be created on March 5th went out on February 23th, and the release plan was discussed quite a few times before that. That was plenty of time to nominate patches for inclusion. It's probably okay to just enable ARB_pixel_buffer_object, but I'd be a bit nervous about the rest. OpenGL 2.1 is more than just PBOs and GLSL 1.20. Do the piglit and glean PBO tests pass on r600 with this patch? > Some games won't even start without pbo support (for example Heroes of > Newerth). > > Even if gameplay isn't perfect (there are some rendering artifacts[1], > and some effects are slow [2]) at least the game starts with that patch. > > [1] which is not related to your pbo patch, I see artifacts w/o it too > in other games, and blender: > https://bugs.freedesktop.org/show_bug.cgi?id=26735 > [2] which can be turned off, like refraction -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuS3nMACgkQX1gOwKyEAw/jjQCcCT12MRnmcyzXT9T/KtxTPzA/ j6YAn00kNPUt/gFAwbfY+cBFojGj/oEk =3PRS -----END PGP SIGNATURE----- |
|
From: Török E. <edw...@gm...> - 2010-03-07 11:07:38
|
On 03/07/2010 01:00 AM, Ian Romanick wrote: > Török Edwin wrote: >> Hi Andre, > >> I've been using your patch that enables pbo on r600: >> http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7 > >> Are you considering enabling it in Mesa 7.8? > > At this point the 7.8 branch is open for bug fixes *only*. The > announcement that the 7.8 branch would be created on March 5th went out > on February 23th, and the release plan was discussed quite a few times > before that. That was plenty of time to nominate patches for inclusion. > > It's probably okay to just enable ARB_pixel_buffer_object, but I'd be a > bit nervous about the rest. OpenGL 2.1 is more than just PBOs and GLSL > 1.20. Do the piglit and glean PBO tests pass on r600 with this patch? I've run the piglit tests using tests/r500.tests, with glean in quick mode. With patch: 620/686 pass Without patch: 614/679 pass (I opened a bugreport about these failures here: https://bugs.freedesktop.org/show_bug.cgi?id=26933) The pbo tests results are: glean/pbo: fail general/pbo-teximage-tiling: pass general/pbo-read-argb8888: pass general/pbo-teximage-tiling-2: pass general/pbo-drawpixels: pass general/pbo-readpixels-small: pass general/object_purgeable-api-pbo: skip general/pbo-teximage: pass fbo/fbo-pbo-readpixels-small: pass The glean/fbo fail looks like some FP tolerance being too strict (1.0 vs 1.00000). Is there a way to accept 1.00000 for 1.0 in the piglit tests? pbo test: Test OpenGL Extension GL_ARB_pixel_buffer_object FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028) (1, 0) = [1.000000, 1.000000, 1.000000], should be [1.0, 1.0, 1.0] pbo: NOTE perf[0] = 372.891 MB/s, which is in normal mode pbo: NOTE perf[1] = 261.088 MB/s, which is using PBO pbo: FAIL rgba8, db, z24, s8, win+pmap, id 33 9 tests passed, 1 tests failed. I've also run piglit w/o the patch applied, the pbo test were the only ones that changed to skip (except for glean/pbo which was pass due to extension not present). So the rest of the piglit tests are unaffected by this patch (they pass/fail the same way). > >> Some games won't even start without pbo support (for example Heroes of >> Newerth). > >> Even if gameplay isn't perfect (there are some rendering artifacts[1], >> and some effects are slow [2]) at least the game starts with that patch. > >> [1] which is not related to your pbo patch, I see artifacts w/o it too >> in other games, and blender: >> https://bugs.freedesktop.org/show_bug.cgi?id=26735 >> [2] which can be turned off, like refraction Best regards, --Edwin |
|
From: Ian R. <id...@fr...> - 2010-03-07 22:12:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Török Edwin wrote: > I've run the piglit tests using tests/r500.tests, with glean in quick mode. > > With patch: 620/686 pass > Without patch: 614/679 pass (I opened a bugreport about these failures > here: https://bugs.freedesktop.org/show_bug.cgi?id=26933) > > The pbo tests results are: > glean/pbo: fail > general/pbo-teximage-tiling: pass > general/pbo-read-argb8888: pass > general/pbo-teximage-tiling-2: pass > general/pbo-drawpixels: pass > general/pbo-readpixels-small: pass > general/object_purgeable-api-pbo: skip > general/pbo-teximage: pass > fbo/fbo-pbo-readpixels-small: pass Okay. I'm convinced. I'll leave it up to the r600 maintainers to make the final call. However, they really need to do it before RC1 (March 12th). > The glean/fbo fail looks like some FP tolerance being too strict (1.0 vs > 1.00000). Is there a way to accept 1.00000 for 1.0 in the piglit tests? > > pbo test: Test OpenGL Extension GL_ARB_pixel_buffer_object > > FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028) > (1, 0) = [1.000000, 1.000000, 1.000000], should be [1.0, 1.0, 1.0] > pbo: NOTE perf[0] = 372.891 MB/s, which is in normal mode > pbo: NOTE perf[1] = 261.088 MB/s, which is using PBO > pbo: FAIL rgba8, db, z24, s8, win+pmap, id 33 > 9 tests passed, 1 tests failed. That's pretty weird. I was pretty sure that glean checked for equality by making sure the difference was below some threshold. As far as I can tell, fabs(1.000000 - 1.0) should be below any reasonable threshold. There's clearly something else going wrong. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuUJLYACgkQX1gOwKyEAw/MPQCfZ8b/sSBRR8yN8z9u6tQrlY7J +4sAnRKvgpboQ8D3ObcNwW5lEUKudPPv =5D6f -----END PGP SIGNATURE----- |
|
From: Török E. <edw...@gm...> - 2010-03-08 09:05:25
|
[Patch for piglit/tests/glean/tpbo.cpp attached] On 03/08/2010 12:12 AM, Ian Romanick wrote: > Török Edwin wrote: > >> I've run the piglit tests using tests/r500.tests, with glean in quick mode. > >> With patch: 620/686 pass >> Without patch: 614/679 pass (I opened a bugreport about these failures >> here: https://bugs.freedesktop.org/show_bug.cgi?id=26933) > >> The pbo tests results are: >> glean/pbo: fail >> general/pbo-teximage-tiling: pass >> general/pbo-read-argb8888: pass >> general/pbo-teximage-tiling-2: pass >> general/pbo-drawpixels: pass >> general/pbo-readpixels-small: pass >> general/object_purgeable-api-pbo: skip >> general/pbo-teximage: pass >> fbo/fbo-pbo-readpixels-small: pass > > Okay. I'm convinced. I'll leave it up to the r600 maintainers to make > the final call. However, they really need to do it before RC1 (March 12th). Thanks! > >> The glean/fbo fail looks like some FP tolerance being too strict (1.0 vs >> 1.00000). Is there a way to accept 1.00000 for 1.0 in the piglit tests? > >> pbo test: Test OpenGL Extension GL_ARB_pixel_buffer_object > >> FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028) >> (1, 0) = [1.000000, 1.000000, 1.000000], should be [1.0, 1.0, 1.0] >> pbo: NOTE perf[0] = 372.891 MB/s, which is in normal mode >> pbo: NOTE perf[1] = 261.088 MB/s, which is using PBO >> pbo: FAIL rgba8, db, z24, s8, win+pmap, id 33 >> 9 tests passed, 1 tests failed. > > That's pretty weird. I was pretty sure that glean checked for equality > by making sure the difference was below some threshold. As far as I can > tell, fabs(1.000000 - 1.0) should be below any reasonable threshold. > There's clearly something else going wrong. Yeah, I looked at the code: it is checking one thing and reporting another :) exp is black/white alternatively for every 2nd iteration: if (i & 1) exp = black; else exp = white; if (i < 10 && j < 10) { if (!equalColors(&buf[(j * windowSize + i) * 3], exp)) { REPORT_FAILURE("glGetPolygonStipple failed"); printf("(%d, %d) = [%f, %f, %f], ", i, j, buf[(j * windowSize + i) * 3], buf[(j * windowSize + i) * 3 + 1], buf[(j * windowSize + i) * 3 + 2]); printf("should be [1.0, 1.0, 1.0]\n"); ^However the message reports 1.0 always. Attached patch fixes error reporting in piglit, and then I get this message: FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028) (1, 0) = [1.000000, 1.000000, 1.000000], should be [0.000000, 0.000000, 0.000000] pbo: NOTE perf[0] = 372.431 MB/s, which is in normal mode pbo: NOTE perf[1] = 262.693 MB/s, which is using PBO pbo: FAIL rgba8, db, z24, s8, win+pmap, id 33 9 tests passed, 1 tests failed. Best regards, --Edwin |
|
From: Alex D. <ale...@gm...> - 2010-03-08 17:02:22
|
2010/3/7 Ian Romanick <id...@fr...>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Török Edwin wrote: > >> I've run the piglit tests using tests/r500.tests, with glean in quick mode. >> >> With patch: 620/686 pass >> Without patch: 614/679 pass (I opened a bugreport about these failures >> here: https://bugs.freedesktop.org/show_bug.cgi?id=26933) >> >> The pbo tests results are: >> glean/pbo: fail >> general/pbo-teximage-tiling: pass >> general/pbo-read-argb8888: pass >> general/pbo-teximage-tiling-2: pass >> general/pbo-drawpixels: pass >> general/pbo-readpixels-small: pass >> general/object_purgeable-api-pbo: skip >> general/pbo-teximage: pass >> fbo/fbo-pbo-readpixels-small: pass > > Okay. I'm convinced. I'll leave it up to the r600 maintainers to make > the final call. However, they really need to do it before RC1 (March 12th). > Ok, I've gone ahead and enabled the extension in the 7.8 branch. Alex >> The glean/fbo fail looks like some FP tolerance being too strict (1.0 vs >> 1.00000). Is there a way to accept 1.00000 for 1.0 in the piglit tests? >> >> pbo test: Test OpenGL Extension GL_ARB_pixel_buffer_object >> >> FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028) >> (1, 0) = [1.000000, 1.000000, 1.000000], should be [1.0, 1.0, 1.0] >> pbo: NOTE perf[0] = 372.891 MB/s, which is in normal mode >> pbo: NOTE perf[1] = 261.088 MB/s, which is using PBO >> pbo: FAIL rgba8, db, z24, s8, win+pmap, id 33 >> 9 tests passed, 1 tests failed. > > That's pretty weird. I was pretty sure that glean checked for equality > by making sure the difference was below some threshold. As far as I can > tell, fabs(1.000000 - 1.0) should be below any reasonable threshold. > There's clearly something else going wrong. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkuUJLYACgkQX1gOwKyEAw/MPQCfZ8b/sSBRR8yN8z9u6tQrlY7J > +4sAnRKvgpboQ8D3ObcNwW5lEUKudPPv > =5D6f > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mesa3d-dev mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > |
|
From: Corbin S. <mos...@gm...> - 2010-03-07 22:30:39
|
2010/3/8 Ian Romanick <id...@fr...>: > Okay. I'm convinced. I'll leave it up to the r600 maintainers to make > the final call. However, they really need to do it before RC1 (March 12th). Thread hijack! Are docs changes okay? I'd like to note that r300g works for the simpler things in life, that bugs may be filed against it, and that it's been taken off the all-kitten diet. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <Mos...@gm...> |
|
From: Ian R. <id...@fr...> - 2010-03-07 22:50:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Corbin Simpson wrote: > 2010/3/8 Ian Romanick <id...@fr...>: >> Okay. I'm convinced. I'll leave it up to the r600 maintainers to make >> the final call. However, they really need to do it before RC1 (March 12th). > > Thread hijack! Are docs changes okay? I'd like to note that r300g As long as they don't cause regressions. ;) > works for the simpler things in life, that bugs may be filed against > it, and that it's been taken off the all-kitten diet. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuULXkACgkQX1gOwKyEAw/eNwCeMWtmKVFrsP3Xszv7lQ2qsfDB y4EAniZo3oVtGOOmoeU686yzCrnRYDZi =dtmN -----END PGP SIGNATURE----- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X