Re: [Mesa-dev] [PATCH] mesa: Fix the Mesa IR copy propagation to not read past writes to the reg.
Looks good to me FWIW.
When dst_reg.reladdr is set we could still restrict the reset to
dst_reg.writemask bits, but this was not done before either.
Jose
On Fri, 2011-02-04 at 12:50 -0800, Eric Anholt wrote:
Fixes glsl-vs-post-increment-01.
---
src/mesa/program/ir_to_mesa.cpp | 47 +-
1 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 3794c0d..d0ec23f 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2742,13 +2742,46 @@ ir_to_mesa_visitor::copy_propagate(void)
/* Continuing the block, clear any written channels from
* the ACP.
*/
- if (inst-dst_reg.file == PROGRAM_TEMPORARY) {
- if (inst-dst_reg.reladdr) {
-memset(acp, 0, sizeof(*acp) * this-next_temp * 4);
- } else {
-for (int i = 0; i 4; i++) {
- if (inst-dst_reg.writemask (1 i)) {
- acp[4 * inst-dst_reg.index + i] = NULL;
+ if (inst-dst_reg.file == PROGRAM_TEMPORARY inst-dst_reg.reladdr) {
+ /* Any temporary might be written, so no copy propagation
+ * across this instruction.
+ */
+ memset(acp, 0, sizeof(*acp) * this-next_temp * 4);
+ } else if (inst-dst_reg.file == PROGRAM_OUTPUT
+ inst-dst_reg.reladdr) {
+ /* Any output might be written, so no copy propagation
+ * from outputs across this instruction.
+ */
+ for (int r = 0; r this-next_temp; r++) {
+for (int c = 0; c 4; c++) {
+ if (acp[4 * r + c]-src_reg[0].file == PROGRAM_OUTPUT)
+ acp[4 * r + c] = NULL;
+}
+ }
+ } else if (inst-dst_reg.file == PROGRAM_TEMPORARY ||
+ inst-dst_reg.file == PROGRAM_OUTPUT) {
+ /* Clear where it's used as dst. */
+ if (inst-dst_reg.file == PROGRAM_TEMPORARY) {
+for (int c = 0; c 4; c++) {
+ if (inst-dst_reg.writemask (1 c)) {
+ acp[4 * inst-dst_reg.index + c] = NULL;
+ }
+}
+ }
+
+ /* Clear where it's used as src. */
+ for (int r = 0; r this-next_temp; r++) {
+for (int c = 0; c 4; c++) {
+ if (!acp[4 * r + c])
+ continue;
+
+ int src_chan = GET_SWZ(acp[4 * r + c]-src_reg[0].swizzle, c);
+
+ if (acp[4 * r + c]-src_reg[0].file == inst-dst_reg.file
+ acp[4 * r + c]-src_reg[0].index == inst-dst_reg.index
+ inst-dst_reg.writemask (1 src_chan))
+ {
+ acp[4 * r + c] = NULL;
}
}
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 23525] Software rendering on QEMU guests badly broken
https://bugs.freedesktop.org/show_bug.cgi?id=23525 --- Comment #4 from Bernhard M. Wiedemann freedesktop...@lsmod.de 2011-02-08 03:16:02 PST --- Mesa-7.10 swrast on Qemu/KVM's emulated 24bit cirrus graphics is still broken. Looks like this: http://openqa.opensuse.org/opensuse/permanent/bug/bfo23525.png but works on vesa driver that has (II) VESA(0): Creating default Display subsection in Screen section Default Screen for depth/fbbpp 24/24 (==) VESA(0): Depth 24, (==) framebuffer bpp 24 ... (==) Depth 24 pixmap format is 32 bpp and also works on fbdev with 16/16 -- 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] r600g, silence a few valgrind warnings
Pushed, thanks.
Marek
On Tue, Feb 8, 2011 at 2:57 AM, Brian Paterni bpate...@gmail.com wrote:
Hi all,
Here's a small patch which silences a few unitialized bytes warnings in
valgrind:
diff --git a/src/gallium/winsys/r600/drm/r600_drm.c
b/src/gallium/winsys/r600/drm/r600_drm.c
index 096c178..f5cd48d 100644
--- a/src/gallium/winsys/r600/drm/r600_drm.c
+++ b/src/gallium/winsys/r600/drm/r600_drm.c
@@ -67,7 +67,7 @@ unsigned r600_get_clock_crystal_freq(struct radeon
*radeon)
static int radeon_get_device(struct radeon *radeon)
{
- struct drm_radeon_info info;
+ struct drm_radeon_info info = {};
int r;
radeon-device = 0;
diff --git a/src/gallium/winsys/r600/drm/r600_hw_context.c
b/src/gallium/winsys/r600/drm/r600_hw_context.c
index a939ec6..f170640 100644
--- a/src/gallium/winsys/r600/drm/r600_hw_context.c
+++ b/src/gallium/winsys/r600/drm/r600_hw_context.c
@@ -1088,7 +1088,7 @@ void r600_context_draw(struct r600_context *ctx,
const struct r600_draw *draw)
void r600_context_flush(struct r600_context *ctx)
{
- struct drm_radeon_cs drmib;
+ struct drm_radeon_cs drmib = {};
struct drm_radeon_cs_chunk chunks[2];
uint64_t chunk_array[2];
unsigned fence;
diff --git a/src/gallium/winsys/r600/drm/radeon_bo.c
b/src/gallium/winsys/r600/drm/radeon_bo.c
index 999de82..3643ddb 100644
--- a/src/gallium/winsys/r600/drm/radeon_bo.c
+++ b/src/gallium/winsys/r600/drm/radeon_bo.c
@@ -98,7 +98,7 @@ struct radeon_bo *radeon_bo(struct radeon *radeon,
unsigned handle,
bo-size = open_arg.size;
bo-shared = TRUE;
} else {
- struct drm_radeon_gem_create args;
+ struct drm_radeon_gem_create args = {};
args.size = size;
args.alignment = alignment;
@@ -204,7 +204,7 @@ int radeon_bo_get_tiling_flags(struct radeon *radeon,
uint32_t *tiling_flags,
uint32_t *pitch)
{
- struct drm_radeon_gem_get_tiling args;
+ struct drm_radeon_gem_get_tiling args = {};
int ret;
args.handle = bo-handle;
___
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
[Mesa-dev] [Bug 33934] glBlitFramebuffer could have a fast path if there's no scaling
https://bugs.freedesktop.org/show_bug.cgi?id=33934 --- Comment #3 from Neil Roberts n...@linux.intel.com 2011-02-08 05:08:06 PST --- Created an attachment (id=43096) -- (https://bugs.freedesktop.org/attachment.cgi?id=43096) Test case showing the performance difference Well at least on the Intel driver there is a faster path for blitting that glCopyTexSubImage2D uses. If it's not also beneficial for Radeon then maybe we should move the patch to be specific to the Intel drivers. Attached is a test case to get some timing for the two functions. Without patch: time for glBlitFramebuffer = 122285 time for glCopyTexSubImage2D = 6097 So glCopyTexSubImage2D is 1906% faster than glBlitFramebuffer. With the patch I get: time for glBlitFramebuffer = 25740 time for glCopyTexSubImage2D = 6900 The patch improves the speed of glBlitFramebuffer by 375% but it's still pretty slow compared to glCopyTexSubImage2D. Maybe the cost of glBlitFramebuffer is mostly in preserving the GL state across the Mesa meta calls and the patch still does a bit of this. Maybe we should make a proper Intel-specific fast path for glBlitFramebuffer that directly calls intelEmitCopyBlit like do_copy_texsubimage does so that it can avoid affecting the GL state. -- 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 33934] 3D blitting is orders of magnitude slower than equivalent 2D blitting.
https://bugs.freedesktop.org/show_bug.cgi?id=33934 Chris Wilson ch...@chris-wilson.co.uk changed: What|Removed |Added Summary|glBlitFramebuffer could |3D blitting is orders of |have a fast path if there's |magnitude slower than |no scaling |equivalent 2D blitting. Component|Mesa core |Drivers/DRI/i965 AssignedTo|mesa-dev@lists.freedesktop. |e...@anholt.net |org | --- Comment #6 from Chris Wilson ch...@chris-wilson.co.uk 2011-02-08 06:39:32 PST --- Marek, this appears to be an intel issue, agreed? -- 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] Black window on Mesa 7.10
Hi all, I just upgraded Mesa to the 7.10 version. Here is the glxinfo trace : user@worky:~$ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile GEM 20100330 DEVELOPMENT OpenGL version string: 2.1 Mesa 7.10 OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_copy_buffer, GL_ARB_depth_clamp, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, GL_ARB_fragment_coord_conventions, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_framebuffer_object, GL_ARB_half_float_pixel, GL_ARB_half_float_vertex, GL_ARB_map_buffer_range, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, GL_ARB_seamless_cube_map, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_sync, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_texture_rg, GL_ARB_texture_swizzle, GL_ARB_transpose_matrix, GL_ARB_vertex_array_bgra, GL_ARB_vertex_array_object, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_copy_texture, GL_EXT_draw_buffers2, GL_EXT_draw_range_elements, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_object, GL_EXT_fog_coord, GL_EXT_gpu_program_parameters, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_provoking_vertex, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_shader_objects, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_texture_swizzle, GL_EXT_timer_query, GL_EXT_vertex_array, GL_EXT_vertex_array_bgra, GL_3DFX_texture_compression_FXT1, GL_APPLE_client_storage, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_APPLE_object_purgeable, GL_ATI_blend_equation_separate, GL_ATI_envmap_bumpmap, GL_ATI_texture_env_combine3, GL_ATI_separate_stencil, GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_texture_signed_rgba, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_depth_clamp, GL_NV_light_max_exponent, GL_NV_packed_depth_stencil, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_OES_read_format,
[Mesa-dev] [Bug 34042] New: Surfaceless eglMakeCurrent() fails if the supplied EGLContext is not a dummy context
https://bugs.freedesktop.org/show_bug.cgi?id=34042 Summary: Surfaceless eglMakeCurrent() fails if the supplied EGLContext is not a dummy context Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: alexandros.frant...@linaro.org Created an attachment (id=43116) -- (https://bugs.freedesktop.org/attachment.cgi?id=43116) Example exhibiting the issue In a EGL implementation that supports EGL_KHR_surfaceless_opengl, making an EGLContext current without any surfaces works only if the supplied EGLContext is a dummy one (see the example). Running the example on my system (r600g but EGL_SOFTWARE=1 results are the same) I get: $ MESA_DEBUG=1 ./egl-surfaceless EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_image EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_surfaceless_gles1 EGL_KHR_surfaceless_gles2 EGL_KHR_surfaceless_opengl Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable eglMakeCurrent Dummy Succeeded: 0x3000 Mesa warning: MakeCurrent: incompatible visuals for context and drawbuffer eglMakeCurrent Normal Failed: 0x3000 It is strange that although the second eglMakeCurrent fails, the eglError() returns EGL_SUCCESS (0x3000). -- 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] [PATCH] st/mesa: Fix surfaceless opengl with non-dummy contexts
main/context.c:check_complatible() detecs an incomplete
framebuffer using its pointer, so do not copy it.
This should fix https://bugs.freedesktop.org/show_bug.cgi?id=34042
---
src/mesa/state_tracker/st_manager.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index 179e5dc..17e11ec 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -426,19 +426,13 @@ st_framebuffer_create(struct st_framebuffer_iface *stfbi)
struct gl_config mode;
gl_buffer_index idx;
+ if (!stfbi)
+ return NULL;
+
stfb = CALLOC_STRUCT(st_framebuffer);
if (!stfb)
return NULL;
- /* for FBO-only context */
- if (!stfbi) {
- struct gl_framebuffer *base = _mesa_get_incomplete_framebuffer();
-
- stfb-Base = *base;
-
- return stfb;
- }
-
st_visual_to_context_mode(stfbi-visual, mode);
_mesa_initialize_window_framebuffer(stfb-Base, mode);
@@ -764,7 +758,8 @@ st_api_make_current(struct st_api *stapi, struct
st_context_iface *stctxi,
ret = _mesa_make_current(st-ctx, stdraw-Base, stread-Base);
}
else {
- ret = FALSE;
+ struct gl_framebuffer *incomplete =
_mesa_get_incomplete_framebuffer();
+ ret = _mesa_make_current(st-ctx, incomplete, incomplete);
}
st_framebuffer_reference(stdraw, NULL);
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 34042] Surfaceless eglMakeCurrent() fails if the supplied EGLContext is not a dummy context
https://bugs.freedesktop.org/show_bug.cgi?id=34042 --- Comment #1 from Benjamin Franzke benjaminfran...@googlemail.com 2011-02-08 10:05:18 PST --- Should be fixed by: http://lists.freedesktop.org/archives/mesa-dev/2011-February/005371.html -- 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] Black window on Mesa 7.10
On Tue, 2011-02-08 at 16:16 +, Lionel Landwerlin wrote: Hi all, Ever since I can't see anything on the screen, even if the rendering seems to be done. For instance glxgears as well as any other opengl app displays just a black window, but still manages to compute framerate : user@worky:~$ glxgears 10153 frames in 5.0 seconds = 2030.533 FPS 10694 frames in 5.0 seconds = 2138.651 FPS 10695 frames in 5.0 seconds = 2138.882 FPS 10914 frames in 5.0 seconds = 2182.691 FPS 10753 frames in 5.0 seconds = 2150.418 FPS 10654 frames in 5.0 seconds = 2130.680 FPS 10858 frames in 5.0 seconds = 2171.426 FPS If I switch to the software x11 rendering, there is no display problem. Any idea how to find the problem ? Regards, Back to 7.8.2 component by component seems to fix the problem when I switch back by the libgl1-mesa-dri package containing : /usr/lib/dri/radeon_dri.so /usr/lib/dri/i915_dri.so /usr/lib/dri/unichrome_dri.so /usr/lib/dri/i965_dri.so /usr/lib/dri/r600_dri.so /usr/lib/dri/r200_dri.so /usr/lib/dri/mach64_dri.so /usr/lib/dri/tdfx_dri.so /usr/lib/dri/savage_dri.so /usr/lib/dri/r300_dri.so /usr/lib/dri/sis_dri.so /usr/lib/dri/r128_dri.so /usr/lib/dri/mga_dri.so /usr/lib/dri/swrast_dri.so -- Lionel Landwerlin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 34047] New: Assert in _tnl_import_array() when using GLfixed vertex datatypes with GLESv2
https://bugs.freedesktop.org/show_bug.cgi?id=34047
Summary: Assert in _tnl_import_array() when using GLfixed
vertex datatypes with GLESv2
Product: Mesa
Version: 7.9
Platform: x86 (IA32)
OS/Version: other
Status: NEW
Severity: critical
Priority: medium
Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: david.le...@nokia.com
-Hardware/software setup:
Intel GMA 3150 (Atom N450) DRI i915
Meego 1.1 trunk
Mesa 7.9.1 / Mesa 7.10
Our program hits an assert in _tnl_import_array() when we try to use GLfixed
datatypes for vertices. It seems the _tnl_import_array() method is unable to
convert this datatype and just asserts to crash the program. According to the
GLESv2 spec, GLfixed datatypes are supported for vertex input.
We are using the following gl functions to render:
glVertexAttribPointer(); // Datatype is GL_FIXED
glDrawElements();
I prototyped a GLfixed to GLfloat conversion function in _tnl_import_array()and
it seems to have fixed the problem.
static void
convert_fixed_to_float(const struct gl_client_array *input,
const GLubyte *ptr, GLfloat *fptr,
GLuint count, GLuint sz)
{
GLuint i,j;
GLfixed *in =(GLfixed *)ptr;
for (i = 0; i count; i++) {
for (j = 0; j input-Size; j++) {
*fptr = (GLfloat)((*in)*(1/65536.0f));
in++;
fptr++;
}
ptr += input-StrideB;
}
}
--
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 34047] Assert in _tnl_import_array() when using GLfixed vertex datatypes with GLESv2
https://bugs.freedesktop.org/show_bug.cgi?id=34047 --- Comment #1 from David Leong david.le...@nokia.com 2011-02-08 10:30:24 PST --- Just to add a note. The same code using GL_FIXED works correctly when using the SGX driver. -- 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 34047] Assert in _tnl_import_array() when using GLfixed vertex datatypes with GLESv2
https://bugs.freedesktop.org/show_bug.cgi?id=34047 --- Comment #2 from David Leong david.le...@nokia.com 2011-02-08 10:59:04 PST --- Code also works ok on the Symbian GLESv2 and windows GLESv2 emulation implementations. -- 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 34042] Surfaceless eglMakeCurrent() fails if the supplied EGLContext is not a dummy context
https://bugs.freedesktop.org/show_bug.cgi?id=34042 --- Comment #2 from Alexandros Frantzis alexandros.frant...@linaro.org 2011-02-08 11:50:46 PST --- (In reply to comment #1) Should be fixed by: http://lists.freedesktop.org/archives/mesa-dev/2011-February/005371.html I tried the patch, but the problem remains. -- 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 34049] New: r600g: assertion failure (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=34049 Summary: r600g: assertion failure (regression) Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: monr...@gmail.com Mesa git master causes an assertion failure on r600g with the following piglit tests. bugs/fdo23670-drawpix_stencil general/stencil-drawpixels stencil-drawpixels: program/program.c:452: _mesa_reference_program: Assertion `(*ptr)-RefCount 0' failed Aborted git bisect says: 5cbff0932e498f49b57cbb71037b93416bfe30e0 is the first bad commit commit 5cbff0932e498f49b57cbb71037b93416bfe30e0 Author: Brian Paul bri...@vmware.com Date: Tue Feb 8 08:05:14 2011 -0700 st/mesa: free the temporary bitmap/drawpix shader code Fixes a per-shader memory leak when drawing glBitmaps, glDrawPixels or glCopyPixels. NOTE: This is a candidate for the 7.9 and 7.10 branches. -- 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 34042] Surfaceless eglMakeCurrent() fails if the supplied EGLContext is not a dummy context
https://bugs.freedesktop.org/show_bug.cgi?id=34042 --- Comment #3 from Alexandros Frantzis alexandros.frant...@linaro.org 2011-02-08 12:27:23 PST --- Note that I have this problem with all of r600g, r600c, i915c and gallium softpipe. -- 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 34042] Surfaceless eglMakeCurrent() fails if the supplied EGLContext is not a dummy context
https://bugs.freedesktop.org/show_bug.cgi?id=34042 Siarhei Siamashka siarhei.siamas...@gmail.com changed: What|Removed |Added CC||siarhei.siamas...@gmail.com -- 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 34042] Surfaceless eglMakeCurrent() fails if the supplied EGLContext is not a dummy context
https://bugs.freedesktop.org/show_bug.cgi?id=34042 --- Comment #4 from Benjamin Franzke benjaminfran...@googlemail.com 2011-02-08 13:16:27 PST --- (In reply to comment #3) Note that I have this problem with all of r600g, r600c, i915c and gallium softpipe. I can't reproduce this using your test client (or cairo-egl). Tested with r600g and softpipe using egl_gallium and egl_dri2. You might want to use EGL_LOG_LEVEL=debug to get more output. -- 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] Gallium proposal: add a user pointer in pipe_resource
Keith, redefine_user_buffer() would be a good compromise and I believe the performance hit wouldn't be so noticable. It would also allow partial uploads of constants in a user buffer, which is something we'd like to have too. Currently, st/mesa in st_draw_vbo is doing: - N calls to resource_destroy - some unnecessary computations - N calls to user_buffer_create - 1 call to set_vertex_buffers - 1 call to set_vertex_elements_state If we can replace this by N calls to redefine_user_buffer, then I am all for it, provided neither _NEW_ARRAY nor _NEW_PROGRAM is dirty of course. Can the function look, let's say, like this? void redefine_user_buffer(struct pipe_context *, struct pipe_resource *, const struct pipe_box *); Marek On Mon, Feb 7, 2011 at 5:15 PM, Keith Whitwell kei...@vmware.com wrote: Marek, I'm fine with keeping user buffers -- it's only a vague hope they'll fade away over time, and I'm comfortable with keeping them as long as their behaviour is well understood. The really important thing for me is to preserve traceability. That is to say it should be possible to observe what happens over the interface and infer directly from that when something important happens. In this case, that would mean having a way to notice that the contents and/or size of a userbuffer changed. That could be as simple as a notification call that this has happened, for example redefine_user_buffer(). On your current drivers that call would be a noop -- hopefully that's not going to be a noticiable performance hit? Then in some tracing or recording module, that call could be used to log the contents of the userbuffer to a file, or in some future indirect-rendering equivalent, the new contents could be transmitted across the wire, etc. This would mean that userbuffers continue to have a known size, etc, and would require the state-tracker to issue the redefine call as necessary. You're in a better position than me to comment on the performance impact of this. If you're saying this isn't workable from a performance POV, then as you suggest we'll have to find a way to push the logic for identifying when userbuffers changed down into those components (tracing, remoting, etc) which care about it. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource
On Tue, 2011-02-08 at 22:29 +0100, Marek Olšák wrote: Keith, redefine_user_buffer() would be a good compromise and I believe the performance hit wouldn't be so noticable. It would also allow partial uploads of constants in a user buffer, which is something we'd like to have too. Currently, st/mesa in st_draw_vbo is doing: - N calls to resource_destroy - some unnecessary computations - N calls to user_buffer_create - 1 call to set_vertex_buffers - 1 call to set_vertex_elements_state If we can replace this by N calls to redefine_user_buffer, then I am all for it, provided neither _NEW_ARRAY nor _NEW_PROGRAM is dirty of course. Can the function look, let's say, like this? void redefine_user_buffer(struct pipe_context *, struct pipe_resource *, const struct pipe_box *); That looks good, but wouldn't you also want to be able to change the size of the userbuffer? I can see you might be able to implicitly grow the buffer this way (when box-x + box-width resource-width0), but that's fairly obtuse and it doesn't permit shrinking. So perhaps as above with a unsigned new_width0 parameter? Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource
On Tue, Feb 8, 2011 at 10:39 PM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2011-02-08 at 22:29 +0100, Marek Olšák wrote: Keith, redefine_user_buffer() would be a good compromise and I believe the performance hit wouldn't be so noticable. It would also allow partial uploads of constants in a user buffer, which is something we'd like to have too. Currently, st/mesa in st_draw_vbo is doing: - N calls to resource_destroy - some unnecessary computations - N calls to user_buffer_create - 1 call to set_vertex_buffers - 1 call to set_vertex_elements_state If we can replace this by N calls to redefine_user_buffer, then I am all for it, provided neither _NEW_ARRAY nor _NEW_PROGRAM is dirty of course. Can the function look, let's say, like this? void redefine_user_buffer(struct pipe_context *, struct pipe_resource *, const struct pipe_box *); That looks good, but wouldn't you also want to be able to change the size of the userbuffer? I can see you might be able to implicitly grow the buffer this way (when box-x + box-width resource-width0), but that's fairly obtuse and it doesn't permit shrinking. So perhaps as above with a unsigned new_width0 parameter? I had in mind that width0 would be ~0, but I guess that's not nice. What about this? void redefine_user_buffer( struct pipe_context*, struct pipe_resource*, unsigned offset, unsigned size); and new width0 would implicitly be offset+size; Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource
On Tue, 2011-02-08 at 22:51 +0100, Marek Olšák wrote: void redefine_user_buffer( struct pipe_context*, struct pipe_resource*, unsigned offset, unsigned size); and new width0 would implicitly be offset+size; I think this is a great place to start, if you're happy with it too. Lets see how well it works for you in implementation make further adjustments later if necessary. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 34047] Assert in _tnl_import_array() when using GLfixed vertex datatypes with GLESv2
https://bugs.freedesktop.org/show_bug.cgi?id=34047 Chad Versace c...@chad-versace.us changed: What|Removed |Added AssignedTo|mesa-dev@lists.freedesktop. |c...@chad-versace.us |org | --- Comment #3 from Chad Versace c...@chad-versace.us 2011-02-08 14:35:35 PST --- Assign bug to myself: c...@chad-versace.us -- 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 34042] Surfaceless eglMakeCurrent() fails if the supplied EGLContext is not a dummy context
https://bugs.freedesktop.org/show_bug.cgi?id=34042 --- Comment #5 from Alexandros Frantzis alexandros.frant...@linaro.org 2011-02-08 15:42:29 PST --- (In reply to comment #4) (In reply to comment #3) Note that I have this problem with all of r600g, r600c, i915c and gallium softpipe. I can't reproduce this using your test client (or cairo-egl). Tested with r600g and softpipe using egl_gallium and egl_dri2. You might want to use EGL_LOG_LEVEL=debug to get more output. The proposed patch works after all. I was forgetting to set EGL_DRIVERS_PATH when testing the libraries built from git. Sorry for the false alarm. 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
[Mesa-dev] [Bug 34049] r600g: assertion failure (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=34049 --- Comment #1 from Brian Paul bri...@vmware.com 2011-02-08 17:25:01 PST --- This should be fixed with commit 7230e1a22822ce91f2d2555da53404f195fa9aaf. Can you retest and close if fixed? I tested w/ softpipe and llvmpipe here but not r600g. -- 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] [PATCH 1/3] egl_dri2: rename loader_extension to dri2_loader_extension
From 7db4f1f8a5c85666b3ea7e60ee58bd5e68457c20 Mon Sep 17 00:00:00 2001
From: Haitao Feng haitao.f...@intel.com
Date: Wed, 9 Feb 2011 14:18:48 -0500
Subject: [PATCH 1/3] egl_dri2: rename loader_extension to dri2_loader_extension
Signed-off-by: Haitao Feng haitao.f...@intel.com
---
src/egl/drivers/dri2/egl_dri2.h |2 +-
src/egl/drivers/dri2/platform_wayland.c | 12 ++--
src/egl/drivers/dri2/platform_x11.c | 22 +++---
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 72e887c..66d200d 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -79,7 +79,7 @@ struct dri2_egl_display
char *device_name;
char *driver_name;
- __DRIdri2LoaderExtension loader_extension;
+ __DRIdri2LoaderExtension dri2_loader_extension;
const __DRIextension *extensions[3];
#ifdef HAVE_WAYLAND_PLATFORM
struct wl_egl_display*wl_dpy;
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index 16e0888..e0eae08 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -568,14 +568,14 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay
*disp)
if (!dri2_load_driver(disp))
goto cleanup_driver_name;
- dri2_dpy-loader_extension.base.name = __DRI_DRI2_LOADER;
- dri2_dpy-loader_extension.base.version = 3;
- dri2_dpy-loader_extension.getBuffers = dri2_get_buffers;
- dri2_dpy-loader_extension.flushFrontBuffer = dri2_flush_front_buffer;
- dri2_dpy-loader_extension.getBuffersWithFormat =
+ dri2_dpy-dri2_loader_extension.base.name = __DRI_DRI2_LOADER;
+ dri2_dpy-dri2_loader_extension.base.version = 3;
+ dri2_dpy-dri2_loader_extension.getBuffers = dri2_get_buffers;
+ dri2_dpy-dri2_loader_extension.flushFrontBuffer = dri2_flush_front_buffer;
+ dri2_dpy-dri2_loader_extension.getBuffersWithFormat =
dri2_get_buffers_with_format;
- dri2_dpy-extensions[0] = dri2_dpy-loader_extension.base;
+ dri2_dpy-extensions[0] = dri2_dpy-dri2_loader_extension.base;
dri2_dpy-extensions[1] = image_lookup_extension.base;
dri2_dpy-extensions[2] = NULL;
diff --git a/src/egl/drivers/dri2/platform_x11.c
b/src/egl/drivers/dri2/platform_x11.c
index 3b2f06e..ea4b717 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -735,21 +735,21 @@ dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
}
if (dri2_dpy-dri2_minor = 1) {
- dri2_dpy-loader_extension.base.name = __DRI_DRI2_LOADER;
- dri2_dpy-loader_extension.base.version = 3;
- dri2_dpy-loader_extension.getBuffers = dri2_get_buffers;
- dri2_dpy-loader_extension.flushFrontBuffer = dri2_flush_front_buffer;
- dri2_dpy-loader_extension.getBuffersWithFormat =
+ dri2_dpy-dri2_loader_extension.base.name = __DRI_DRI2_LOADER;
+ dri2_dpy-dri2_loader_extension.base.version = 3;
+ dri2_dpy-dri2_loader_extension.getBuffers = dri2_get_buffers;
+ dri2_dpy-dri2_loader_extension.flushFrontBuffer =
dri2_flush_front_buffer;
+ dri2_dpy-dri2_loader_extension.getBuffersWithFormat =
dri2_get_buffers_with_format;
} else {
- dri2_dpy-loader_extension.base.name = __DRI_DRI2_LOADER;
- dri2_dpy-loader_extension.base.version = 2;
- dri2_dpy-loader_extension.getBuffers = dri2_get_buffers;
- dri2_dpy-loader_extension.flushFrontBuffer = dri2_flush_front_buffer;
- dri2_dpy-loader_extension.getBuffersWithFormat = NULL;
+ dri2_dpy-dri2_loader_extension.base.name = __DRI_DRI2_LOADER;
+ dri2_dpy-dri2_loader_extension.base.version = 2;
+ dri2_dpy-dri2_loader_extension.getBuffers = dri2_get_buffers;
+ dri2_dpy-dri2_loader_extension.flushFrontBuffer =
dri2_flush_front_buffer;
+ dri2_dpy-dri2_loader_extension.getBuffersWithFormat = NULL;
}
- dri2_dpy-extensions[0] = dri2_dpy-loader_extension.base;
+ dri2_dpy-extensions[0] = dri2_dpy-dri2_loader_extension.base;
dri2_dpy-extensions[1] = image_lookup_extension.base;
dri2_dpy-extensions[2] = NULL;
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] egl_dri2: add swrast
From 4d2994362d53b0a7e00e6ec29433c648a3695208 Mon Sep 17 00:00:00 2001
From: Haitao Feng haitao.f...@intel.com
Date: Wed, 9 Feb 2011 14:43:23 -0500
Subject: [PATCH 2/3] egl_dri2: add swrast
This enables the egl_dri2 driver to load swrast driver
for software rendering. It could be used when hardware
dri2 drivers are not available, such as in VM.
Signed-off-by: Haitao Feng haitao.f...@intel.com
---
src/egl/drivers/dri2/egl_dri2.c | 144
src/egl/drivers/dri2/egl_dri2.h | 10 +-
src/egl/drivers/dri2/platform_drm.c |2 +
src/egl/drivers/dri2/platform_wayland.c |2 +
src/egl/drivers/dri2/platform_x11.c | 285 +--
5 files changed, 393 insertions(+), 50 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 3e51077..919b996 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -244,6 +244,17 @@ static struct dri2_extension_match dri2_core_extensions[]
= {
{ NULL, 0, 0 }
};
+static struct dri2_extension_match swrast_driver_extensions[] = {
+ { __DRI_CORE, 1, offsetof(struct dri2_egl_display, core) },
+ { __DRI_SWRAST, 2, offsetof(struct dri2_egl_display, swrast) },
+ { NULL }
+};
+
+static struct dri2_extension_match swrast_core_extensions[] = {
+ { __DRI_TEX_BUFFER, 2, offsetof(struct dri2_egl_display, tex_buffer) },
+ { NULL }
+};
+
static EGLBoolean
dri2_bind_extensions(struct dri2_egl_display *dri2_dpy,
struct dri2_extension_match *matches,
@@ -331,10 +342,17 @@ dri2_load_driver(_EGLDisplay *disp)
return EGL_FALSE;
}
- if (!dri2_bind_extensions(dri2_dpy, dri2_driver_extensions, extensions)) {
- dlclose(dri2_dpy-driver);
- return EGL_FALSE;
- }
+ if (strcmp(dri2_dpy-driver_name, swrast) == 0) {
+ if (!dri2_bind_extensions(dri2_dpy, swrast_driver_extensions,
extensions)) {
+ dlclose(dri2_dpy-driver);
+ return EGL_FALSE;
+ }
+ } else {
+ if (!dri2_bind_extensions(dri2_dpy, dri2_driver_extensions, extensions))
{
+ dlclose(dri2_dpy-driver);
+ return EGL_FALSE;
+ }
+ }
return EGL_TRUE;
}
@@ -347,9 +365,17 @@ dri2_create_screen(_EGLDisplay *disp)
unsigned int api_mask;
dri2_dpy = disp-DriverData;
- dri2_dpy-dri_screen =
- dri2_dpy-dri2-createNewScreen(0, dri2_dpy-fd, dri2_dpy-extensions,
- dri2_dpy-driver_configs, disp);
+
+ if (dri2_dpy-dri2) {
+ dri2_dpy-dri_screen =
+ dri2_dpy-dri2-createNewScreen(0, dri2_dpy-fd, dri2_dpy-extensions,
+dri2_dpy-driver_configs, disp);
+ } else {
+ assert(dri2_dpy-swrast);
+ dri2_dpy-dri_screen =
+ dri2_dpy-swrast-createNewScreen(0, dri2_dpy-extensions,
+ dri2_dpy-driver_configs, disp);
+ }
if (dri2_dpy-dri_screen == NULL) {
_eglLog(_EGL_WARNING, DRI2: failed to create dri screen);
@@ -357,13 +383,28 @@ dri2_create_screen(_EGLDisplay *disp)
}
extensions = dri2_dpy-core-getExtensions(dri2_dpy-dri_screen);
- if (!dri2_bind_extensions(dri2_dpy, dri2_core_extensions, extensions))
- goto cleanup_dri_screen;
+
+ if (dri2_dpy-dri2) {
+ if (!dri2_bind_extensions(dri2_dpy, dri2_core_extensions, extensions))
+ goto cleanup_dri_screen;
+ } else {
+ assert(dri2_dpy-swrast);
+ if (!dri2_bind_extensions(dri2_dpy, swrast_core_extensions, extensions))
+ goto cleanup_dri_screen;
+ }
- if (dri2_dpy-dri2-base.version = 2)
- api_mask = dri2_dpy-dri2-getAPIMask(dri2_dpy-dri_screen);
- else
- api_mask = 1 __DRI_API_OPENGL;
+ if (dri2_dpy-dri2) {
+ if (dri2_dpy-dri2-base.version = 2)
+ api_mask = dri2_dpy-dri2-getAPIMask(dri2_dpy-dri_screen);
+ else
+ api_mask = 1 __DRI_API_OPENGL;
+ } else {
+ assert(dri2_dpy-swrast);
+ if (dri2_dpy-swrast-base.version = 2)
+ api_mask = 1 __DRI_API_OPENGL | 1 __DRI_API_GLES | 1
__DRI_API_GLES2;
+ else
+ api_mask = 1 __DRI_API_OPENGL;
+ }
disp-ClientAPIs = 0;
if (api_mask (1 __DRI_API_OPENGL))
@@ -373,10 +414,19 @@ dri2_create_screen(_EGLDisplay *disp)
if (api_mask (1 __DRI_API_GLES2))
disp-ClientAPIs |= EGL_OPENGL_ES2_BIT;
- if (dri2_dpy-dri2-base.version = 2) {
- disp-Extensions.KHR_surfaceless_gles1 = EGL_TRUE;
- disp-Extensions.KHR_surfaceless_gles2 = EGL_TRUE;
- disp-Extensions.KHR_surfaceless_opengl = EGL_TRUE;
+ if (dri2_dpy-dri2) {
+ if (dri2_dpy-dri2-base.version = 2) {
+ disp-Extensions.KHR_surfaceless_gles1 = EGL_TRUE;
+ disp-Extensions.KHR_surfaceless_gles2 = EGL_TRUE;
+ disp-Extensions.KHR_surfaceless_opengl = EGL_TRUE;
+ }
+ } else {
+ assert(dri2_dpy-swrast);
+ if (dri2_dpy-swrast-base.version = 2) {
+ disp-Extensions.KHR_surfaceless_gles1 =
[Mesa-dev] [PATCH 3/3] egl_dri2: make swrast always double buffered
From 1ef02e603f0296e5d11df4e9a1b783fae2da3af8 Mon Sep 17 00:00:00 2001 From: Haitao Feng haitao.f...@intel.com Date: Wed, 9 Feb 2011 14:52:59 -0500 Subject: [PATCH 3/3] egl_dri2: make swrast always double buffered Signed-off-by: Haitao Feng haitao.f...@intel.com --- src/egl/drivers/dri2/egl_dri2.c |7 --- src/egl/drivers/dri2/platform_x11.c |1 + 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index 919b996..ffd97a5 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -157,14 +157,15 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig *dri_config, int id, } } - /* In EGL, double buffer or not isn't a config attribute. Pixmaps + /* In EGL, for dri2, double buffer or not isn't a config attribute. Pixmaps * surfaces are always single buffered, pbuffer surfaces are always * back buffers and windows can be either, selected by passing an * attribute at window surface construction time. To support this * we ignore all double buffer configs and manipulate the buffer we -* return in the getBuffer callback to get the behaviour we want. */ +* return in the getBuffer callback to get the behaviour we want. +* for swrast, all surfaces are always double buffered */ - if (double_buffer) + if ((dri2_dpy-dri2 double_buffer) || (dri2_dpy-swrast !double_buffer)) return NULL; if (depth 0 depth != base.BufferSize) diff --git a/src/egl/drivers/dri2/platform_x11.c b/src/egl/drivers/dri2/platform_x11.c index d138763..8147e12 100644 --- a/src/egl/drivers/dri2/platform_x11.c +++ b/src/egl/drivers/dri2/platform_x11.c @@ -23,6 +23,7 @@ * * Authors: *Kristian Høgsberg k...@bitplanet.net + *Haitao Feng haitao.f...@intel.com */ #include stdlib.h -- 1.7.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 34049] r600g: assertion failure (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=34049 Rafael Monica monr...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Rafael Monica monr...@gmail.com 2011-02-08 23:17:36 PST --- yeah, that commit fixed it here also on r600g -- 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
