On Tue 22 Nov 2011 12:21:09 PM PST, Kenneth Graunke wrote:
On 11/22/2011 11:42 AM, Anuj Phogat wrote:
[snip]
  I agree. This is simpler to read and _mesa_is_cube_map_face() can be reused
  in mesa. Posting an updated patch with your suggestions.

  >  I haven't tested this so the logic might be incorrect.
  It worked as it is. Just defined a new function _mesa_is_cube_face().

Actually, Brian already added that function; it's in teximage.h.

I just realised that my mesa branch was not updated with git://anongit.freedesktop.org/mesa/mesa. _mesa_is_cube_face() do exist in teximage.h After fetching all the recent changes and installing libdrm 2.4.27, i am getting following error while building the mesa driver:

i830_state.c: In function ‘i830Enable’:
i830_state.c:851:51: error: ‘struct intel_renderbuffer’ has no member named ‘region’
gmake[6]: *** [i830_state.o] Error 1
gmake[6]: *** Waiting for unfinished jobs....
gmake[6]: Leaving directory `/home/anuj/projects/mesa/src/mesa/drivers/dri/i915'
gmake[5]: *** [lib] Error 2
gmake[5]: Leaving directory `/home/anuj/projects/mesa/src/mesa/drivers/dri/i915'
gmake[4]: *** [subdirs] Error 1
gmake[4]: Leaving directory `/home/anuj/projects/mesa/src/mesa/drivers/dri'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/home/anuj/projects/mesa/src/mesa/drivers'
gmake[2]: *** [driver_subdirs] Error 2
gmake[2]: Leaving directory `/home/anuj/projects/mesa/src/mesa'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/anuj/projects/mesa/src'
make: *** [default] Error 1

Is this a known issue or something specific to my system configuration?
-   /* additional checks for depth textures */
+
+  /* additional checks for depth textures */
     if (_mesa_base_tex_format(ctx, internalFormat) == GL_DEPTH_COMPONENT) {
-      /* Only 1D, 2D, rect and array textures supported, not 3D or cubes */
+     /* Only 1D, 2D, rect, array and cube textures supported, not 3D
+      * Cubemaps are only supported for GL version>  3.0 or with 
EXT_gpu_shader4 */
        if (target != GL_TEXTURE_1D&&
            target != GL_PROXY_TEXTURE_1D&&
            target != GL_TEXTURE_2D&&
-          target != GL_PROXY_TEXTURE_2D&&
-          target != GL_TEXTURE_1D_ARRAY&&
-          target != GL_PROXY_TEXTURE_1D_ARRAY&&
-          target != GL_TEXTURE_2D_ARRAY&&
            target != GL_PROXY_TEXTURE_2D_ARRAY&&
            target != GL_TEXTURE_RECTANGLE_ARB&&
-          target != GL_PROXY_TEXTURE_RECTANGLE_ARB) {
-         if (!isProxy)
-            _mesa_error(ctx, GL_INVALID_ENUM,
-                        "glTexImage(target/internalFormat)");
-         return GL_TRUE;
+          target != GL_PROXY_TEXTURE_RECTANGLE_ARB&&
+         !((_mesa_is_cube_map_face(target) || target == 
GL_PROXY_TEXTURE_CUBE_MAP)&&
+           (ctx->VersionMajor>= 3 || ctx->Extensions.EXT_gpu_shader4))) {
+        if (!isProxy)
+           _mesa_error(ctx, GL_INVALID_ENUM,
+                       "glTexImage(target/internalFormat)");
+        return GL_TRUE;
        }
     }

target != GL_PROXY_TEXTURE_2D&&
target != GL_TEXTURE_1D_ARRAY&&
target != GL_PROXY_TEXTURE_1D_ARRAY&&
target != GL_TEXTURE_2D_ARRAY&&
I deleted these 4 lines by mistake. I'll correct this in next patch.
-   /* additional checks for compressed textures */
+  /* additional checks for compressed textures */
     if (_mesa_is_compressed_format(ctx, internalFormat)) {
        if (!target_can_be_compressed(ctx, target, internalFormat)) {
           if (!isProxy)

Seems like some spurious whitespace changes got introduced here...this
isProxy stuff shouldn't be appearing in the diff.

Mesa coding style is 3-space indentation with 8-space tabs.  (Yeah, it's
quite unusual... :))

In vim I accomplish this via the following .vimrc line:
autocmd BufNewFile,BufRead /home/kwg/Projects/mesa/* set noexpandtab
tabstop=8 softtabstop=3 shiftwidth=3
I'm sure there are recipes for other editors.

Also, you might consider using git-send-email to send out your patches:

git send-email --to mesa-dev@lists.freedesktop.org --annotate HEAD~1..HEAD

...sends the top commit from your current branch to the list.  You can
change the HEAD~1 to send a whole series; --compose lets you write a
[PATCH 0/n] mail introducing the series if you like.

The nice thing about git-send-email is that recipients can save the
email as an mbox file (in Thunderbird, just right click and hit save)
and then use 'git am<file>' to apply the patch, committing it with the
proper commit message, authorship, etc.  It's really convenient.

Assuming the spurious hunks get dropped, this patch is
Reviewed-by: Kenneth Graunke<kenn...@whitecape.org>

Thanks!

Thanks for sharing the configuration for .vimrc. I'm already using git send-email for sending out the patches.

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to