Re: [Mesa-dev] [RFC] [PATCH 1/2] mesa: let GL3 buf obj queries not depend on opengl major version
On 09/19/2011 12:12 PM, Jose Fonseca wrote: - Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/19/2011 07:20 AM, Brian Paul wrote: On 09/19/2011 04:25 AM, Yuanhan Liu wrote: If I understand correctly, the new GL3 buffer object queries parameters, like BUFFER_MAP_ACCESS_FLAGS, depends on ARB_map_buffer_range extension. That would make sense, but in fact the extension spec (http://www.opengl.org/registry/specs/ARB/map_buffer_range.txt) says nothing about these queries. They were added in GL 3.0. It seems like this could be an error in the extension spec. This is one of the extensions, like ARB_framebuffer_object, that back ports OpenGL 3.0 functionality to previous versions. These extensions are supposed to provide *identical* functionality to OpenGL 3.0. The other cases of mismatches have been determined to be bugs in the extension specs. FWIW, this ability would be useful for GL debuggers such as apitrace. Otherwise the ARB_map_buffer_range extension is unbalanced: it adds new state that can never be queried. The question is, what do other implementations do? The other other question is, are there any implementations that support ARB_map_buffer_range but not OpenGL 3.0? Very good questions... The answer to the later question can be obtained by data mining openbenchmarking.org, by entering this query on google: site:openbenchmarking.org GL_ARB_map_buffer_range glxinfo OpenGL version string: 2.1 -mesa and there are a few NVIDIA cards / driver combinations out there that hit this: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 7900 GT/GTO/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 260.19.36 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro FX 3450/4000 SDI/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 195.36.31 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce Go 7400/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 270.29 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce Go 7900 GS/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 260.19.06 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 7600 GT/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 270.30 I have this card but an older version of the driver. It claims to support GL_ARB_map_buffer_range. Attached is my full output from `nvidia-settings -g`. OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 7600 GT/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 260.19.29 -- Chris If anybody had one of these, we could tell for sure. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev GLX Information for chocobot:0.0: direct rendering: Yes GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_ARB_get_proc_address server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_NV_present_video, GLX_NV_copy_image, GLX_NV_multisample_coverage, GLX_NV_video_capture, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 7600 GT/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 260.19.29 OpenGL extensions: GL_ARB_color_buffer_float, GL_ARB_copy_buffer, GL_ARB_depth_clamp, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_ES2_compatibility, GL_ARB_explicit_attrib_location, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_framebuffer_object, GL_ARB_half_float_pixel,
Re: [Mesa-dev] [PATCH 5/5] glsl: Clarify ir_function::matching_sigature()
On 07/29/2011 08:59 PM, Chad Versace wrote:
The function used a variable named 'score', which was an outright lie.
A signature matches or it doesn't; there is no fuzzy scoring.
Change the return type of parameter_lists_match() to an enum, and
let ir_function::matching_sigature() switch on that enum.
CC: Ian Romanick ian.d.roman...@intel.com
CC: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
src/glsl/ir_function.cpp | 53 -
1 files changed, 33 insertions(+), 20 deletions(-)
diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
index dd63e30..6cfc32c 100644
--- a/src/glsl/ir_function.cpp
+++ b/src/glsl/ir_function.cpp
@@ -24,17 +24,28 @@
#include glsl_types.h
#include ir.h
+typedef enum {
+ PARAMETER_LIST_NO_MATCH,
+ PARAMETER_LIST_EXACT_MATCH,
+ PARAMETER_LIST_INEXACT_MATCH, /* Match requires implicit conversion. */
+} parameter_list_match_t;
+
/**
* \brief Check if two parameter lists match.
*
* \param list_a Parameters of the function definition.
* \param list_b Actual parameters passed to the function.
- * \return If an exact match, return 0.
- * If an inexact match requiring implicit conversion, return 1.
- * If not a match, return -1.
* \see matching_signature()
*/
Looks like the above comment block is now duplicated here.
-static int
+
+/**
+ * \brief Check if two parameter lists match.
+ *
+ * \param list_a Parameters of the function definition.
+ * \param list_b Actual parameters passed to the function.
+ * \see matching_signature()
+ */
+static parameter_list_match_t
parameter_lists_match(const exec_list *list_a, const exec_list *list_b)
{
const exec_node *node_a = list_a-head;
@@ -52,7 +63,7 @@ parameter_lists_match(const exec_list *list_a, const
exec_list *list_b)
* do not match.
*/
if (node_b-is_tail_sentinel())
- return -1;
+ return PARAMETER_LIST_NO_MATCH;
const ir_variable *const param = (ir_variable *) node_a;
@@ -72,17 +83,17 @@ parameter_lists_match(const exec_list *list_a, const
exec_list *list_b)
* as uniform.
*/
assert(0);
- return -1;
+ return PARAMETER_LIST_NO_MATCH;
case ir_var_const_in:
case ir_var_in:
if (!actual-type-can_implicitly_convert_to(param-type))
- return -1;
+ return PARAMETER_LIST_NO_MATCH;
break;
case ir_var_out:
if (!param-type-can_implicitly_convert_to(actual-type))
- return -1;
+ return PARAMETER_LIST_NO_MATCH;
break;
case ir_var_inout:
@@ -90,11 +101,11 @@ parameter_lists_match(const exec_list *list_a, const
exec_list *list_b)
* there is int - float but no float - int), inout parameters must
* be exact matches.
*/
- return -1;
+ return PARAMETER_LIST_NO_MATCH;
default:
assert(false);
- return -1;
+ return PARAMETER_LIST_NO_MATCH;
}
}
@@ -103,12 +114,12 @@ parameter_lists_match(const exec_list *list_a, const
exec_list *list_b)
* match.
*/
if (!node_b-is_tail_sentinel())
- return -1;
+ return PARAMETER_LIST_NO_MATCH;
if (inexact_match)
- return 1;
+ return PARAMETER_LIST_INEXACT_MATCH;
else
- return 0;
+ return PARAMETER_LIST_EXACT_MATCH;
}
@@ -132,18 +143,20 @@ ir_function::matching_signature(const exec_list
*actual_parameters)
ir_function_signature *const sig =
(ir_function_signature *) iter.get();
- const int score = parameter_lists_match( sig-parameters,
- actual_parameters);
-
- /* If we found an exact match, simply return it */
- if (score == 0)
+ switch (parameter_lists_match( sig-parameters, actual_parameters)) {
+ case PARAMETER_LIST_EXACT_MATCH:
return sig;
-
- if (score 0) {
+ case PARAMETER_LIST_INEXACT_MATCH:
if (match == NULL)
match = sig;
else
multiple_inexact_matches = true;
+ continue;
+ case PARAMETER_LIST_NO_MATCH:
+ continue;
+ default:
+ assert(false);
+ return NULL;
}
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] faster util_next_power_of_two() function
On 06/08/2011 06:38 AM, Benjamin Bellec wrote: Here is the v4 patch. Benjamin As an uninformed bystander, I have some nitpicks that may just be coding style. From the patch: + if (x = 1) + return 1; I think it would make more sense to move this above the #ifdef and not duplicate it in each implementation. It's about the function input, not the implementations. From the patch: + else + return (1 ((sizeof(unsigned) * 8) - __builtin_clz(x - 1))); I don't like else after return. The else can be removed entirely. -- Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Truncated extensions string
On 03/11/2011 02:14 PM, Kenneth Graunke wrote: On Friday, March 11, 2011 10:46:31 AM José Fonseca wrote: On Fri, 2011-03-11 at 09:04 -0800, Eric Anholt wrote: On Fri, 11 Mar 2011 10:33:13 +, José Fonseca jfons...@vmware.com wrote: The problem from http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12493.h tml is back, and now a bit worse -- it causes Quake3 arena demo to crash (at least the windows version). The full version works fine. I'm not sure what other applications are hit by this. See the above thread for more background. There are two major approaches: 1) sort extensions chronologically instead of alphabetically. See attached patch for that - for those who prefer to see extensions sorted alphabetically in glxinfo, we could modify glxinfo to sort then before displaying 2) detect broken applications (i.e., by process name), and only sort extensions strings chronologically then Personally I think that varying behavior based on process name is a ugly and brittle hack, so I'd prefer 1), but I just want to put this on my back above all, so whatever works is also fine by me. If this is just a hack for one broken application, and we think that building in a workaround for this particular broken application is important (I don't), I still prefer an obvious hack for that broken application like feeding it a tiny extension string that it cares about, instead of reordering the extension list. There are many versions of Quake3 out there, some fixed, others not, and others enhanced. This means a tiny string would prevent any Quake3 application from finding newer extensions. So I think that if we go for the application name detection then we should present the whole extension string sorted chronologically, instead of giving a tiny string. Jose I agree with José - it's not one broken application, it's a number of old, sometimes closed-source games that we can't change. I'm not sure how changing the sorting solves the problem, anyway - the amount of data returned would still overflow the buffer, possibly wreaking havoc. I'd rather avoid that. Ian and I talked about this a year ago, and the solution I believe we came up with was to use a driconf option or environment variable: If MESA_MAX_EXTENSION_YEAR=2006, then glGetString would only return extensions created in 2006 or earlier. The rationale is that if a game came out in 2006, it won't know about any extensions from 2007 anyway, so advertising them is useless. The fixed-size buffer is also almost certainly large enough to handle this cut-down list of extensions. I'm just a lurker on the list, but this approach seems the most sane to me. Keeping the code/table in a format useful to developers seems more important than supporting legacy applications. In my opinion, a user of old, closed or binary applications can flip some switches to use the latest mesa. This should be trivial to do now that you already have the years for each extension...just store them in the table, rather than in comments, and check before listing an extension. I suspect that the performance of any implementation is insignificant, since this kind of query happens very few times in an application? A driconf option is nice because it allows this to be overridden in .drirc on a per-app basis, rather than having to set an environment variable. It might be a bit more work though. --Kenneth ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
