Re: [Mesa-dev] leak of gem_objects on intel i965
Hello Kenneth, > On 06/16/2011 12:10 AM, Lampersperger Andreas 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: > > > > Thread [1] 12367 (Suspended : Signal : SIGSEGV:Segmentation fault) > > > > st_visual_to_context_mode() at st_manager.c:309 > 0xb6ea7be0 > > > > st_framebuffer_create() at st_manager.c:441 > 0xb6ea8352 > > > > st_api_make_current() at st_manager.c:732 0xb6ea8456 > > ^^^ This is Gallium code. The official Intel drivers do not use > Gallium. Are you trying to use the unsupported i965g driver? > No, I'm just using http://www.x.org/releases/individual/driver/xf86-video-intel-2.15.0.tar.bz2 Did I made some mistakes with configuring packages? -Andreas > > dri_make_current() at dri_context.c:194 0xb6e4662f > > driBindContext() at dri_util.c:196 0xb6e425a9 > > dri2_bind_context() at dri2_glx.c:151 0xb7480d10 > > MakeContextCurrent() at glxcurrent.c:263 0xb7459b2d > > glXMakeCurrent() at glxcurrent.c:287 0xb7459c43 > > gdk_gl_window_impl_x11_make_context_current() at > > gdkglwindow-x11.c:250 0xb7fc583e > > gdk_gl_drawable_gl_begin() at gdkgldrawable.c:143 > > 0xb7fa384d > > configure_event() at simple.c:81 0x8049982 > > > > ... > > > > In st_framebuffer_create() stfbi->visual was not initialized. > > > > Do I have to apply other patches to 7.10.3? > > > > -Andreas --- Registergericht: Traunstein / Registry Court: HRB 275 – Sitz / Head Office: Traunreut Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman), Michael Grimm, Matthias Fauser, Sebastian Tondorf E-Mail Haftungsausschluss / E-Mail Disclaimer: http://www.heidenhain.de/disclaimer ___ 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 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 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=31294&attachment=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
[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 changed: What|Removed |Added URL||http://bugs.gentoo.org/show ||_bug.cgi?id=335169 --- Comment #2 from DJ Cozatt 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 --- Comment #1 from DJ Cozatt 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=31294&attachment=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
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 Radke 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
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] [PATCH 1/6] mesa: Add field gl_renderbuffer.Unwrapped
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/16/2011 10:26 AM, Chad Versace wrote: > 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. Unfortunately, I don't think any of our shipping hardware supports it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk36TjwACgkQX1gOwKyEAw998ACghRN1Ko2nFzgvXm8w/fmLKI6B +/MAoJRC46z7crD+Cfc3QIO8XCu6Qov7 =t9N5 -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 Tue, 14 Jun 2011 13:09:50 +0200, Andreas Radke 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] leak of gem_objects on intel i965
On Tue, 14 Jun 2011 15:30:53 +0100, Chris Wilson wrote: > If the leak still occurs with 2.6.39, it is definitely in userspace. ;-) > -Chris I wouldn't be surprised if Mesa is neglecting to decrement some region's refcount. i965 makes a lot of refcounting blunders. We're slowly tidying it up, however. Andreas, do the leaks still exist with 2.6.39? - Chad ___ 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
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
>
> [snip]
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Fix region refcounting in intel_alloc_renderbuffer_storage
On Thu, 16 Jun 2011 00:06:11 +0100, Chris Wilson wrote: > I'm curious, what's the advantage? i.e. what am I not understanding that > needs to be explained in the changelog? > -Chris Oops, I was wrong. NAK this patch. I thought these regions were never referenced, anywhere. But now I see that intel_region_alloc_internal sets the refcount ot 1. Oops. - Chad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/7] mesa, intel: Support s8z24 pure renderbuffers when using separate stencil
On Wed, 15 Jun 2011 17:34:37 -0700, Chad Versace wrote: > Only patch 1 affects core mesa; the remaining patches are in the intel shared > driver. > > Patch 6 is just a clean-up leading to patch 7. > > Chad Versace (7): > mesa: Add field gl_renderbuffer.Unwrapped > intel: Unconditionally enable support for S8_Z24 texture format > intel: Support renderbuffer unwrappers in intel_get_renderbuffer() > intel: Fix intel_framebuffer_map/unamp to use intel_get_renderbuffer() > intel: Fix region refcounting in intel_alloc_renderbuffer_storage > intel: Unobfuscate intel_alloc_renderbuffer_storage > intel: Support s8z24 pure renderbuffers when using separate stencil NAK this patch series. A comment from Chris Wilson revealed that patch 5/7 is incorrect. I've resubmitted with that patch removed. - Chad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] mesa: Add field gl_renderbuffer.Unwrapped
On 06/16/2011 07:14 AM, Brian Paul wrote: > On 06/15/2011 06:34 PM, Chad Versace 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. >> >> Alter the following function to take Unwrapped into account: >> _mesa_framebuffer_renderbuffer >> _mesa_update_depth_buffer >> _mesa_update_stencil_buffer >> _mesa_reference_renderbuffer > > Chad, could you give a bit of background on the big picture here? When/why do > we need to represent separate depth and stencil > buffers as a unified depth+stencil buffer? Like Ian said, we have future hardware that requires a separate stencil buffer. But we still need to accomodate apps that use renderbuffers with format GL_DEPTH_STENCIL. > I'd like to move away from the whole renderbuffer/wrapper business. As I > mentioned the other day, I'd like to move to a simple > map/unmap model to accesss renderbuffer (and texture) data. Mesa would > generally see the buffers as-is without any kind of > wrappers/converters. If a driver needed to change the appearance of > buffer(s) to core Mesa, it would have to do the data > munging inside map()/unmap(). Would that approach work with the problem > you're solving with unwrappers? > > Thanks. > > -Brian I think the problems I'm solving are tractable within that approach. The solution would involve defing custom renderbuffer accessors (GetRow, PutRow) for the fake S8_Z24 buffer. I'll give that a try today and see how it works. -- 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] 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 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 1/6] mesa: Add field gl_renderbuffer.Unwrapped
On Thu, Jun 16, 2011 at 1:26 PM, Chad Versace wrote: > On 06/16/2011 08:01 AM, Alex Deucher wrote: >> On Wed, Jun 15, 2011 at 9:09 PM, Chad Versace 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. > I suspect the hardware stores the depth or stencil in some compressed format. On radeon, you have to do a special uncompress operation (either a blit or in place depending on what you want to do) if you want to use the depth or stencil buffer as a texture or render target. Alex > -- > 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 06/16/2011 12:10 AM, Lampersperger Andreas 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: Thread [1] 12367 (Suspended : Signal : SIGSEGV:Segmentation fault) st_visual_to_context_mode() at st_manager.c:309 0xb6ea7be0 st_framebuffer_create() at st_manager.c:441 0xb6ea8352 st_api_make_current() at st_manager.c:732 0xb6ea8456 ^^^ This is Gallium code. The official Intel drivers do not use Gallium. Are you trying to use the unsupported i965g driver? dri_make_current() at dri_context.c:194 0xb6e4662f driBindContext() at dri_util.c:196 0xb6e425a9 dri2_bind_context() at dri2_glx.c:151 0xb7480d10 MakeContextCurrent() at glxcurrent.c:263 0xb7459b2d glXMakeCurrent() at glxcurrent.c:287 0xb7459c43 gdk_gl_window_impl_x11_make_context_current() at gdkglwindow-x11.c:250 0xb7fc583e gdk_gl_drawable_gl_begin() at gdkgldrawable.c:143 0xb7fa384d configure_event() at simple.c:81 0x8049982 ... In st_framebuffer_create() stfbi->visual was not initialized. Do I have to apply other patches to 7.10.3? -Andreas ___ 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] [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 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
[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 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] Status of the GLSL->TGSI translator
On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul 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
Re: [Mesa-dev] [PATCH 1/7] mesa: Add field gl_renderbuffer.Unwrapped
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/16/2011 07:14 AM, Brian Paul wrote: > On 06/15/2011 06:34 PM, Chad Versace 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. >> >> Alter the following function to take Unwrapped into account: >> _mesa_framebuffer_renderbuffer >> _mesa_update_depth_buffer >> _mesa_update_stencil_buffer >> _mesa_reference_renderbuffer > > Chad, could you give a bit of background on the big picture here? > When/why do we need to represent separate depth and stencil buffers as a > unified depth+stencil buffer? We have future hardware that only does separate depth and stencil. However, almost every existing application wants to use packed depth / stencil. Few apps have (tested) fallback paths. > I'd like to move away from the whole renderbuffer/wrapper business. As I > mentioned the other day, I'd like to move to a simple map/unmap model to > accesss renderbuffer (and texture) data. Mesa would generally see the > buffers as-is without any kind of wrappers/converters. If a driver > needed to change the appearance of buffer(s) to core Mesa, it would have > to do the data munging inside map()/unmap(). Would that approach work > with the problem you're solving with unwrappers? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk36Lu0ACgkQX1gOwKyEAw9IxQCfU2tWbcb6pSdHw45oEqT6ddhG L94AoJjrwm1poxo/hpP0LVe/rZjR1gZD =rDOb -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] mesa: Add field gl_renderbuffer.Unwrapped
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/15/2011 05:34 PM, Chad Versace 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.
>
> Alter the following function to take Unwrapped into account:
> _mesa_framebuffer_renderbuffer
> _mesa_update_depth_buffer
> _mesa_update_stencil_buffer
> _mesa_reference_renderbuffer
>
> Signed-off-by: Chad Versace
> ---
> src/mesa/main/fbobject.c | 26 +---
> src/mesa/main/framebuffer.c | 54
> +++---
> src/mesa/main/mtypes.h | 11
> src/mesa/main/renderbuffer.c |6
> 4 files changed, 79 insertions(+), 18 deletions(-)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 2230b26..61a0619 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -379,10 +379,28 @@ _mesa_framebuffer_renderbuffer(struct gl_context *ctx,
> if (rb) {
>_mesa_set_renderbuffer_attachment(ctx, att, rb);
>if (attachment == GL_DEPTH_STENCIL_ATTACHMENT) {
> - /* do stencil attachment here (depth already done above) */
> - att = _mesa_get_attachment(ctx, fb, GL_STENCIL_ATTACHMENT_EXT);
> - assert(att);
> - _mesa_set_renderbuffer_attachment(ctx, att, rb);
> + struct gl_renderbuffer_attachment *depth_att =
> + _mesa_get_attachment(ctx, fb, GL_DEPTH_ATTACHMENT);
> + struct gl_renderbuffer_attachment *stencil_att =
> + _mesa_get_attachment(ctx, fb, GL_STENCIL_ATTACHMENT_EXT);
> + struct gl_renderbuffer *depth_rb;
> + struct gl_renderbuffer *stencil_rb;
> +
> + /* Set depth attachment. */
> + if (rb->Unwrapped[BUFFER_DEPTH]) {
> + depth_rb = rb->Unwrapped[BUFFER_DEPTH];
> + } else {
> + depth_rb = rb;
> + }
Instead of doing this, would it be easier to have Unwrapped[] point back
to itself for non-wrapper renderbuffers? That may have other
consequences that I'm not foreseeing.
> + _mesa_set_renderbuffer_attachment(ctx, depth_att, depth_rb);
> +
> + /* Set stencil attachment. */
> + if (rb->Unwrapped[BUFFER_STENCIL]) {
> + stencil_rb = rb->Unwrapped[BUFFER_STENCIL];
> + } else {
> + stencil_rb = rb;
> + }
> + _mesa_set_renderbuffer_attachment(ctx, stencil_att, stencil_rb);
>}
>rb->AttachedAnytime = GL_TRUE;
> }
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index 66c9bd9..6e1f1f1 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -604,14 +604,20 @@ _mesa_update_framebuffer_visual(struct gl_context *ctx,
>
>
> /**
> - * Update the framebuffer's _DepthBuffer field using the renderbuffer
> - * found at the given attachment index.
> + * \brief Update gl_framebuffer._DepthBuffer.
> *
> - * If that attachment points to a combined GL_DEPTH_STENCIL renderbuffer,
> - * create and install a depth wrapper/adaptor.
> + * Set gl_framebuffer._DepthBuffer to the attachment's renderbuffer, unless
> + * the renderbuffer has packed depth/stencil format.
> + *
> + * Renderbuffers with packed depth/stencil format are a special case. If the
> + * attachment's renderbuffer contains a depth unwrapper (that is,
> + * gl_renderbuffer.Unwrapper[BUFFER_DEPTH != NULL), then install the
> + * unwrapper. Otherwise, create and install a x8_z24 depth wrapper.
> *
> * \param fb the framebuffer whose _DepthBuffer field to update
> * \param attIndex indicates the renderbuffer to possibly wrap
> + *
> + * \see _mesa_new_z24_renderbuffer_wrapper
> */
> void
> _mesa_update_depth_buffer(struct gl_context *ctx,
> @@ -627,9 +633,16 @@ _mesa_update_depth_buffer(struct gl_context *ctx,
>
> if (depthRb && _mesa_is_format_packed_depth_stencil(depthRb->Format)) {
>/* The attached depth buffer is a GL_DEPTH_STENCIL renderbuffer */
> - if (!fb->_DepthBuffer
> - || fb->_DepthBuffer->Wrapped != depthRb
> - || _mesa_get_format_base_format(fb->_DepthBuffer->Format) !=
> GL_DEPTH_COMPONENT) {
> + struct gl_renderbuffer *unwrapper = depthRb->Unwrapped[BUFFER_DEPTH];
> + if (unwrapper) {
> + if (fb->_DepthBuffer != unwrapper) {
> + _mesa_reference_renderbuffer(&fb->_DepthBuffer, unwrapper);
> + }
> + }
> + else if (!fb->_DepthBuffer
> +|| fb->_DepthBuffer->Wrapped != depthRb
> +|| _mesa_get_format_base_format(fb->_DepthBuffer->Format)
> + != GL_DEPTH_COMPONENT) {
> /* need to update wrapper */
> struct gl_renderbuffer *wrapper
> = _mesa_new_z24_renderbuffer_wrapper(ct
Re: [Mesa-dev] Status of the GLSL->TGSI translator
On 06/16/2011 08:41 AM, Jerome Glisse wrote: On Thu, Jun 16, 2011 at 10:08 AM, Brian Paul 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 ? Fragment programs apply to glDrawPixels, glCopyPixels, glBitmap. -Brian ___ 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 Wed, Jun 15, 2011 at 9:09 PM, Chad Versace 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 ___ 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 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] [PATCH 0/6] Overhaul of Gallium configure options
* --enable-debug => build=debug (there's also, "profile", "checked", and "release") * --with-xxx --disable-xxx => just say list target you want, and scons will build that target, and all depencies, and nothing more. For example scons dri-r600g It would be nice to have a list of all targets, but I don't know. Another approach is to specify the directory: scons src/gallium/targets/dri-swrast/ The rest, --prefix=/usr --enable-glx-tls --enable-texture-float, has no equivalent yet: there's no install support, and libGL is not being built yet either. Hopefully soon. Jose - Original Message - > OK, I take the scons patches back. I thought scons was only good for > building llvmpipe and svga on Windows. > > scons --help is not very helpful, it doesn't describe how to build > drivers. Is there a way to exactly reproduce the following configure > options in scons? > > --prefix=/usr --enable-glx-tls --enable-debug --enable-texture-float > --disable-glu --disable-glut --disable-glw > --with-gallium-drivers=r300,r600,swrast --with-dri-drivers=swrast > > Marek > > On Tue, Jun 14, 2011 at 6:45 PM, Jose Fonseca > wrote: > > > > > > - Original Message - > >> On Tue, 2011-06-14 at 18:25 +0200, Marek Olšák wrote: > >> > Hi, > >> > > >> > This series reworks some of our configure options to make > >> > Gallium > >> > easier to configure. > >> > > >> > First, there is a new option --with-gallium-drivers=DIRS, which > >> > replaces the current heap of options --enable-gallium-DRIVER. > >> > --disable-gallium is removed as well, instead, > >> > --with-gallium-drivers= without parameters should be used to > >> > disable Gallium. > >> > > >> > --enable-gallium-egl is removed. having --enable-egl and > >> > --with-gallium-drivers=somedriver is sufficient. > >> > > >> > --with-state-trackers is removed as well. The list of state > >> > trackers is automatically deduced from the --enable-API options > >> > (the vega,egl state trackers) and --with-driver=dri|xlib (the > >> > dri,glx state trackers). Some state trackers lack an enable flag > >> > now, so these two have been added to make the list complete: > >> > --enable-xorg and --enable-d3d1x. > >> > > >> > In order to be able to "git bisect run" through this change, you > >> > can specify both the old and new options at the same time. Those > >> > that are unsupported are ignored. > >> > > >> > Other than that, I am enabling r600g by default and removing > >> > r300g > >> > and r600g from scons. I am not a fan of having multiple build > >> > systems and most people prefer autoconf anyway. It's not like > >> > anybody needs to build those drivers on Windows. > >> > >> I did use r600g + scons for the little bit of work I did there, > >> and > >> if I > >> went back to it, it would continue to be with scons... > >> > >> Is there a significant cost to you having it there? > >> > >> Keith > > > > Ditto. I've been building r600g on linux with scons too -- scons > > it's much better for continuous integration/testing, given one > > doesn't need to do make clean everytime, just to ensure the > > dependencies are computed correctly. > > > > Given that autoconf will never support MSVC, if people don't like > > multiple build systems, then autoconf+gmake is definely not the > > one to bet on. > > > > I've been (slowly) trying to get scons to build everything, and > > plan to do so. So that scons can be a viable alternative > > eventually. > > > > Jose > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] mesa: Add field gl_renderbuffer.Unwrapped
On 06/15/2011 06:34 PM, Chad Versace 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. Alter the following function to take Unwrapped into account: _mesa_framebuffer_renderbuffer _mesa_update_depth_buffer _mesa_update_stencil_buffer _mesa_reference_renderbuffer Chad, could you give a bit of background on the big picture here? When/why do we need to represent separate depth and stencil buffers as a unified depth+stencil buffer? I'd like to move away from the whole renderbuffer/wrapper business. As I mentioned the other day, I'd like to move to a simple map/unmap model to accesss renderbuffer (and texture) data. Mesa would generally see the buffers as-is without any kind of wrappers/converters. If a driver needed to change the appearance of buffer(s) to core Mesa, it would have to do the data munging inside map()/unmap(). Would that approach work with the problem you're solving with unwrappers? Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
- Original Message -
> On Mon, Jun 13, 2011 at 3:23 PM, Jose Fonseca
> wrote:
> >
> > - Original Message -
> >> Am 05.06.2011 06:31, schrieb Younes Manton:
> >> > 2011/6/4 Jose Fonseca :
> >> >> At very least there are ovious things that need to be fixed:
> >> >>
> >> >> - get_param / is_format_supported should not be duplicated from
> >> >> screen.
> >> >
> >> > This is also deliberate.
> >
> >> > Params and surface formats may depend on
> >> > the
> >> > codec/profile/dimensions of the video stream the context was
> >> > created
> >> > to decode. There is not always enough info available in
> >> > pipe_screen
> >> > alone to determine if a particular cap or surface is supported.
> >> > The
> >> > current implementation largely wraps pipe_screen because again
> >> > it's
> >> > using the 3D pipeline and we don't have to deal with funny
> >> > decoding
> >> > hardware constraints.
> >>
> >> I'm not sure if that's the right answer though, couldn't you just
> >> as
> >> well require a driver to handle all dimensions etc. for a given
> >> codec?
> >> If necessary should just use the shader stages (or cpu...)
> >> instead?
> >>
> >> Also, just glancing over the interface changes:
> >> +enum pipe_video_codec
> >> +{
> >> + PIPE_VIDEO_CODEC_UNKNOWN = 0,
> >> + PIPE_VIDEO_CODEC_MPEG12, /**< MPEG1, MPEG2 */
> >> + PIPE_VIDEO_CODEC_MPEG4, /**< DIVX, XVID */
> >> + PIPE_VIDEO_CODEC_VC1, /**< WMV */
> >> + PIPE_VIDEO_CODEC_MPEG4_AVC /**< H.264 */
> >> +};
> >> +
> >> +enum pipe_video_profile
> >> +{
> >> + PIPE_VIDEO_PROFILE_UNKNOWN,
> >> + PIPE_VIDEO_PROFILE_MPEG1,
> >> + PIPE_VIDEO_PROFILE_MPEG2_SIMPLE,
> >> + PIPE_VIDEO_PROFILE_MPEG2_MAIN,
> >> + PIPE_VIDEO_PROFILE_MPEG4_SIMPLE,
> >> + PIPE_VIDEO_PROFILE_MPEG4_ADVANCED_SIMPLE,
> >> + PIPE_VIDEO_PROFILE_VC1_SIMPLE,
> >> + PIPE_VIDEO_PROFILE_VC1_MAIN,
> >> + PIPE_VIDEO_PROFILE_VC1_ADVANCED,
> >> + PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE,
> >> + PIPE_VIDEO_PROFILE_MPEG4_AVC_MAIN,
> >> + PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH
> >> +};
> >> Do you really need both here?
> >>
> >> @@ -229,9 +229,27 @@ enum pipe_format {
> >> PIPE_FORMAT_L32A32_FLOAT = 161,
> >> PIPE_FORMAT_I32_FLOAT = 162,
> >>
> >> + PIPE_FORMAT_YV12 = 163,
> >> + PIPE_FORMAT_YV16 = 164,
> >> + PIPE_FORMAT_IYUV = 165, /**< aka I420 */
> >> + PIPE_FORMAT_NV12 = 166,
> >> + PIPE_FORMAT_NV21 = 167,
> >> + PIPE_FORMAT_AYUV =
> >> PIPE_FORMAT_A8R8G8B8_UNORM,
> >> + PIPE_FORMAT_VUYA =
> >> PIPE_FORMAT_B8G8R8A8_UNORM,
> >> + PIPE_FORMAT_XYUV =
> >> PIPE_FORMAT_X8R8G8B8_UNORM,
> >> + PIPE_FORMAT_VUYX =
> >> PIPE_FORMAT_B8G8R8X8_UNORM,
> >> + PIPE_FORMAT_IA44 = 168,
> >> + PIPE_FORMAT_AI44 = 169,
> >> +
> >> PIPE_FORMAT_COUNT
> >> };
> >> Defining these formats as another format feels wrong. There might
> >> be
> >> reasons why you'd want to use them in normal 3d contexts (ok maybe
> >> not
> >> really) but if you can't distinguish the format that's a no go.
> >
> > Yes this is also incorrect. Blitting from PIPE_FORMAT_AYUV to
> > PIPE_FORMAT_A8R8G8B8_UNORM is not a no-op.
> > I actually have llvmpipe AYUV support implemented in a private
> > branch.
>
> This wasn't intended to be permanent, just a quick hack that worked
> for softpipe and 3D decoding, since for the 3D decoding case you'll
> end up substituting an RGBA surface for AYUV anyhow.
>
> >> Frankly I'm not sure if all these formats really should be simple
> >> PIPE_FORMATs even, since chances you can use them in normal 3d
> >> contexts
> >> are next to zero anyway (especially the planar stuff hurts).
> >
> > That's fine. Pixel formats just need to uniquely describe out to
> > interpret the pixels. A 3d context doesn't need to support all of
> > them.
> >
> > I'll see
> >> though where that's coming from (as pipe_surface,
> >> pipe_sampler_state
> >> and
> >> friends are reused, even though the entry points are not). Though
> >> I'm
> >> not sure the all-new-entry points with reused gallium structs is
> >> really
> >> the right approach. Maybe if you need separate contexts etc.
> >> anyway
> >> (to
> >> be able to exploit video hardware) it would be better if you'd
> >> just
> >> use
> >> all your own structs better suited for video tasks. The vl code
> >> could
> >> then translate that stuff to "normal" gallium.
> >> If others are happy with the interface, I won't object though.
> >> I've
> >> no
> >> clue really how a better interface would look like...
> >
> > My gut feel looking at [1] is that pipe_video_context interface
> > should be either an extension of pipe_context, or optional
> > entry-points in pipe_context. Because there's a lot of
> > functionality needed for a pipe_context (low level resource
> > management, reloca
Re: [Mesa-dev] Status of the GLSL->TGSI translator
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. 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. 5. I also see the compilation failure that Dave mentioned. -Brian ___ 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 12:46 AM, Dave Airlie wrote: > On Thu, Jun 16, 2011 at 3:22 PM, Dave Airlie wrote: > > On Thu, Jun 16, 2011 at 7:38 AM, 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. > > > > I just pulled it into master here, and got this on build on an F15 box > > with gcc 4.6.0. > > > > g++ -c -o state_tracker/st_glsl_to_tgsi.o > > state_tracker/st_glsl_to_tgsi.cpp -DFEATURE_GL=1 -D_GNU_SOURCE > > -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 > > -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING > > -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DGALLIUM_LLVMPIPE > > -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0208 -I../../include > > -I../../src/glsl -I../../src/mesa -I../../src/mapi > > -I../../src/gallium/include -I../../src/gallium/auxiliary > > -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS > > -D__STDC_CONSTANT_MACROS -g -O2 -Wall -fno-strict-aliasing -fPIC > > -fvisibility=hidden > > state_tracker/st_glsl_to_tgsi.cpp:392:70: error: call of overloaded > > ‘st_src_reg(gl_register_file, int, NULL)’ is ambiguous > > state_tracker/st_glsl_to_tgsi.cpp:392:70: note: candidates are: > > state_tracker/st_glsl_to_tgsi.cpp:103:4: note: > > st_src_reg::st_src_reg(gl_register_file, int, int) > > state_tracker/st_glsl_to_tgsi.cpp:90:4: note: > > st_src_reg::st_src_reg(gl_register_file, int, const glsl_type*) > > gmake[2]: *** [state_tracker/st_glsl_to_tgsi.o] Error 1 > > I fixed this by casting NULL to (const glsl_type *)NULL, but not sure > what the proper answer is, > > With that I get 0 piglit regressions due to this on r600g on evergreen. > > Dave. > Hm, I never got that error with my version of g++ (I think 4.5). It looks like it just doesn't know whether NULL is a pointer or an integer (stupid C++), so casting it to (const glsl_type *)NULL is the correct fix. I'll commit a fix for that when I get back to my computer at home. ___ 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 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Sven Arvidsson 2011-06-16 04:54:55 PDT --- (In reply to comment #5) > Sven, would you like to try your game again to see if the rendering is any > better? There's still rendering issues, but it seems to be shader compiler issues, so I'm going to file new bugs for these. Thanks for working on this! -- 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] st/mesa: improved is_interleaved_arrays() checking
- Original Message - > On Tue, 2011-06-14 at 09:39 -0600, Brian Paul wrote: > > Good question. I was thinking that the interleaved vs. > > non-interleaved paths could probably be merged with a little work. > > I > > don't remember the original reason for doing things as they are. > > I think it enabled an easier upload path within the > driver/state-tracker > -- memcpy a single range to a single VBO, rather than gathering. > Now that the upload is potentially code-generated, that may no longer > matter as much. Yes, for user pointer arrays it still makes sense indeed. But for pure VBOs I don't think that detecting interleaved arrays matters. Jose ___ 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
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 mailto: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 -- Registergericht: Traunstein / Registry Court: HRB 275 - Sitz / Head Office: Traunreut Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman), Michael Grimm, Matthias Fauser, Sebastian Tondorf http://www.heidenhain.de/disclaimer"; target="_blank">E-Mail Haftungsausschluss / E-Mail Disclaimer 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] leak of gem_objects on intel i965
On Thu, Jun 16, 2011 at 00:10, Lampersperger Andreas < 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 ___ 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
Hello Stéphane,
I've tried your patch (I adopted it to 7.10.3, see attached patch), but it
results in a SEGFAULT:
Thread [1] 12367 (Suspended : Signal : SIGSEGV:Segmentation fault)
st_visual_to_context_mode() at st_manager.c:309 0xb6ea7be0
st_framebuffer_create() at st_manager.c:441 0xb6ea8352
st_api_make_current() at st_manager.c:732 0xb6ea8456
dri_make_current() at dri_context.c:194 0xb6e4662f
driBindContext() at dri_util.c:196 0xb6e425a9
dri2_bind_context() at dri2_glx.c:151 0xb7480d10
MakeContextCurrent() at glxcurrent.c:263 0xb7459b2d
glXMakeCurrent() at glxcurrent.c:287 0xb7459c43
gdk_gl_window_impl_x11_make_context_current() at
gdkglwindow-x11.c:250 0xb7fc583e
gdk_gl_drawable_gl_begin() at gdkgldrawable.c:143 0xb7fa384d
configure_event() at simple.c:81 0x8049982
...
In st_framebuffer_create() stfbi->visual was not initialized.
Do I have to apply other patches to 7.10.3?
-Andreas
Von: marc...@google.com [mailto:marc...@google.com] Im Auftrag von Stéphane
Marchesin
Gesendet: Donnerstag, 16. Juni 2011 04:22
An: Lampersperger Andreas
Cc: Chris Wilson; mesa-dev@lists.freedesktop.org
Betreff: Re: [Mesa-dev] leak of gem_objects on intel i965
On Wed, Jun 15, 2011 at 01:53, Lampersperger Andreas
mailto:lampersperger.andr...@heidenhain.de>>
wrote:
Hello,
I've tried 2.6.39.1 and the gem_objects leak still exists.
I found the leak also on a i915 not only on a i965.
It only disappears if I set LIBGL_ALLWAYS_SOFTWARE (not really an opinion ;-).
Now I can try to update user space libraries, what lib would you suspect most?
libdrm 2.4.23
xorg-server 1.10.2
xf86-video-intel-2.15
gtkglext-1.2.0
mesa-7.10.2
Or I can continue debugging, if anyone can give me a hint to the following
question:
In which function are the buffers freed, which are received
from xserver via DRI2GetBuffersWithFormat(..) at dri2.c:431?
This sounds familiar. You may want to try the patch I posted earlied today
("glx: implement drawable refcounting").
Stéphane
--
Registergericht: Traunstein / Registry Court: HRB 275 - Sitz / Head Office:
Traunreut
Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard
Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender /
Chairman),
Michael Grimm, Matthias Fauser, Sebastian Tondorf
http://www.heidenhain.de/disclaimer"; target="_blank">E-Mail
Haftungsausschluss / E-Mail Disclaimer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
