[Mesa-dev] [PATCH 3/3] intel: Merge identical cases in switch statement.

Signed-off-by: Nick Bowler --- src/mesa/drivers/dri/intel/intel_fbo.c | 16 +--- 1 files changed, 5 insertions(+), 11 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers/dri/intel/intel_fbo.c index 4a83886..2fdb6e4 100644 --- a/src/mesa/drivers/dri/

[Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

Intel sometimes uses packed depth/stencil buffers even when only a depth buffer or only a stencil buffer was requested. GL specifies that GL_DEPTH_COMPONENT renderbuffers are *not* stencil-attachable, but the current check happily attaches these buffers to the stencil attachment point (or vice-ver

[Mesa-dev] [PATCH 1/3] mesa: Identify packed depth/stencil buffers using the Format field.

Intel sometimes uses packed depth/stencil buffers even when only a depth buffer or only a stencil buffer was requested. Common code currently uses the _BaseFormat field to determine whether a depth/stencil wrapper is necessary. But unless the user explicitly requested a packed depth/stencil buffe

[Mesa-dev] [PATCH 0/3] FBO fixes for intel.

The following series fixes a couple issues with FBOs on the intel driver; fallout from the driver's decision to use packed depth/stencil buffers when only one was requested by the user. These patches are completely independent. I've also prepared some piglit tests for the issues, but I am not sur

Re: [Mesa-dev] [PATCH 1/3] mesa: Identify packed depth/stencil buffers using the Format field.

On 08/25/2010 07:14 AM, Nick Bowler wrote: Intel sometimes uses packed depth/stencil buffers even when only a depth buffer or only a stencil buffer was requested. Common code currently uses the _BaseFormat field to determine whether a depth/stencil wrapper is necessary. But unless the user expl

Re: [Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

On 08/25/2010 07:14 AM, Nick Bowler wrote: Intel sometimes uses packed depth/stencil buffers even when only a depth buffer or only a stencil buffer was requested. GL specifies that GL_DEPTH_COMPONENT renderbuffers are *not* stencil-attachable, but the current check happily attaches these buffers

Re: [Mesa-dev] mesa compile, talloc

On 26 aug 2010, at 15.10, Trevor Woerner wrote: Hi, I was trying to compile Xorg and had a bit of a stumble in the mesa directory. The configure.ac looks for the talloc package and assumes your distribution has supplied a "talloc.pc" to work with the pkg-config system. Unfortunately mine doe

Re: [Mesa-dev] [PATCH 3/3] intel: Merge identical cases in switch statement.

On 08/25/2010 07:14 AM, Nick Bowler wrote: Signed-off-by: Nick Bowler --- src/mesa/drivers/dri/intel/intel_fbo.c | 16 +--- 1 files changed, 5 insertions(+), 11 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers/dri/intel/intel_fbo.c index 4a838

[Mesa-dev] [Bug 29638] [glsl2]Mesa demo fpglsl render incorrectly

https://bugs.freedesktop.org/show_bug.cgi?id=29638 --- Comment #3 from Brian Paul 2010-08-26 07:27:24 PDT --- I've fixed the demo program. ac1d244a50087cd454c0eea02115561fac932865 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail beca

[Mesa-dev] [PATCH v2] mesa: Identify packed depth/stencil buffers using the Format field.

Intel sometimes uses packed depth/stencil buffers even when only a depth buffer or only a stencil buffer was requested. Common code currently uses the _BaseFormat field to determine whether a depth/stencil wrapper is necessary. But unless the user explicitly requested a packed depth/stencil buffe

Re: [Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

On 8/26/10, Brian Paul wrote: > This looks good. I'm not sure if there's a piglit test that would > exercise this. I prepared piglit tests for this and the other issue. Should I send them to this list as well? It's not obvious to me where the maintainer(s) want piglit patches sent. > Did you

Re: [Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

On 08/26/2010 08:33 AM, Nick Bowler wrote: On 8/26/10, Brian Paul wrote: This looks good. I'm not sure if there's a piglit test that would exercise this. I prepared piglit tests for this and the other issue. Should I send them to this list as well? It's not obvious to me where the maintain

Re: [Mesa-dev] [PATCH v2] mesa: Identify packed depth/stencil buffers using the Format field.

I added a missing semicolon after the prototype in formats.h and I changed the return values to GL_TRUE/FALSE to be consistant. Committed. Thanks. -Brian On 08/26/2010 08:26 AM, Nick Bowler wrote: Intel sometimes uses packed depth/stencil buffers even when only a depth buffer or only a stenc

Re: [Mesa-dev] [PATCH v2] mesa: Identify packed depth/stencil buffers using the Format field.

On 8/26/10, Brian Paul wrote: > I added a missing semicolon after the prototype in formats.h and I > changed the return values to GL_TRUE/FALSE to be consistant. > Committed. Thanks. Whoops. I fixed the missing semicolon, but then forgot to change the commit id I passed to git send-email. Sorr

[Mesa-dev] Mesa + glxPixmaps problems

Hi folks, I've been working on some code that makes extensive use of glxPixmaps for offscreen rendering, and I've hit a number of problems. First, My colleague and I found that the following sequence of events led to a crash: context1 = glXCreateNewContext() xPixmap = XCreatePixmap () glxP

[Mesa-dev] Mesa EGL extensions

This is a little long, but I was wondering about a couple of the EGL extensions Mesa implements: Re: the new EGL_KHR_screenless_opengl and friends that took up the functionality of EGL_MESA_no_surface - are there specs for those anywhere on the web? Google gave nothing but Mesa itself, and the KHR

[Mesa-dev] [Bug 29793] [glsl2]piglit glslparsertest_glsl2_struct-05.vert and glslparsertest_glsl2_redeclaration-02.vert fail

https://bugs.freedesktop.org/show_bug.cgi?id=29793 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Re: [Mesa-dev] Mesa EGL extensions

On Thu, Aug 26, 2010 at 11:55 AM, nobled wrote: > This is a little long, but I was wondering about a couple of the EGL > extensions Mesa implements: > > Re: the new EGL_KHR_screenless_opengl and friends that took up the > functionality of EGL_MESA_no_surface - are there specs for those > anywhere

[Mesa-dev] [Bug 29578] [Gallium/Draw] Kwin effects don't work with Gallium3D driver

https://bugs.freedesktop.org/show_bug.cgi?id=29578 --- Comment #14 from Marek Olšák 2010-08-26 11:17:55 PDT --- The driver has not software fallback so I don't see how it could have so high CPU usage. It appears to me KDE uses the selection and/or feedback mode, both of which don't touch the driv

[Mesa-dev] [Bug 29578] [Gallium/Draw] Kwin effects don't work with Gallium3D driver

https://bugs.freedesktop.org/show_bug.cgi?id=29578 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Mesa-dev] [Bug 29822] New: [glsl bisected] Unigine Sanctuary v2.2: no shadows (allocation of uniforms failed)

https://bugs.freedesktop.org/show_bug.cgi?id=29822 Summary: [glsl bisected] Unigine Sanctuary v2.2: no shadows (allocation of uniforms failed) Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW

Re: [Mesa-dev] Mesa + glxPixmaps problems

Ian Molton writes: > Sadly, however, it appears that there are many more similar looking > bugs in Mesa. Has anyone actually used Mesa to render to glxPixmaps? > are there patches available to make this stuff work? FBOs are a (much) better way to achieve what you want: they are cross platform and

[Mesa-dev] [Bug 29822] [glsl bisected] Unigine Sanctuary v2.2: no shadows (allocation of uniforms failed)

https://bugs.freedesktop.org/show_bug.cgi?id=29822 Pavel Ondračka changed: What|Removed |Added Keywords||regression CC|

Re: [Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Bowler wrote: > Intel sometimes uses packed depth/stencil buffers even when only a > depth buffer or only a stencil buffer was requested. GL specifies > that GL_DEPTH_COMPONENT renderbuffers are *not* stencil-attachable, > but the current check h

Re: [Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

On 08/26/2010 12:50 PM, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Bowler wrote: Intel sometimes uses packed depth/stencil buffers even when only a depth buffer or only a stencil buffer was requested. GL specifies that GL_DEPTH_COMPONENT renderbuffers are *not* sten

Re: [Mesa-dev] Mesa (master): r300g: fix gl_PointCoord

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marek Olšák wrote: > On Thu, Aug 26, 2010 at 4:08 AM, Luca Barbieri > wrote: > > Also, doesn't sprite coord replacement also affect gl_TexCoord in GLSL? > > I suspect it does. Why would it? gl_TexCoord is a set o

[Mesa-dev] [Bug 29578] [Gallium/Draw] Kwin effects don't work with Gallium3D driver

https://bugs.freedesktop.org/show_bug.cgi?id=29578 --- Comment #16 from Niels Ole Salscheider 2010-08-26 12:49:46 PDT --- There seems to be something wrong in KDE's functionality check. If you disable them all effects are hardware accelerated (at least for me; although the new glsl compiler some

[Mesa-dev] [Bug 29823] New: GetUniform[if]v busted

https://bugs.freedesktop.org/show_bug.cgi?id=29823 Summary: GetUniform[if]v busted Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: critical Priority: medium Componen

Re: [Mesa-dev] Mesa (master): r300g: fix gl_PointCoord

OpenGL 4.1 compatibility profile says: << All fragments produced in rasterizing a point sprite are assigned the same as- sociated data, which are those of the vertex corresponding to the point. However, the fragment shader built-in gl_PointCoord contains point sprite texture coor- dinates. Addition

[Mesa-dev] [Bug 29824] New: OSMesaMakeCurrent triggers assertion on multiple MakeCurrent calls

https://bugs.freedesktop.org/show_bug.cgi?id=29824 Summary: OSMesaMakeCurrent triggers assertion on multiple MakeCurrent calls Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW

Re: [Mesa-dev] Mesa + glxPixmaps problems

On Thu, 26 Aug 2010 16:30:55 +0100, Ian Molton wrote: > > Hi folks, > > I've been working on some code that makes extensive use of glxPixmaps > for offscreen rendering, and I've hit a number of problems. > > First, My colleague and I found that the following sequence of events > led to a cra

[Mesa-dev] [Bug 29824] OSMesaMakeCurrent triggers assertion on multiple MakeCurrent calls

https://bugs.freedesktop.org/show_bug.cgi?id=29824 Tom Fogal changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Mesa-dev] [Bug 10966] workaround to avoid the assert main/renderbuffer.c:2041: _mesa_add_renderbuffer:...

https://bugs.freedesktop.org/show_bug.cgi?id=10966 Tom Fogal changed: What|Removed |Added CC||vladi...@pobox.com --- Comment #17 from Tom

[Mesa-dev] [PATCH] mesa: Use the format info to identify packed depth/stencil formats.

Due to a misunderstanding of the Z24_X8 and X8_Z24 formats, the earlier patch created depth/stencil wrappers for them. This broke swrast. Use the format info instead, which only identifies Z24_S8 and S8_Z24 as packed depth/stencil. It also has the advantage of being nicer code. Signed-off-by: N

Re: [Mesa-dev] mesa compile, talloc

On Thu, Aug 26, 2010 at 10:17 AM, Jakob Bornecrantz wrote: > On 26 aug 2010, at 15.10, Trevor Woerner wrote: >> If the talloc sources are being included in the mesa package, why does >> the configure.ac require talloc be installed before you can start >> building? > > It is only there for system w

[Mesa-dev] [Bug 29831] New: git Mesa 7.9-devel no longer running the 'engine' demo

https://bugs.freedesktop.org/show_bug.cgi?id=29831 Summary: git Mesa 7.9-devel no longer running the 'engine' demo Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal

Re: [Mesa-dev] Mesa EGL extensions

2010/8/27 Kristian Høgsberg : > On Thu, Aug 26, 2010 at 11:55 AM, nobled wrote: >> This is a little long, but I was wondering about a couple of the EGL >> extensions Mesa implements: >> >> Re: the new EGL_KHR_screenless_opengl and friends that took up the >> functionality of EGL_MESA_no_surface -