Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
On Mon, 2012-03-05 at 19:41 -0800, Benoit Jacob wrote: - Original Message - On Sat, 3 Mar 2012 13:21:08 -0800, Alon Zakai alonza...@gmail.com wrote: In the project I work on (Emscripten, an open source C/C++ to JavaScript compiler that utilizes LLVM), we want to be able to compile OpenGL games from desktop so that they work on WebGL on the web. The main remaining difficulty for us is to emulate the full OpenGL API using the WebGL API. WebGL is close to OpenGL ES 2.0, so it has shaders but lacks the fixed-function pipeline, glBegin etc. So far we have some of the OpenGL ES 2.0 API implemented, you can see a demo of it on the web here: http://people.mozilla.org/~eakhgari/es2gears.html Too bad it refuses to run on big endian hosts yet. :) Desktop GL includes ridiculous things like texture borders and GL_CLAMP and glDrawPixels and other things we all wish we could just forget about. ES2 doesn't have those equivalents, so you'd have to emulate them. That's exactly where we were hoping that Mesa might be able to help: doesn't Mesa already have an implementation of these OpenGL 1 pieces on top of something closer to OpenGL ES 2 (which IIUC is far closer to how modern hardware really works)? If Mesa had an implementation of GL1 on top of GLES2, Emscripten (Alon's C/C++-to-JS translator) could compile it to JS. For a bunch of it, apps don't use it so nobody would notice. glBitmap and glDrawPixels are reasonably popular, though. You should be able to build those with shaders, though. You can see partial implementations for these in on top of fixed function in Mesa as src/mesa/drivers/common/meta.c (contributions welcome, particularly in the form of GLSL-based implementations of them!) Thanks for the pointer but that (a GLES2-based implementation) is precisely what we're looking for :-) Before we'd start caring about glBitmap and glDrawPixels, we have more fundamental things to implement: - glBegin ... glVertex ... glEnd - glShadeModel(GL_FLAT) (this one seems really hard to do with OpenGL ES2, a real capability regression from OpenGL [ES] 1 it seems!) - display lists - the lighting model (glLight, glMaterial) Does Mesa have code that could be reused to implement some of that on top of ES2? I suspect you're thinking of the Gallium3D framework, and I think it could indeed be useful for this. Basically, you should only need to write: * A core Gallium3D driver (src/gallium/drivers/.../) which translates shaders from TGSI to GLSL (should be trivial at least for a first pass) and Gallium3D state to GLES / WebGL state calls. * Possibly some environment glue code (src/gallium/winsys/.../). * Target glue code (src/gallium/targets/.../). The parts which translate from OpenGL/GLSL to Gallium3D/TGSI (src/mesa/state_tracker/) are shared between all Gallium3D drivers. There might be some gotchas I'm not aware of though... -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Missing copyright header in dri/common/dri_util.c
Would it be possible to add missing copyrights to dri_util.c? Thanks, Tomasz___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/9] st/vdpau: implement support for extra mixer layers
On 05.03.2012 23:56, Emil Velikov wrote: On Sun, 04 Mar 2012 11:52:36 -, Christian König deathsim...@vodafone.de wrote: Signed-off-by: Christian König deathsim...@vodafone.de --- src/gallium/state_trackers/vdpau/mixer.c | 27 +-- 1 files changed, 21 insertions(+), 6 deletions(-) Hello Christian Would you consider pushing patches into a branch at fd.o IMHO it would make testing a bit easier Hi Emil, well I used to do that, but gotten so less feedback that I stopped. Anyway a branch with my current set of mesa patches can often be found on ssh://people.freedesktop.org/~deathsimple/mesa. If you want to test something specific just leave me a note and I will push it there. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
For a bunch of it, apps don't use it so nobody would notice. glBitmap and glDrawPixels are reasonably popular, though. You should be able to build those with shaders, though. You can see partial implementations for these in on top of fixed function in Mesa as src/mesa/drivers/common/meta.c (contributions welcome, particularly in the form of GLSL-based implementations of them!) Thanks for the pointer but that (a GLES2-based implementation) is precisely what we're looking for :-) Before we'd start caring about glBitmap and glDrawPixels, we have more fundamental things to implement: - glBegin ... glVertex ... glEnd - glShadeModel(GL_FLAT) (this one seems really hard to do with OpenGL ES2, a real capability regression from OpenGL [ES] 1 it seems!) - display lists - the lighting model (glLight, glMaterial) Does Mesa have code that could be reused to implement some of that on top of ES2? I suspect you're thinking of the Gallium3D framework, and I think it could indeed be useful for this. Hah, OK. That makes sense. Basically, you should only need to write: * A core Gallium3D driver (src/gallium/drivers/.../) which translates shaders from TGSI to GLSL (should be trivial at least for a first pass) and Gallium3D state to GLES / WebGL state calls. * Possibly some environment glue code (src/gallium/winsys/.../). * Target glue code (src/gallium/targets/.../). The parts which translate from OpenGL/GLSL to Gallium3D/TGSI (src/mesa/state_tracker/) are shared between all Gallium3D drivers. Many thanks for the pointers! Do you think that the translation of Gallium3D state to GL state could be efficient (given that this is the converse of the primary use case, which is IIUC to convert GL state to Gallium3D state)? Just checking if this has a reasonable chance of performing well. Benoit There might be some gotchas I'm not aware of though... -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
- Original Message - To solve these, I don't think building a Mesa driver would help you too much -- it seems like a big detour to mostly get to the same point of hooking desktop glBlendFunc up to WebGL glBlendFunc and so on (git grep ctx-\API suggests not too many overrides are needed). Eric, I reread this part of your email and only understand it now that I've read Michel's email. I understand that OpenGL call - Gallium3D - WebGL call seems like useless complication and when possible, it is much better to map OpenGL calls directly to WebGL calls without going through Gallium3D. Emscripten already maps OpenGL ES 2 calls directly to WebGL calls. So in principle, we would only need to go through Gallium3D for the OpenGL calls that are not part of OpenGL ES 2. In practice, there is a problem: if some/many calls skip Gallium3D, then Gallium3D won't know about all the state. Maybe if going through Gallium3D is cheap enough, we should not worry and just enable a OpenGL mode where all the calls go through Gallium3D, while in OpenGL ES2 mode we'd keep our direct mapping to WebGL calls. Do you expect that going through Gallium3D will incur a large overhead for OpenGL ES 2 calls? What makes me hopeful is that in WebGL, call overhead is already much larger than in OpenGL, so hopefully the Gallium3D overhead would be negligible. But if you think that Gallium3D overhead is going to be large (when all this is compiled to JavaScript) then my next question would be, do you see a way that we could pay this overhead only for OpenGL 1 calls without affecting the performance of OpenGL ES 2 calls? Cheers, Benoit ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
- Original Message - http://people.mozilla.org/~eakhgari/es2gears.html Too bad it refuses to run on big endian hosts yet. :) Off-topic, but just FYI: Emscripten uses a Typed Array to represent the heap, and Typed Arrays expose endianness which means that it's up to the application developer to make sure that their code works with both endiannesses. So in this case, I guess the solution would be to compile es2gears twice. It's controversial that Typed Arrays expose endianness (TC39 is not fond of that) but so far, AFAIK, no full solution to that problem has been found. Cheers, Benoit ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
On Die, 2012-03-06 at 05:11 -0800, Benoit Jacob wrote: For a bunch of it, apps don't use it so nobody would notice. glBitmap and glDrawPixels are reasonably popular, though. You should be able to build those with shaders, though. You can see partial implementations for these in on top of fixed function in Mesa as src/mesa/drivers/common/meta.c (contributions welcome, particularly in the form of GLSL-based implementations of them!) Thanks for the pointer but that (a GLES2-based implementation) is precisely what we're looking for :-) Before we'd start caring about glBitmap and glDrawPixels, we have more fundamental things to implement: - glBegin ... glVertex ... glEnd - glShadeModel(GL_FLAT) (this one seems really hard to do with OpenGL ES2, a real capability regression from OpenGL [ES] 1 it seems!) - display lists - the lighting model (glLight, glMaterial) Does Mesa have code that could be reused to implement some of that on top of ES2? I suspect you're thinking of the Gallium3D framework, and I think it could indeed be useful for this. Hah, OK. That makes sense. Basically, you should only need to write: * A core Gallium3D driver (src/gallium/drivers/.../) which translates shaders from TGSI to GLSL (should be trivial at least for a first pass) and Gallium3D state to GLES / WebGL state calls. * Possibly some environment glue code (src/gallium/winsys/.../). * Target glue code (src/gallium/targets/.../). The parts which translate from OpenGL/GLSL to Gallium3D/TGSI (src/mesa/state_tracker/) are shared between all Gallium3D drivers. Many thanks for the pointers! Do you think that the translation of Gallium3D state to GL state could be efficient (given that this is the converse of the primary use case, which is IIUC to convert GL state to Gallium3D state)? Just checking if this has a reasonable chance of performing well. It does. VMware uses Gallium3D for the guest drivers to achieve OpenGL hardware acceleration in virtual machines, and it performs well under presumably worse circumstances (there's a virtual machine barrier between the Gallium3D driver in the guest and the graphics stack in the host). That said, there's no denying that your use case is relatively special, so a more specialized solution which preserves some GLES API calls might provide significantly better performance. On the other hand, Gallium3D should facilitate covering more APIs, e.g. right now OpenVG and a few video APIs are implemented on top of Gallium3D. No idea if that's of any concern for you though. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
- Original Message - On Die, 2012-03-06 at 05:11 -0800, Benoit Jacob wrote: That said, there's no denying that your use case is relatively special, so a more specialized solution which preserves some GLES API calls might provide significantly better performance. On the other hand, Gallium3D should facilitate covering more APIs, e.g. right now OpenVG and a few video APIs are implemented on top of Gallium3D. No idea if that's of any concern for you though. The goal is to help port real-world applications such as games. Besides OpenGL [ES], the other API that is widely used in the real world is Direct3D (9 and 10), so that's what would be the most interesting. I've heard about a Direct3D implementation on top of Gallium3D but don't know its status. Benoit -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
On Mon, 5 Mar 2012 19:41:14 -0800 (PST), Benoit Jacob bja...@mozilla.com wrote: For a bunch of it, apps don't use it so nobody would notice. glBitmap and glDrawPixels are reasonably popular, though. You should be able to build those with shaders, though. You can see partial implementations for these in on top of fixed function in Mesa as src/mesa/drivers/common/meta.c (contributions welcome, particularly in the form of GLSL-based implementations of them!) Thanks for the pointer but that (a GLES2-based implementation) is precisely what we're looking for :-) I was mostly thinking in terms of how to set up state, which I find to be the hard part of writing the metaops -- converting the ff fragment shading to GLSL should be pretty easy, since if it can be written in fixed function it's usually trivial. I want to do the GLSL conversions of them some day, since it would be less overhead for us, but it's low on the task list. Before we'd start caring about glBitmap and glDrawPixels, we have more fundamental things to implement: - glBegin ... glVertex ... glEnd The src/mesa/vbo module handles this (the driver ends up with a callback to draw a number of primitives with a particular collection of VBOs, using the state that the driver had already been told about) and that plus src/mesa/main/dlist.c handle display lists. That's actually a huge component, and probably justifies making a Mesa driver out of this thing. - glShadeModel(GL_FLAT) (this one seems really hard to do with OpenGL ES2, a real capability regression from OpenGL [ES] 1 it seems!) Ouch. I keep trying to come up with workarounds for this, but I'm ending up with things that use even later GL functionality. Rewrite your VBOs, I guess, but that gets really awful in the case of vertex shading. - the lighting model (glLight, glMaterial) The code we have for doing this in src/mesa/main/ff_fragment_shader.cpp and src/mesa/main/ffvertex_prog.c generate IRs, not GLSL source. This sounds like another argument for making a Mesa driver and glueing Aras's stuff onto the backend, since that consumes our IR as the input. (You may note that ffvertex_prog.c doesn't generate GLSL IR, it generates Mesa IR. That's on the list of tasks for changing this quarter) pgpB75nyWqujP.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
- Original Message - On Mon, 5 Mar 2012 19:41:14 -0800 (PST), Benoit Jacob bja...@mozilla.com wrote: For a bunch of it, apps don't use it so nobody would notice. glBitmap and glDrawPixels are reasonably popular, though. You should be able to build those with shaders, though. You can see partial implementations for these in on top of fixed function in Mesa as src/mesa/drivers/common/meta.c (contributions welcome, particularly in the form of GLSL-based implementations of them!) Thanks for the pointer but that (a GLES2-based implementation) is precisely what we're looking for :-) I was mostly thinking in terms of how to set up state, which I find to be the hard part of writing the metaops -- converting the ff fragment shading to GLSL should be pretty easy, since if it can be written in fixed function it's usually trivial. I want to do the GLSL conversions of them some day, since it would be less overhead for us, but it's low on the task list. Before we'd start caring about glBitmap and glDrawPixels, we have more fundamental things to implement: - glBegin ... glVertex ... glEnd The src/mesa/vbo module handles this (the driver ends up with a callback to draw a number of primitives with a particular collection of VBOs, using the state that the driver had already been told about) and that plus src/mesa/main/dlist.c handle display lists. That's actually a huge component, and probably justifies making a Mesa driver out of this thing. Many thanks, that is super helpful. - glShadeModel(GL_FLAT) (this one seems really hard to do with OpenGL ES2, a real capability regression from OpenGL [ES] 1 it seems!) Ouch. I keep trying to come up with workarounds for this, but I'm ending up with things that use even later GL functionality. Rewrite your VBOs, I guess, but that gets really awful in the case of vertex shading. About glShadeModel(GL_FLAT), rewriting VBOs if of course what I would like to avoid; the biggest hope I've had was from this page, suggesting implementing it using OES_standard_derivatives (which is already widely available as a WebGL extension): http://athile.net/library/blog/?p=970 I would like to understand: when Mesa uses Gallium3D, at what level is glShadeModel(GL_FLAT) handled? Is the VBO rewritten before it hits Gallium3D, or does Gallium3D accept flat shading (which would mean that implementing a Gallium3D driver targeting WebGL would require us to handle glShadeModel(GL_FLAT) ourselves)? - the lighting model (glLight, glMaterial) The code we have for doing this in src/mesa/main/ff_fragment_shader.cpp and src/mesa/main/ffvertex_prog.c generate IRs, not GLSL source. This sounds like another argument for making a Mesa driver and glueing Aras's stuff onto the backend, since that consumes our IR as the input. (You may note that ffvertex_prog.c doesn't generate GLSL IR, it generates Mesa IR. That's on the list of tasks for changing this quarter) Many thanks again for all the pointers. Benoit ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: handle gl_PointCoord for Gen4 and Gen5 platforms
On Mon, 27 Feb 2012 15:46:32 +0800, Yuanhan Liu yuanhan@linux.intel.com
wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
b/src/mesa/drivers/dri/i965/brw_sf.c
index 6e63583..7950c47 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -125,6 +135,7 @@ brw_upload_sf_prog(struct brw_context *brw)
{
struct gl_context *ctx = brw-intel.ctx;
struct brw_sf_prog_key key;
There should be a /* _NEW_BUFFERS */ comment here to note the state flag
dependency.
+ bool render_to_fbo = ctx-DrawBuffer-Name != 0;
Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
pgpyenFytQOyB.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i915: move the FALLBACK_DRAW_OFFSET check outside the drawing rect check
On Tue, 6 Mar 2012 14:40:32 +0800, Yuanhan Liu yuanhan@linux.intel.com
wrote:
We have to do fallback when the 'Clipped Drawing Rectangle X/Y Max'
exceed the hardware's limit no matter the drawing rectangle offset
changed or not.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46665
NOTE: This is a candidate for stable release branches.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/drivers/dri/i915/i915_vtbl.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index 11e8a35..e78dbc8 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -665,12 +665,11 @@ i915_set_draw_region(struct intel_context *intel,
draw_offset = (draw_y 16) | draw_x;
+ FALLBACK(intel, I915_FALLBACK_DRAW_OFFSET,
+(ctx-DrawBuffer-Width + draw_x 2048) ||
+(ctx-DrawBuffer-Height + draw_y 2048));
/* When changing drawing rectangle offset, an MI_FLUSH is first required.
*/
if (draw_offset != i915-last_draw_offset) {
- FALLBACK(intel, I915_FALLBACK_DRAW_OFFSET,
- (ctx-DrawBuffer-Width + draw_x 2048) ||
- (ctx-DrawBuffer-Height + draw_y 2048));
-
state-Buffer[I915_DESTREG_DRAWRECT0] = MI_FLUSH |
INHIBIT_FLUSH_RENDER_CACHE;
i915-last_draw_offset = draw_offset;
} else
Reviewed-by: Eric Anholt e...@anholt.net
pgpzYROJ2DPzj.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: Pass in a MCRegisterInfo to MCInstPrinter on llvm-3.1.
On 03/05/2012 11:08 PM, Vinson Lee wrote:
llvm-3.1svn r152043 changes createMCInstPrinter to take an additional
MCRegisterInfo argument.
Signed-off-by: Vinson Leev...@freedesktop.org
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
index 11209da..b6849cb 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
@@ -243,7 +243,18 @@ lp_disassemble(const void* func)
int AsmPrinterVariant = AsmInfo-getAssemblerDialect();
#endif
-#if HAVE_LLVM= 0x0300
+#if HAVE_LLVM= 0x0301
+ OwningPtrconst MCRegisterInfo MRI(T-createMCRegInfo(Triple));
+ if (!MRI) {
+ debug_printf(error: no register info for target %s\n, Triple.c_str());
+ return;
+ }
+#endif
+
+#if HAVE_LLVM= 0x0301
+ OwningPtrMCInstPrinter Printer(
+ T-createMCInstPrinter(AsmPrinterVariant, *AsmInfo, *MRI, *STI));
+#elif HAVE_LLVM == 0x0300
OwningPtrMCInstPrinter Printer(
T-createMCInstPrinter(AsmPrinterVariant, *AsmInfo, *STI));
#elif HAVE_LLVM= 0x0208
Looks OK to me. Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Missing copyright header in dri/common/dri_util.c
On 03/06/2012 02:15 AM, Tomasz Kowal wrote: Would it be possible to add missing copyrights to dri_util.c? The oldest git commits for dri_util.c are from 2004, committed by Ian. Ian, would copying the blurb from utils.c be OK? /* * (C) Copyright IBM Corporation 2002, 2004 * All Rights Reserved. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the Software), * to deal in the Software without restriction, including without limitation * on the rights to use, copy, modify, merge, publish, distribute, sub * license, and/or sell copies of the Software, and to permit persons to whom * the Software is furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice (including the next * paragraph) shall be included in all copies or substantial portions of the * Software. * * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL * VA LINUX SYSTEM, IBM AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM, * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE * USE OR OTHER DEALINGS IN THE SOFTWARE. */ We could replace VA LINUX SYSTEM, IBM with THE AUTHORS. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: handle array textures in strip_texture_border()
On 03/05/2012 08:42 PM, Anuj Phogat wrote:
On Wed 29 Feb 2012 07:36:21 PM PST, Brian Paul wrote:
If the texture is a 1D array, don't remove the border pixel from the
height. Similarly for 2D array textures and the depth direction.
Simplify the function by assuming the border is always one pixel.
---
src/mesa/main/teximage.c | 37 -
1 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 4fb81e6..29d1d36 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -2422,7 +2422,7 @@ _mesa_choose_texture_format(struct gl_context *ctx,
/**
* Adjust pixel unpack params and image dimensions to strip off the
- * texture border.
+ * one-pixel texture border.
*
* Gallium and intel don't support texture borders. They've seldem been used
* and seldom been implemented correctly anyway.
@@ -2430,34 +2430,37 @@ _mesa_choose_texture_format(struct gl_context *ctx,
* \param unpackNew returns the new pixel unpack parameters
*/
static void
-strip_texture_border(GLint *border,
+strip_texture_border(GLenum target,
GLint *width, GLint *height, GLint *depth,
const struct gl_pixelstore_attrib *unpack,
struct gl_pixelstore_attrib *unpackNew)
{
- assert(*border 0); /* sanity check */
+ assert(width);
+ assert(height);
+ assert(depth);
*unpackNew = *unpack;
if (unpackNew-RowLength == 0)
unpackNew-RowLength = *width;
- if (depth unpackNew-ImageHeight == 0)
+ if (unpackNew-ImageHeight == 0)
unpackNew-ImageHeight = *height;
- unpackNew-SkipPixels += *border;
- if (height)
- unpackNew-SkipRows += *border;
- if (depth)
- unpackNew-SkipImages += *border;
-
assert(*width= 3);
- *width = *width - 2 * *border;
- if (height *height= 3)
- *height = *height - 2 * *border;
- if (depth *depth= 3)
- *depth = *depth - 2 * *border;
- *border = 0;
+ unpackNew-SkipPixels++; /* skip the border */
+ *width = *width - 2; /* reduce the width by two border pixels */
+
+ /* The min height of a texture with a border is 3 */
+ if (*height= 3 target != GL_TEXTURE_1D_ARRAY) {
+ unpackNew-SkipRows++; /* skip the border */
+ *height = *height - 2; /* reduce the height by two border pixels */
+ }
+
+ if (*depth= 3 target != GL_TEXTURE_2D_ARRAY) {
+ unpackNew-SkipImages++; /* skip the border */
+ *depth = *depth - 2; /* reduce the depth by two border pixels */
+ }
}
/**
@@ -2542,7 +2545,7 @@ teximage(struct gl_context *ctx, GLuint dims,
* rarely-tested software fallback rendering.
*/
if (border ctx-Const.StripTextureBorder) {
-strip_texture_border(border,width,height,depth, unpack,
+strip_texture_border(target,width,height,depth, unpack,
unpack_no_border);
border value should be set to zero after this call.
Yes, the caller to the strip() function should set border=0.
I'm getting
assertion failure in piglit
texture-border test (under review) without that:
texture-border: intel_tex.c:64: intel_alloc_texture_image_buffer:
Assertion `image-Border == 0' failed.
unpack =unpack_no_border;
}
Apart from above issue this patch looks cleaner than mine.
After above fix this patch is:
Reviewed-by: Anuj Phogatanuj.pho...@gmail.com
Thanks. I'll commit this later.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 46815] Build fails with byacc and configuration script succeeds
https://bugs.freedesktop.org/show_bug.cgi?id=46815 --- Comment #1 from Kenneth Graunke kenn...@whitecape.org 2012-03-06 09:53:33 PST --- Bison is definitely required, so yes, configure ought to detect that and fail. We should fix that. -- 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 2/3] gtest: Build as a convenience library.
On 03/06/2012 10:47 AM, Kenneth Graunke wrote: On 03/05/2012 05:01 PM, Eric Anholt wrote: --- configure.ac | 1 + src/gtest/.gitignore | 5 + src/gtest/Makefile.am | 38 ++ 3 files changed, 44 insertions(+), 0 deletions(-) create mode 100644 src/gtest/.gitignore create mode 100644 src/gtest/Makefile.am Presumably the PATCH 1/3 that seems to be missing from my inbox is Import the Google Test Framework into Mesa's git repository. The msg is held by moderation for being too large (~340KB). I can let it through... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gtest: Import sources from gtest 1.6.0.
On 03/05/2012 05:01 PM, Eric Anholt wrote: The upstream of gtest has decided that the intended usage model is for projects to import the source and use it, which is reflected in their recent removal of the gtest-config tool. You've got to be kidding me :( But you're right: http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog I'm still not a fan, but it sounds like we don't have a choice. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
On Tue, Mar 6, 2012 at 6:41 AM, Michel Dänzer mic...@daenzer.net wrote: On Die, 2012-03-06 at 05:11 -0800, Benoit Jacob wrote: For a bunch of it, apps don't use it so nobody would notice. glBitmap and glDrawPixels are reasonably popular, though. You should be able to build those with shaders, though. You can see partial implementations for these in on top of fixed function in Mesa as src/mesa/drivers/common/meta.c (contributions welcome, particularly in the form of GLSL-based implementations of them!) Thanks for the pointer but that (a GLES2-based implementation) is precisely what we're looking for :-) Before we'd start caring about glBitmap and glDrawPixels, we have more fundamental things to implement: - glBegin ... glVertex ... glEnd - glShadeModel(GL_FLAT) (this one seems really hard to do with OpenGL ES2, a real capability regression from OpenGL [ES] 1 it seems!) - display lists - the lighting model (glLight, glMaterial) Does Mesa have code that could be reused to implement some of that on top of ES2? I suspect you're thinking of the Gallium3D framework, and I think it could indeed be useful for this. Hah, OK. That makes sense. Basically, you should only need to write: * A core Gallium3D driver (src/gallium/drivers/.../) which translates shaders from TGSI to GLSL (should be trivial at least for a first pass) and Gallium3D state to GLES / WebGL state calls. * Possibly some environment glue code (src/gallium/winsys/.../). * Target glue code (src/gallium/targets/.../). The parts which translate from OpenGL/GLSL to Gallium3D/TGSI (src/mesa/state_tracker/) are shared between all Gallium3D drivers. Many thanks for the pointers! Do you think that the translation of Gallium3D state to GL state could be efficient (given that this is the converse of the primary use case, which is IIUC to convert GL state to Gallium3D state)? Just checking if this has a reasonable chance of performing well. It does. VMware uses Gallium3D for the guest drivers to achieve OpenGL hardware acceleration in virtual machines, and it performs well under presumably worse circumstances (there's a virtual machine barrier between the Gallium3D driver in the guest and the graphics stack in the host). Thanks for the information! If that approach is fast enough for VMWare to run games with, then it sounds pretty good. I assume btw that that work is not open source? Would be nice if it were, it sounds like the closest thing to what we are doing here... That said, there's no denying that your use case is relatively special, so a more specialized solution which preserves some GLES API calls might provide significantly better performance. On the other hand, Gallium3D should facilitate covering more APIs, e.g. right now OpenVG and a few video APIs are implemented on top of Gallium3D. No idea if that's of any concern for you though. The additional APIs are not currently important, but might be in the future, the more compatibility the better. I'm still processing all this information, but it seems that optimally, both a Gallium3D and a specialized approach make sense. The Gallium3D way would give maximal compatibility while the specialized approach would have less overhead but only work on a limited subset that we define as we go. However, the question is whether we have the resources to follow both approaches, if not, we would need to pick one I guess.. Best, Alon Zakai ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nouveau_vieux: don't use nested functions
nobled nob...@dreamwidth.org writes:
It's a GNU extension that isn't supported by clang right now:
http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Nested-Functions.html
http://clang.llvm.org/docs/UsersManual.html#c_unimpl_gcc
With this, clang now compiles the nouveau classic driver.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44061
(Types changed from e.g. 'unsigned char' to 'GLubyte' so that the types can
be concatenated to form a unique function name without any whitespace
interfering.)
I'm not especially fond of uglifying the code to work around a compiler
deficiency... Anyway... I've pushed your patch with a minor change
giving more meaningful names to the dispatch functions.
Thanks.
---
src/mesa/drivers/dri/nouveau/nouveau_array.c| 67
++-
src/mesa/drivers/dri/nouveau/nouveau_render_t.c | 67
+++
2 files changed, 73 insertions(+), 61 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_array.c
b/src/mesa/drivers/dri/nouveau/nouveau_array.c
index 17e6d16..d9253b0 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_array.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_array.c
@@ -29,54 +29,71 @@
#include nouveau_array.h
#include nouveau_bufferobj.h
+#define EXTRACT(in_t, out_t) extract_func_##in_t##_to_##out_t
+
+#define EXTRACT_FUNC(in_t, out_t, k) \
+static out_t EXTRACT(in_t, out_t)\
+(struct nouveau_array *a, int i, int j) {\
+ in_t x = ((in_t *)(a-buf + i * a-stride))[j]; \
+ \
+ return (out_t)x / (k); \
+}
+
+EXTRACT_FUNC(GLchar, unsigned, 1);
+EXTRACT_FUNC(GLchar, float, SCHAR_MAX);
+EXTRACT_FUNC(GLubyte, unsigned, 1);
+EXTRACT_FUNC(GLubyte, float, UCHAR_MAX);
+EXTRACT_FUNC(GLshort, unsigned, 1);
+EXTRACT_FUNC(GLshort, float, SHRT_MAX);
+EXTRACT_FUNC(GLushort, unsigned, 1);
+EXTRACT_FUNC(GLushort, float, USHRT_MAX);
+EXTRACT_FUNC(GLint, unsigned, 1);
+EXTRACT_FUNC(GLint, float, INT_MAX);
+EXTRACT_FUNC(GLuint, unsigned, 1);
+EXTRACT_FUNC(GLuint, float, UINT_MAX);
+EXTRACT_FUNC(GLfloat, unsigned, 1.0 / UINT_MAX);
+EXTRACT_FUNC(GLfloat, float, 1);
+
+#undef EXTRACT_FUNC
+
static void
get_array_extract(struct nouveau_array *a, extract_u_t *extract_u,
extract_f_t *extract_f)
{
-#define EXTRACT(in_t, out_t, k)
\
- ({ \
- auto out_t f(struct nouveau_array *, int, int); \
- out_t f(struct nouveau_array *a, int i, int j) {\
- in_t x = ((in_t *)(a-buf + i * a-stride))[j]; \
- \
- return (out_t)x / (k); \
- }; \
- f; \
- });
-
switch (a-type) {
case GL_BYTE:
- *extract_u = EXTRACT(char, unsigned, 1);
- *extract_f = EXTRACT(char, float, SCHAR_MAX);
+ *extract_u = EXTRACT(GLchar, unsigned);
+ *extract_f = EXTRACT(GLchar, float);
break;
case GL_UNSIGNED_BYTE:
- *extract_u = EXTRACT(unsigned char, unsigned, 1);
- *extract_f = EXTRACT(unsigned char, float, UCHAR_MAX);
+ *extract_u = EXTRACT(GLubyte, unsigned);
+ *extract_f = EXTRACT(GLubyte, float);
break;
case GL_SHORT:
- *extract_u = EXTRACT(short, unsigned, 1);
- *extract_f = EXTRACT(short, float, SHRT_MAX);
+ *extract_u = EXTRACT(GLshort, unsigned);
+ *extract_f = EXTRACT(GLshort, float);
break;
case GL_UNSIGNED_SHORT:
- *extract_u = EXTRACT(unsigned short, unsigned, 1);
- *extract_f = EXTRACT(unsigned short, float, USHRT_MAX);
+ *extract_u = EXTRACT(GLushort, unsigned);
+ *extract_f = EXTRACT(GLushort, float);
break;
case GL_INT:
- *extract_u = EXTRACT(int, unsigned, 1);
- *extract_f = EXTRACT(int, float, INT_MAX);
+ *extract_u = EXTRACT(GLint, unsigned);
+ *extract_f = EXTRACT(GLint, float);
break;
case GL_UNSIGNED_INT:
- *extract_u = EXTRACT(unsigned int, unsigned, 1);
- *extract_f = EXTRACT(unsigned int, float, UINT_MAX);
+ *extract_u = EXTRACT(GLuint, unsigned);
+ *extract_f = EXTRACT(GLuint, float);
break;
case GL_FLOAT:
- *extract_u = EXTRACT(float, unsigned, 1.0 / UINT_MAX);
- *extract_f = EXTRACT(float, float, 1);
+ *extract_u = EXTRACT(GLfloat, unsigned);
+
Re: [Mesa-dev] [PATCH 1/3] gtest: Import sources from gtest 1.6.0.
On Tue, 06 Mar 2012 10:26:58 -0800, Kenneth Graunke kenn...@whitecape.org wrote: On 03/05/2012 05:01 PM, Eric Anholt wrote: The upstream of gtest has decided that the intended usage model is for projects to import the source and use it, which is reflected in their recent removal of the gtest-config tool. You've got to be kidding me :( But you're right: http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog I'm still not a fan, but it sounds like we don't have a choice. The ODR also sounds like a reason that LLVM would be trying to force compiler flags on users of llvm-config. pgprGpSAgWsTr.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] i965: Turn the INTEL_FORCE_GS env var into a driconf option.
--- src/mesa/drivers/dri/i965/brw_context.c |1 + src/mesa/drivers/dri/i965/brw_context.h |3 +++ src/mesa/drivers/dri/i965/brw_gs.c|3 +-- src/mesa/drivers/dri/intel/intel_screen.c |6 +- 4 files changed, 10 insertions(+), 3 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index 65de260..30db5b4 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -313,6 +313,7 @@ brwCreateContext(int api, brw_draw_init( brw ); brw-precompile = driQueryOptionb(intel-optionCache, shader_precompile); + brw-gs.force_enable = driQueryOptionb(intel-optionCache, force_gs); ctx-Const.NativeIntegers = true; ctx-Const.UniformBooleanTrue = 1; diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h index a16145b..507720d 100644 --- a/src/mesa/drivers/dri/i965/brw_context.h +++ b/src/mesa/drivers/dri/i965/brw_context.h @@ -865,6 +865,9 @@ struct brw_context struct brw_gs_prog_data *prog_data; bool prog_active; + /** Debug option to always enable a passthrough GS program */ + bool force_enable; + /** Offset in the program cache to the CLIP program pre-gen6 */ uint32_t prog_offset; uint32_t state_offset; diff --git a/src/mesa/drivers/dri/i965/brw_gs.c b/src/mesa/drivers/dri/i965/brw_gs.c index bfca169..cbcd31f 100644 --- a/src/mesa/drivers/dri/i965/brw_gs.c +++ b/src/mesa/drivers/dri/i965/brw_gs.c @@ -234,8 +234,7 @@ static void populate_key( struct brw_context *brw, /* For testing, the environment variable INTEL_FORCE_GS can be used to * force a GS program to be used, even if it's not necessary. */ - if (getenv(INTEL_FORCE_GS)) - key-need_gs_prog = true; + key-need_gs_prog = brw-gs.force_enable; } /* Calculate interpolants for triangle and line rasterization. diff --git a/src/mesa/drivers/dri/intel/intel_screen.c b/src/mesa/drivers/dri/intel/intel_screen.c index 48762d0..39c9fb4 100644 --- a/src/mesa/drivers/dri/intel/intel_screen.c +++ b/src/mesa/drivers/dri/intel/intel_screen.c @@ -83,10 +83,14 @@ PUBLIC const char __driConfigOptions[] = DRI_CONF_OPT_BEGIN(shader_precompile, bool, false) DRI_CONF_DESC(en, Perform code generation at shader link time.) DRI_CONF_OPT_END + + DRI_CONF_OPT_BEGIN(force_gs, bool, false) +DRI_CONF_DESC(en, Always use a passthrough GS program on gen4/5.) + DRI_CONF_OPT_END DRI_CONF_SECTION_END DRI_CONF_END; -const GLuint __driNConfigOptions = 13; +const GLuint __driNConfigOptions = 14; #include intel_batchbuffer.h #include intel_buffers.h -- 1.7.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/7] intel: Skip looking at driver debug flags when setuid.
The idea is that when the driver is loaded by the setuid root X
Server, you don't want the driver debug flags to apply in case they
can be used for nefarious purposes.
---
src/mesa/drivers/dri/intel/intel_context.c |6 +-
src/mesa/drivers/dri/intel/intel_screen.c | 20 +++-
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 3101ef2..174cf88 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -25,6 +25,7 @@
*
**/
+#include unistd.h
#include main/glheader.h
#include main/context.h
@@ -728,7 +729,10 @@ intelInitContext(struct intel_context *intel,
break;
}
- INTEL_DEBUG = driParseDebugString(getenv(INTEL_DEBUG), debug_control);
+ if (geteuid() == getuid()) {
+ INTEL_DEBUG = driParseDebugString(getenv(INTEL_DEBUG), debug_control);
+ }
+
if (INTEL_DEBUG DEBUG_BUFMGR)
dri_bufmgr_set_debug(intel-bufmgr, true);
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index d477aaf..8b5fb5a 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -25,6 +25,7 @@
*
**/
+#include unistd.h
#include errno.h
#include main/glheader.h
#include main/context.h
@@ -600,8 +601,12 @@ intel_init_bufmgr(struct intel_screen *intelScreen)
__DRIscreen *spriv = intelScreen-driScrnPriv;
int num_fences = 0;
- intelScreen-no_hw = (getenv(INTEL_NO_HW) != NULL ||
-getenv(INTEL_DEVID_OVERRIDE) != NULL);
+ if (geteuid() != getuid()) {
+ intelScreen-no_hw = false;
+ } else {
+ intelScreen-no_hw = (getenv(INTEL_NO_HW) != NULL ||
+ getenv(INTEL_DEVID_OVERRIDE) != NULL);
+ }
intelScreen-bufmgr = intel_bufmgr_gem_init(spriv-fd, BATCH_SZ);
if (intelScreen-bufmgr == NULL) {
@@ -638,6 +643,9 @@ intel_init_bufmgr(struct intel_screen *intelScreen)
static void
intel_override_separate_stencil(struct intel_screen *screen)
{
+ if (geteuid() != getuid())
+ return;
+
const char *s = getenv(INTEL_SEPARATE_STENCIL);
if (!s) {
return;
@@ -721,9 +729,11 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
* This implies INTEL_NO_HW, to avoid programming your actual GPU
* incorrectly.
*/
- devid_override = getenv(INTEL_DEVID_OVERRIDE);
- if (devid_override) {
- intelScreen-deviceID = strtod(devid_override, NULL);
+ if (geteuid() == getuid()) {
+ devid_override = getenv(INTEL_DEVID_OVERRIDE);
+ if (devid_override) {
+intelScreen-deviceID = strtod(devid_override, NULL);
+ }
}
intelScreen-kernel_has_gen7_sol_reset =
--
1.7.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] intel: Drop the INTEL_NO_BLIT debug environment variable.
This was added in the i915/i965 merge from the i915 driver, but I
don't recall it ever being used since then.
---
src/mesa/drivers/dri/intel/intel_pixel.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_pixel.c
b/src/mesa/drivers/dri/intel/intel_pixel.c
index eeafe22..bc70510 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel.c
@@ -159,11 +159,9 @@ void
intelInitPixelFuncs(struct dd_function_table *functions)
{
functions-Accum = _mesa_accum;
- if (!getenv(INTEL_NO_BLIT)) {
- functions-Bitmap = intelBitmap;
- functions-CopyPixels = intelCopyPixels;
- functions-DrawPixels = intelDrawPixels;
- }
+ functions-Bitmap = intelBitmap;
+ functions-CopyPixels = intelCopyPixels;
+ functions-DrawPixels = intelDrawPixels;
functions-ReadPixels = intelReadPixels;
}
--
1.7.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] dri: Disable user-specified driconf options when in a setuid environment.
A user (for example, without DRI priveleges) should not be able to
modify the behavior of the X Server's AIGLX driver.
---
src/mesa/drivers/dri/common/xmlconfig.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
b/src/mesa/drivers/dri/common/xmlconfig.c
index 6d1d5ec..9248cc8 100644
--- a/src/mesa/drivers/dri/common/xmlconfig.c
+++ b/src/mesa/drivers/dri/common/xmlconfig.c
@@ -580,7 +580,11 @@ static void parseOptInfoAttr (struct OptInfoData *data,
const XML_Char **attr) {
else
XML_FATAL (illegal type in option: %s., attrVal[OA_TYPE]);
-defaultVal = getenv (cache-info[opt].name);
+if (geteuid() == getuid())
+ defaultVal = getenv (cache-info[opt].name);
+else
+ defaultVal = NULL;
+
if (defaultVal != NULL) {
/* don't use XML_WARNING, we want the user to see this! */
fprintf (stderr,
@@ -813,7 +817,7 @@ static void parseOptConfAttr (struct OptConfData *data,
const XML_Char **attr) {
GLuint opt = findOption (cache, name);
if (cache-info[opt].name == NULL)
XML_WARNING (undefined option: %s., name);
- else if (getenv (cache-info[opt].name))
+ else if (geteuid() == getuid() getenv (cache-info[opt].name))
/* don't use XML_WARNING, we want the user to see this! */
fprintf (stderr, ATTENTION: option value of option %s ignored.\n,
cache-info[opt].name);
@@ -957,7 +961,7 @@ void driParseConfigFiles (driOptionCache *cache, const
driOptionCache *info,
userData.driverName = driverName;
userData.execName = GET_PROGRAM_NAME();
-if ((home = getenv (HOME))) {
+if (geteuid() == getuid() (home = getenv (HOME))) {
GLuint len = strlen (home);
filenames[1] = MALLOC (len + 7+1);
if (filenames[1] == NULL)
--
1.7.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] intel: Drop the INTEL_STRICT_CONFORMANCE environment variable.
If you want to test the graphics driver, you want to test it under the
conditions that users will see, not some set of additional fallbacks.
If you want to test swrast, run the swrast driver (or no_rast=true)
instead.
---
src/mesa/drivers/dri/i915/intel_tris.c | 12 +-
src/mesa/drivers/dri/intel/intel_context.c | 32 ---
src/mesa/drivers/dri/intel/intel_context.h |6 -
3 files changed, 6 insertions(+), 44 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c
b/src/mesa/drivers/dri/i915/intel_tris.c
index a36011a..c802d72 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -944,7 +944,7 @@ intelFastRenderClippedPoly(struct gl_context * ctx, const
GLuint * elts, GLuint
-#define ANY_FALLBACK_FLAGS (DD_LINE_STIPPLE | DD_TRI_STIPPLE | DD_POINT_ATTEN
| DD_POINT_SMOOTH | DD_TRI_SMOOTH)
+#define ANY_FALLBACK_FLAGS (DD_LINE_STIPPLE | DD_TRI_STIPPLE | DD_POINT_ATTEN)
#define ANY_RASTER_FLAGS (DD_TRI_LIGHT_TWOSIDE | DD_TRI_OFFSET |
DD_TRI_UNFILLED)
void
@@ -995,11 +995,6 @@ intelChooseRenderState(struct gl_context * ctx)
if ((flags DD_TRI_STIPPLE) !intel-hw_stipple)
intel-draw_tri = intel_fallback_tri;
- if (flags DD_TRI_SMOOTH) {
- if (intel-conformance_mode 0)
- intel-draw_tri = intel_fallback_tri;
-}
-
if (flags DD_POINT_ATTEN) {
if (0)
intel-draw_point = intel_atten_point;
@@ -1007,11 +1002,6 @@ intelChooseRenderState(struct gl_context * ctx)
intel-draw_point = intel_fallback_point;
}
-if (flags DD_POINT_SMOOTH) {
- if (intel-conformance_mode 0)
- intel-draw_point = intel_fallback_point;
-}
-
index |= INTEL_FALLBACK_BIT;
}
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 7b2bdad..5432fb1 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -652,33 +652,11 @@ intelInitContext(struct intel_context *intel,
break;
}
- /* This doesn't yet catch all non-conformant rendering, but it's a
-* start.
-*/
- if (getenv(INTEL_STRICT_CONFORMANCE)) {
- unsigned int value = atoi(getenv(INTEL_STRICT_CONFORMANCE));
- if (value 0) {
- intel-conformance_mode = value;
- }
- else {
- intel-conformance_mode = 1;
- }
- }
-
- if (intel-conformance_mode 0) {
- ctx-Const.MinLineWidth = 1.0;
- ctx-Const.MinLineWidthAA = 1.0;
- ctx-Const.MaxLineWidth = 1.0;
- ctx-Const.MaxLineWidthAA = 1.0;
- ctx-Const.LineWidthGranularity = 1.0;
- }
- else {
- ctx-Const.MinLineWidth = 1.0;
- ctx-Const.MinLineWidthAA = 1.0;
- ctx-Const.MaxLineWidth = 5.0;
- ctx-Const.MaxLineWidthAA = 5.0;
- ctx-Const.LineWidthGranularity = 0.5;
- }
+ ctx-Const.MinLineWidth = 1.0;
+ ctx-Const.MinLineWidthAA = 1.0;
+ ctx-Const.MaxLineWidth = 5.0;
+ ctx-Const.MaxLineWidthAA = 5.0;
+ ctx-Const.LineWidthGranularity = 0.5;
ctx-Const.MinPointSize = 1.0;
ctx-Const.MinPointSizeAA = 1.0;
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index ef024b1..041a4fc 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -289,12 +289,6 @@ struct intel_context
bool always_flush_batch;
bool always_flush_cache;
- /* 0 - nonconformant, best performance;
-* 1 - fallback to sw for known conformance bugs
-* 2 - always fallback to sw
-*/
- GLuint conformance_mode;
-
/* State for intelvb.c and inteltris.c.
*/
GLuint RenderIndex;
--
1.7.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/7] mesa: Skip looking at debug environment variables when setuid.
When a driver is loaded by the setuid root X Server, you don't want
the debug flags to apply in case they can be used for nefarious
purposes.
---
src/mesa/main/imports.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 82713a1..f371c7a 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -49,6 +49,7 @@
#include mtypes.h
#include version.h
+#include unistd.h
#ifdef _GNU_SOURCE
#include locale.h
#ifdef __APPLE__
@@ -726,6 +727,9 @@ _mesa_bsearch( const void *key, const void *base, size_t
nmemb, size_t size,
char *
_mesa_getenv( const char *var )
{
+ if (geteuid() != getuid())
+ return NULL;
+
#if defined(_XBOX) || defined(_WIN32_WCE)
return NULL;
#else
--
1.7.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: Also put a symlink from libGL.so in lib/ for now.
On Sat, Mar 3, 2012 at 09:11, Johannes Obermayr johannesoberm...@gmx.de wrote: This fixes the libGLU.so.* build when a system libGL.so is not present since it is relying on the lib/ to build against until it gets converted to automake. --- src/glx/Makefile.am | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am index b5bbebd..79dc405 100644 --- a/src/glx/Makefile.am +++ b/src/glx/Makefile.am @@ -116,6 +116,7 @@ if !HAVE_MANGLED_GL all-local: $(NORMAL_GL_LIB) $(MANGLED_GL_LIB) $(MKDIR_P) $(top_builddir)/$(LIB_DIR); ln -f .libs/libGL.so.1.2.0 $(top_builddir)/$(LIB_DIR)/libGL.so.1 + ln -sf libGL.so.1 $(top_builddir)/$(LIB_DIR)/libGL.so endif $(GLAPI_LIB): -- 1.7.7 Tested-by: Stéphane Marchesin marc...@chromium.org Reviewed-by: Stéphane Marchesin marc...@chromium.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/7] i965: Change the hiz-override env var to a driconf option.
On 03/06/2012 02:57 PM, Eric Anholt wrote: The force-enable option is dropped, now that the hardware we were concerned about has HiZ on by default. Now, instead of doing INTEL_HIZ=0 to test disabling hiz, you can set hiz=false. --- src/mesa/drivers/dri/intel/intel_context.c |5 +++- src/mesa/drivers/dri/intel/intel_screen.c | 31 --- src/mesa/drivers/dri/intel/intel_screen.h |1 - 3 files changed, 9 insertions(+), 28 deletions(-) On gen6, if we set intel_context::has_hiz = false, then we need to set has_separate_stencil = false too, just to be safe. Fixing this also affects patch 5/7. Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 47028] New: EGL: (r300) weston crashes in libEGL.so - bisected
https://bugs.freedesktop.org/show_bug.cgi?id=47028 Bug #: 47028 Summary: EGL: (r300) weston crashes in libEGL.so - bisected Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: ore...@gmail.com Created attachment 58099 -- https://bugs.freedesktop.org/attachment.cgi?id=58099 weston crash weston crashes when trying to start with drm. Attached is the bt. I bisected with the following result: e5f895485e03ac60efcb3f6f83ec1d3e33ef7ec2 is the first bad commit commit e5f895485e03ac60efcb3f6f83ec1d3e33ef7ec2 Author: Eric Anholt e...@anholt.net Date: Mon Feb 6 12:12:53 2012 +0100 egl/drivers: Convert to automake. Reviewed-by: Kenneth Graunke kenn...@whitecape.org Thanks -- 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] i965: handle gl_PointCoord for Gen4 and Gen5 platforms
On Tue, Mar 06, 2012 at 08:25:10AM -0800, Eric Anholt wrote:
On Mon, 27 Feb 2012 15:46:32 +0800, Yuanhan Liu yuanhan@linux.intel.com
wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
b/src/mesa/drivers/dri/i965/brw_sf.c
index 6e63583..7950c47 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -125,6 +135,7 @@ brw_upload_sf_prog(struct brw_context *brw)
{
struct gl_context *ctx = brw-intel.ctx;
struct brw_sf_prog_key key;
There should be a /* _NEW_BUFFERS */ comment here to note the state flag
dependency.
Ok.
+ bool render_to_fbo = ctx-DrawBuffer-Name != 0;
Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
Thanks for the Reviewed-by, which I have been waiting for a quite while ;)
Thanks,
Yuanhan Liu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
