Re: [Mesa-dev] leak of gem_objects on intel i965
Hello Stéphane, your are right, I forgot to attach, here it is... Andreas Von: marc...@google.com [mailto:marc...@google.com] Im Auftrag von Stéphane Marchesin Gesendet: Donnerstag, 16. Juni 2011 10:52 An: Lampersperger Andreas Cc: mesa-dev@lists.freedesktop.org Betreff: Re: [Mesa-dev] leak of gem_objects on intel i965 On Thu, Jun 16, 2011 at 00:10, Lampersperger Andreas lampersperger.andr...@heidenhain.demailto:lampersperger.andr...@heidenhain.de wrote: Hello Stéphane, I've tried your patch (I adopted it to 7.10.3, see attached patch), but it results in a SEGFAULT: Hmm right I'm working against mesa git. That said, I don't see an attached patch :) Stéphane /PREp -- br Registergericht: Traunstein / Registry Court: HRB 275 - Sitz / Head Office: Traunreut br Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard br Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman),br Michael Grimm, Matthias Fauser, Sebastian Tondorfbrbr a href=http://www.heidenhain.de/disclaimer; target=_blankE-Mail Haftungsausschluss / E-Mail Disclaimer/abrpre mesa_7.3-implement-glx-refcounting_1.patch Description: mesa_7.3-implement-glx-refcounting_1.patch ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL-TGSI translator
On Thu, Jun 16, 2011 at 10:08 AM, Brian Paul bri...@vmware.com wrote: On 06/15/2011 03:38 PM, Bryan Cain wrote: My work on the GLSL IR to TGSI translator I announced on the list this April is now at the point where I think it is ready to be merged into Mesa. It is stable and doesn't regress any piglit tests on softpipe or nv50. It adds native integer support as required by GLSL 1.30, although it is currently disabled for all drivers since GLSL 1.30 support is not complete yet and most Gallium drivers haven't implemented the TGSI integer opcodes. (This would be a good time for Gallium driver developers to add support for TGSI's integer opcodes, which are currently only implemented in softpipe.) Developing this necessitated significant changes elsewhere in Mesa, and some small changes in Gallium. This means that some of the commits in my branch probably need to be reviewed by the developers of those components. If I had commit access to Mesa, I would create a branch for this work in the main Mesa repository. But since I am still waiting on my freedesktop.org account to be created, I have pushed the latest version to the glsl-to-tgsi branch of my personal Mesa repository on GitHub: Git clone URL: git://github.com/Plombo/mesa.git Web interface for viewing commits: https://github.com/Plombo/mesa/commits/glsl-to-tgsi Hopefully my freedesktop.org account will be created soon (I have already had my account request approved), so that I can push this to a branch in the central repository. Looks like nice work, Bryan. Just a few minor questions/comments for now: 1. The st_fragment/vertex/geometry_program structs now have a glsl_to_tgsi field. I did a grep, but I couldn't find where that field is assigned. Can you clue me in? 2. The above mentioned program structs contains an old Mesa instruction program AND/OR(?) a GLSL IR. Do both types of representations co-exist sometimes? Perhaps you could update the comments on those structs to explain that. 3. Kind of a follow-on: for glDrawPixels and glBitmap we take the original program code (in Mesa form) and prepend extra instructions for fetching the fragment color or doing the fragment kill. Do we always have the Mesa instructions for this? It seems we don't normally want to generate Mesa instructions all the time but we still need them sometimes. I must be missing something but why do we need to take the original program for those ? Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL-TGSI translator
On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul bri...@vmware.com wrote: Looks like nice work, Bryan. Just a few minor questions/comments for now: 1. The st_fragment/vertex/geometry_program structs now have a glsl_to_tgsi field. I did a grep, but I couldn't find where that field is assigned. Can you clue me in? It's assigned at the end of the get_mesa_program function in st_glsl_to_tgsi.cpp. 2. The above mentioned program structs contains an old Mesa instruction program AND/OR(?) a GLSL IR. Do both types of representations co-exist sometimes? Perhaps you could update the comments on those structs to explain that. They used to co-exist, because after my first commit, st_glsl_to_tgsi still generated Mesa IR in addition to TGSI. But I removed the Mesa IR generation in st/mesa: stop generating Mesa IR in st_glsl_to_tgsi, so now it has either one or the other - glsl_to_tgsi_visitor for GLSL shaders, Mesa IR programs for everything else. 3. Kind of a follow-on: for glDrawPixels and glBitmap we take the original program code (in Mesa form) and prepend extra instructions for fetching the fragment color or doing the fragment kill. Do we always have the Mesa instructions for this? It seems we don't normally want to generate Mesa instructions all the time but we still need them sometimes. No, I didn't realize Mesa did that, and we don't have the Mesa instructions for GLSL programs anymore. I'm not sure what the right way to handle that is. 4. At least one commit message is slightly mis-named: changes to the gallium/util/tgsi/ files were labeled as softpipe. Not a big deal, but maybe be more careful about that. I thought only softpipe used tgsi_exec, but I'll keep in mind to be more careful in the future. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 37476] [wine] Devil May Cry 4: TXD tgsi opcode unsupported / translation from TGSI failed / missing vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=37476 --- Comment #7 from Sven Arvidsson s...@whiz.se 2011-06-16 10:24:11 PDT --- FWIW the shader issues was resolved with an upgrade to the latest version of Wine. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] mesa: Add field gl_renderbuffer.Unwrapped
On 06/16/2011 08:01 AM, Alex Deucher wrote: On Wed, Jun 15, 2011 at 9:09 PM, Chad Versace c...@chad-versace.us wrote: If a renderbuffer wraps multiple renderbuffers, then Unwrapped points to the them. For example, if hardware requires separate depth and stencil buffers (X8_Z24 and S8), then glRenderbufferStorage(GL_DEPTH24_STENCIL8) may create a fake S8_Z24 renderbuffer for which Unwrapped[BUFFER_DEPTH] and Unwrapped[BUFFER_STENCIL] point to the real X8_Z24 and S8 renderbuffers. FWIW, evergreen and newer chips only support separate stencil and depth, so we had a similar issue. We ended up using GL_ARB_shader_stencil_export to implement writes to the stencil. Start of the thread: http://lists.freedesktop.org/archives/mesa-dev/2010-September/003318.html Alex The thread mentions some strange behaviour on r600: so on r600g, the only way to directly write to the stencil is via the shader, using a transfer would require an extra step to flush the DS buffer I've observed mysterious behaviour when writing to intel's stencil buffer through a memory mapped pointer. It's seems that the hardware fails to recognize that the writes ever occurred. (Writes via rendering work fine). I still need to investigate the problem further, but perhaps GL_ARB_shader_stencil_export is what the intel driver needs to work around this problem. Thanks for pointing this out. -- Chad Versace c...@chad-versace.us ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] leak of gem_objects on intel i965
On Thu, Jun 16, 2011 at 02:05, Lampersperger Andreas lampersperger.andr...@heidenhain.de wrote: Hello Stéphane, ** ** your are right, I forgot to attach, here it is... ** Erm, you miss half the patch in there... Can you try with my patch on git mesa instead? Stéphane ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL-TGSI translator
On 06/16/2011 10:34 AM, Bryan Cain wrote: On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul bri...@vmware.com mailto:bri...@vmware.com wrote: Looks like nice work, Bryan. Just a few minor questions/comments for now: 1. The st_fragment/vertex/geometry_program structs now have a glsl_to_tgsi field. I did a grep, but I couldn't find where that field is assigned. Can you clue me in? It's assigned at the end of the get_mesa_program function in st_glsl_to_tgsi.cpp. Thanks. I was using grep glsl_to_tgsi *.[ch] Duh. 2. The above mentioned program structs contains an old Mesa instruction program AND/OR(?) a GLSL IR. Do both types of representations co-exist sometimes? Perhaps you could update the comments on those structs to explain that. They used to co-exist, because after my first commit, st_glsl_to_tgsi still generated Mesa IR in addition to TGSI. But I removed the Mesa IR generation in st/mesa: stop generating Mesa IR in st_glsl_to_tgsi, so now it has either one or the other - glsl_to_tgsi_visitor for GLSL shaders, Mesa IR programs for everything else. OK, can you update the comments with this info? 3. Kind of a follow-on: for glDrawPixels and glBitmap we take the original program code (in Mesa form) and prepend extra instructions for fetching the fragment color or doing the fragment kill. Do we always have the Mesa instructions for this? It seems we don't normally want to generate Mesa instructions all the time but we still need them sometimes. No, I didn't realize Mesa did that, and we don't have the Mesa instructions for GLSL programs anymore. I'm not sure what the right way to handle that is. How hard would it be to edit the IR to insert the extra operations? For glBitmaps it's basically sample a texture and then do a conditional fragment kill. For glDrawPixels we need to sample the texture representing the image, then apply the pixel transfer ops (scale/bias, table lookup, etc). We generate the code for that in st_atom_pixeltransfer.c. That program is then concatenated with the current fragment program with _mesa_combine_program(). If we ever propogate GLSL IR through the gallium interface there's lots of places where we'll need to do other kinds of IR editing. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/gen5, 6: Fix hang when emitting hiz buffer without stencil buffer
On Wed, 15 Jun 2011 00:13:51 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
On 06/14/2011 03:28 PM, Chad Versace wrote:
[snip]
@@ -355,26 +355,48 @@ static void emit_depthbuffer(struct brw_context *brw)
ADVANCE_BATCH();
}
- /* Emit hiz buffer. */
if (hiz_region || stencil_irb) {
- BEGIN_BATCH(3);
- OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER 16) | (3 - 2));
- OUT_BATCH(hiz_region-pitch * hiz_region-cpp - 1);
- OUT_RELOC(hiz_region-buffer,
- I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
- 0);
- ADVANCE_BATCH();
- }
+ /*
+ * In the 3DSTATE_DEPTH_BUFFER batch emitted above, the 'separate
+ * stencil enable' and 'hiz enable' bits were set. Therefore we must
+ * emit 3DSTATE_HIER_DEPTH_BUFFER and 3DSTATE_STENCIL_BUFFER. Even if
+ * there is no stencil buffer, 3DSTATE_STENCIL_BUFFER must be
emitted;
+ * failure to do so causes hangs on gen5.
+ */
Extra indentation here?
Nope. The comment only applies if the if-branch is taken, so I placed
the comment in the if-branch.
Otherwise, yes, please :)
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
[snip]
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.10.3 release
On Tue, 14 Jun 2011 13:09:50 +0200, Andreas Radke a.ra...@arcor.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can you please confirm the tarballs. gzip and bzip2 tarballs won't extract here throwing errors until you give tar -f parameter. I can't build packages because our packaging system uses simple bsdtar without further options. tar -tvf ~/arch64/sources/MesaLib-7.10.2.tar.gz | grep ^h shows nothing for the working older releases but many broken links in the new archives. [andyrtr@workstation64 foo]$ LANG=C tar -tvf ~/arch64/sources/MesaLib-7.10.3.tar.gz | grep ^h No errors for me. The following produces no errors. $ # Fetch and unzip bz2 $ wget ftp://freedesktop.org/pub/mesa/7.10.3/MesaLib-7.10.3.tar.bz2 $ tar xvf MesaLib-7.10.3.tar.bz2 $ # Fetch and unzip gz $ wget ftp://freedesktop.org/pub/mesa/7.10.3/MesaLib-7.10.3.tar.gz $ tar xvf MesaLib-7.10.3.tar.gz - Chad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL-TGSI translator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2011 06:45 PM, Tom Stellard wrote: On Wed, Jun 15, 2011 at 04:38:07PM -0500, Bryan Cain wrote: My work on the GLSL IR to TGSI translator I announced on the list this April is now at the point where I think it is ready to be merged into Mesa. It is stable and doesn't regress any piglit tests on softpipe or nv50. Hi, First of all, nice work on this. It's great to have one less IR to deal with. Just two comments: 1. This branch causes a few piglit regressions on R300 because there is no optimization pass equivalent to _mesa_simplify_cmp() in st_glsl_to_tgsi(I guess technically it's not really an optimization pass, since R300 needs it to function). Would you be able to add something similar in st_glsl_to_tgsi? It should be really easy. You can ping me on irc (tstellar) if you have any questions about it. I'm working on some code that will fix this the right way. It probably won't land until after the 7.11 branch. It's an optimization pass on the GLSL IR that makes unconditional assignments out of conditional assignments to variables with no reaching definition. There's some ugly code in my ud-chains branch. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk36T6AACgkQX1gOwKyEAw8rkgCfcBd5iuGGx5BZmkAOIrNp4kAG jpsAn0578akiXTB5gsViWutQxEPElvpi =LrQK -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.10.3 release
On 06/14/2011 12:22 PM, Chad Versace wrote: On Tue, 14 Jun 2011 13:09:50 +0200, Andreas Radkea.ra...@arcor.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can you please confirm the tarballs. gzip and bzip2 tarballs won't extract here throwing errors until you give tar -f parameter. I can't build packages because our packaging system uses simple bsdtar without further options. tar -tvf ~/arch64/sources/MesaLib-7.10.2.tar.gz | grep ^h shows nothing for the working older releases but many broken links in the new archives. [andyrtr@workstation64 foo]$ LANG=C tar -tvf ~/arch64/sources/MesaLib-7.10.3.tar.gz | grep ^h No errors for me. The following produces no errors. $ # Fetch and unzip bz2 $ wget ftp://freedesktop.org/pub/mesa/7.10.3/MesaLib-7.10.3.tar.bz2 $ tar xvf MesaLib-7.10.3.tar.bz2 $ # Fetch and unzip gz $ wget ftp://freedesktop.org/pub/mesa/7.10.3/MesaLib-7.10.3.tar.gz $ tar xvf MesaLib-7.10.3.tar.gz - Chad Chad, you're using GNU tar. Andreas is using BSD tar. --Kenneth ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31294] libGlw.so is missing glw(M)DrawingAreaWidgetClass and simlilar although configured with --enable-motif --enable-glw
https://bugs.freedesktop.org/show_bug.cgi?id=31294 --- Comment #1 from DJ Cozatt olbran...@gmail.com 2011-06-16 15:41:07 PDT --- Created an attachment (id=48065) View: https://bugs.freedesktop.org/attachment.cgi?id=48065 Review: https://bugs.freedesktop.org/review?bug=31294attachment=48065 patch from linked bug -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31294] libGlw.so is missing glw(M)DrawingAreaWidgetClass and simlilar although configured with --enable-motif --enable-glw
https://bugs.freedesktop.org/show_bug.cgi?id=31294 DJ Cozatt olbran...@gmail.com changed: What|Removed |Added URL||http://bugs.gentoo.org/show ||_bug.cgi?id=335169 --- Comment #2 from DJ Cozatt olbran...@gmail.com 2011-06-16 15:41:50 PDT --- Add GLAPI to the two functions in question (499 bytes, patch) 2011-06-02 11:56 UTC, Gert Wollny -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31294] libGlw.so is missing glw(M)DrawingAreaWidgetClass and simlilar although configured with --enable-motif --enable-glw
https://bugs.freedesktop.org/show_bug.cgi?id=31294 Dan Nicholson dbn.li...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|mesa-dev@lists.freedesktop. |dbn.li...@gmail.com |org | Attachment #48065|0 |1 is obsolete|| --- Comment #3 from Dan Nicholson dbn.li...@gmail.com 2011-06-16 16:39:47 PDT --- Created an attachment (id=48070) View: https://bugs.freedesktop.org/attachment.cgi?id=48070 Review: https://bugs.freedesktop.org/review?bug=31294attachment=48070 glw: Mark all extern symbols GLAPI to regain default visibility (#31294) I think this is the more complete patch that fixes both the Motif and non-Motif cases for GLw. Can you test it out? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
