[Mesa-dev] [PATCH] nouveau: Fix bugs in nouveau_video_buffer
Double free and array overflow, even if only 2 members are used the last one needs to be set to NULL explicitly. Signed-off-by: Maarten Lankhorst base); - FREE(buffer); return NULL; } diff --git a/src/gallium/drivers/nouveau/nouveau_video.h b/src/gallium/drivers/nouveau/nouveau_video.h index c6875c3..22593ff 100644 --- a/src/gallium/drivers/nouveau/nouveau_video.h +++ b/src/gallium/drivers/nouveau/nouveau_video.h @@ -7,10 +7,10 @@ struct nouveau_video_buffer { struct pipe_video_buffer base; unsigned num_planes; - struct pipe_resource *resources[2]; - struct pipe_sampler_view *sampler_view_planes[2]; + struct pipe_resource *resources[3]; + struct pipe_sampler_view *sampler_view_planes[3]; struct pipe_sampler_view *sampler_view_components[3]; - struct pipe_surface *surfaces[2]; + struct pipe_surface *surfaces[3]; }; struct nouveau_decoder { -- 1.7.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] vdpau: Add support for parameters
Currently only validating, since nothing else can be done with it yet Signed-off-by: Maarten Lankhorst --- src/gallium/state_trackers/vdpau/mixer.c | 95 +- src/gallium/state_trackers/vdpau/query.c | 41 +- src/gallium/state_trackers/vdpau/vdpau_private.h |3 + 3 files changed, 133 insertions(+), 6 deletions(-) diff --git a/src/gallium/state_trackers/vdpau/mixer.c b/src/gallium/state_trackers/vdpau/mixer.c index 1588744..276f5d5 100644 --- a/src/gallium/state_trackers/vdpau/mixer.c +++ b/src/gallium/state_trackers/vdpau/mixer.c @@ -49,12 +49,16 @@ vlVdpVideoMixerCreate(VdpDevice device, vlVdpVideoMixer *vmixer = NULL; VdpStatus ret; float csc[16]; + struct pipe_screen *screen; + unsigned max_width, max_height, i; + enum pipe_video_profile prof = PIPE_VIDEO_PROFILE_UNKNOWN; VDPAU_MSG(VDPAU_TRACE, "[VDPAU] Creating VideoMixer\n"); vlVdpDevice *dev = vlGetDataHTAB(device); if (!dev) return VDP_STATUS_INVALID_HANDLE; + screen = dev->vscreen->pscreen; vmixer = CALLOC(1, sizeof(vlVdpVideoMixer)); if (!vmixer) @@ -72,7 +76,7 @@ vlVdpVideoMixerCreate(VdpDevice device, vl_compositor_set_csc_matrix(&vmixer->compositor, csc); /* -* TODO: Handle features and parameters +* TODO: Handle features */ *mixer = vlAddDataHTAB(vmixer); @@ -80,10 +84,49 @@ vlVdpVideoMixerCreate(VdpDevice device, ret = VDP_STATUS_ERROR; goto no_handle; } - + vmixer->chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420; + ret = VDP_STATUS_INVALID_VIDEO_MIXER_PARAMETER; + for (i = 0; i < parameter_count; ++i) { + switch (parameters[i]) { + case VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_WIDTH: + vmixer->video_width = *(uint32_t*)parameter_values[i]; + break; + case VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_HEIGHT: + vmixer->video_height = *(uint32_t*)parameter_values[i]; + break; + case VDP_VIDEO_MIXER_PARAMETER_CHROMA_TYPE: + vmixer->chroma_format = ChromaToPipe(*(VdpChromaType*)parameter_values[i]); + break; + case VDP_VIDEO_MIXER_PARAMETER_LAYERS: + vmixer->max_layers = *(uint32_t*)parameter_values[i]; + break; + default: goto no_params; + } + } + ret = VDP_STATUS_INVALID_VALUE; + if (vmixer->max_layers > 4) { + VDPAU_MSG(VDPAU_TRACE, "[VDPAU] Max layers > 4 not supported\n", vmixer->max_layers); + goto no_params; + } + max_width = screen->get_video_param(screen, prof, PIPE_VIDEO_CAP_MAX_WIDTH); + max_height = screen->get_video_param(screen, prof, PIPE_VIDEO_CAP_MAX_HEIGHT); + if (vmixer->video_width < 48 || + vmixer->video_width > max_width) { + VDPAU_MSG(VDPAU_TRACE, "[VDPAU] 48 < %u < %u not valid for width\n", vmixer->video_width, max_width); + goto no_params; + } + if (vmixer->video_height < 48 || + vmixer->video_height > max_height) { + VDPAU_MSG(VDPAU_TRACE, "[VDPAU] 48 < %u < %u not valid for height\n", vmixer->video_height, max_height); + goto no_params; + } return VDP_STATUS_OK; +no_params: + vlRemoveDataHTAB(*mixer); no_handle: + vl_compositor_cleanup(&vmixer->compositor); + FREE(vmixer); return ret; } @@ -100,6 +143,7 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer) vmixer = vlGetDataHTAB(mixer); if (!vmixer) return VDP_STATUS_INVALID_HANDLE; + vlRemoveDataHTAB(mixer); vl_compositor_cleanup(&vmixer->compositor); @@ -133,6 +177,18 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer, return VDP_STATUS_OK; } +static VdpStatus +check_video_surface(vlVdpVideoMixer *mixer, vlVdpSurface *surf) +{ + if (surf->device != mixer->device) + return VDP_STATUS_HANDLE_DEVICE_MISMATCH; + if (mixer->video_width > surf->video_buffer->width || + mixer->video_height > surf->video_buffer->height || + mixer->chroma_format != surf->video_buffer->chroma_format) + return VDP_STATUS_INVALID_SIZE; + return VDP_STATUS_OK; +} + /** * Perform a video post-processing and compositing operation. */ @@ -153,6 +209,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer, VdpLayer const *layers) { struct pipe_video_rect src_rect, dst_rect, dst_clip; + VdpStatus ret; vlVdpVideoMixer *vmixer; vlVdpSurface *surf; @@ -165,6 +222,11 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer, surf = vlGetDataHTAB(video_surface_current); if (!surf) return VDP_STATUS_INVALID_HANDLE; + ret = check_video_surface(vmixer, surf); + if (ret) + return ret; + if (layer_count > vmixer->max_layers) + return VDP_STATUS_INVALID_VALUE; dst = vlGetDataHTAB(destination_surface); if (!dst) @@ -237,7 +299,34 @@ vlVdpVideoMixerGetParameterValues(VdpVideoMixer mixer, VdpVideoMixerParameter const *parameters, void *const *parameter_values) {
[Mesa-dev] [PATCH 2/3] vdpau: Add support for mixer attributes
It's harmless to add support for attributes we don't support, since they require a feature enabled for them to affect something. As long as they aren't enabled, nothing happens. This enables support for custom colorspaces and background colors. Signed-off-by: Maarten Lankhorst --- src/gallium/state_trackers/vdpau/mixer.c | 125 +++--- src/gallium/state_trackers/vdpau/query.c | 37 ++- src/gallium/state_trackers/vdpau/vdpau_private.h |4 +- 3 files changed, 149 insertions(+), 17 deletions(-) diff --git a/src/gallium/state_trackers/vdpau/mixer.c b/src/gallium/state_trackers/vdpau/mixer.c index 276f5d5..a05ad57 100644 --- a/src/gallium/state_trackers/vdpau/mixer.c +++ b/src/gallium/state_trackers/vdpau/mixer.c @@ -48,7 +48,6 @@ vlVdpVideoMixerCreate(VdpDevice device, { vlVdpVideoMixer *vmixer = NULL; VdpStatus ret; - float csc[16]; struct pipe_screen *screen; unsigned max_width, max_height, i; enum pipe_video_profile prof = PIPE_VIDEO_PROFILE_UNKNOWN; @@ -67,13 +66,9 @@ vlVdpVideoMixerCreate(VdpDevice device, vmixer->device = dev; vl_compositor_init(&vmixer->compositor, dev->context->pipe); - vl_csc_get_matrix - ( - debug_get_bool_option("G3DVL_NO_CSC", FALSE) ? - VL_CSC_COLOR_STANDARD_IDENTITY : VL_CSC_COLOR_STANDARD_BT_601, - NULL, true, csc - ); - vl_compositor_set_csc_matrix(&vmixer->compositor, csc); + vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_BT_601, NULL, true, vmixer->csc); + if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE)) + vl_compositor_set_csc_matrix(&vmixer->compositor, vmixer->csc); /* * TODO: Handle features @@ -120,6 +115,10 @@ vlVdpVideoMixerCreate(VdpDevice device, VDPAU_MSG(VDPAU_TRACE, "[VDPAU] 48 < %u < %u not valid for height\n", vmixer->video_height, max_height); goto no_params; } + vmixer->luma_key_min = 0.f; + vmixer->luma_key_max = 1.f; + vmixer->noise_reduction_level = 0.f; + vmixer->sharpness = 0.f; return VDP_STATUS_OK; no_params: @@ -178,7 +177,7 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer, } static VdpStatus -check_video_surface(vlVdpVideoMixer *mixer, vlVdpSurface *surf) +vl_check_video_surface(vlVdpVideoMixer *mixer, vlVdpSurface *surf) { if (surf->device != mixer->device) return VDP_STATUS_HANDLE_DEVICE_MISMATCH; @@ -222,7 +221,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer, surf = vlGetDataHTAB(video_surface_current); if (!surf) return VDP_STATUS_INVALID_HANDLE; - ret = check_video_surface(vmixer, surf); + ret = vl_check_video_surface(vmixer, surf); if (ret) return ret; if (layer_count > vmixer->max_layers) @@ -252,6 +251,12 @@ vlVdpVideoMixerSetAttributeValues(VdpVideoMixer mixer, VdpVideoMixerAttribute const *attributes, void const *const *attribute_values) { + const VdpColor *background_color; + union pipe_color_union color; + const float *vdp_csc; + float val; + unsigned i; + if (!(attributes && attribute_values)) return VDP_STATUS_INVALID_POINTER; @@ -259,9 +264,59 @@ vlVdpVideoMixerSetAttributeValues(VdpVideoMixer mixer, if (!vmixer) return VDP_STATUS_INVALID_HANDLE; - /* -* TODO: Implement the function -*/ + for (i = 0; i < attribute_count; ++i) { + switch (attributes[i]) { + case VDP_VIDEO_MIXER_ATTRIBUTE_BACKGROUND_COLOR: + background_color = attribute_values[i]; + color.f[0] = background_color->red; + color.f[1] = background_color->green; + color.f[2] = background_color->blue; + color.f[3] = background_color->alpha; + vl_compositor_set_clear_color(&vmixer->compositor, &color); + break; + case VDP_VIDEO_MIXER_ATTRIBUTE_CSC_MATRIX: + vdp_csc = attribute_values[i]; + vmixer->custom_csc = !!vdp_csc; + if (!vdp_csc) +vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_BT_601, NULL, 1, vmixer->csc); + else +memcpy(vmixer->csc, vdp_csc, sizeof(float)*12); + if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE)) +vl_compositor_set_csc_matrix(&vmixer->compositor, vmixer->csc); + break; + case VDP_VIDEO_MIXER_ATTRIBUTE_NOISE_REDUCTION_LEVEL: + val = *(float*)attribute_values[i]; + if (val < 0.f || val > 1.f) +return VDP_STATUS_INVALID_VALUE; + vmixer->noise_reduction_level = val; + break; + case VDP_VIDEO_MIXER_ATTRIBUTE_LUMA_KEY_MIN_LUMA: + val = *(float*)attribute_values[i]; + if (val < 0.f || val > 1.f) +return VDP_STATUS_INVALID_VALUE; + vmixer->luma_key_min = val; + break; + case VDP_VIDEO_MIXER_ATTRIBUTE_LUMA_KEY_MAX_LUMA: + val = *(float*)attribute_values[i]; + if (val < 0.f || val > 1.f) +return VDP_STATUS_INVALID_VALUE; + vmixer->luma_key_max = va
[Mesa-dev] [PATCH 3/3] vdpau: Add background surface support
Sets rgba layer as zeroth layer if a custom background_surface is specified. Signed-off-by: Maarten Lankhorst --- Can be applied without dependency on previous 2 patches in this series src/gallium/state_trackers/vdpau/mixer.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/src/gallium/state_trackers/vdpau/mixer.c b/src/gallium/state_trackers/vdpau/mixer.c index a05ad57..cd15739 100644 --- a/src/gallium/state_trackers/vdpau/mixer.c +++ b/src/gallium/state_trackers/vdpau/mixer.c @@ -209,6 +209,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer, { struct pipe_video_rect src_rect, dst_rect, dst_clip; VdpStatus ret; + unsigned layer = 0; vlVdpVideoMixer *vmixer; vlVdpSurface *surf; @@ -231,8 +232,16 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer, if (!dst) return VDP_STATUS_INVALID_HANDLE; + if (background_surface != VDP_INVALID_HANDLE) { + vlVdpOutputSurface *bg = vlGetDataHTAB(background_surface); + if (!bg) + return VDP_STATUS_INVALID_HANDLE; + vl_compositor_set_rgba_layer(&vmixer->compositor, layer++, bg->sampler_view, + RectToPipe(background_source_rect, &src_rect), NULL); + } + vl_compositor_clear_layers(&vmixer->compositor); - vl_compositor_set_buffer_layer(&vmixer->compositor, 0, surf->video_buffer, + vl_compositor_set_buffer_layer(&vmixer->compositor, layer, surf->video_buffer, RectToPipe(video_source_rect, &src_rect), NULL); vl_compositor_render(&vmixer->compositor, dst->surface, RectToPipe(destination_video_rect, &dst_rect), -- 1.7.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: block attempt to swapbuffer on pixmap. (v2)
On Wed, Dec 7, 2011 at 6:32 PM, Eric Anholt wrote: > On Wed, 7 Dec 2011 10:24:09 +, Dave Airlie wrote: >> From: Dave Airlie >> >> This keeps track of the creation process and stores a drawable type, >> it then blocks DRI2 from getting called if the drawable is a pixmap. >> >> v2: check if we have a GLX drawable, which means we aren't a pbuffer, >> avoid doing flush at all since its meant to be a no-op. > > I still think this is the wrong way to go. As ajax pointed out, there's > all sorts of races available from trying to guess client-side, and > there's no way anybody's relying on the current ("print an error message > in the xorg log") behavior of the DRI2 protocol for single-buffered, so > we might as well resolve that DRI2 protocol should do what we want for > GLX. I've been thinking about the races, and I'm not sure they really apply, like we would have all those races now with the current code, Look at the patch, when the glx_drawable struct is created we record the type of the pixmap, we then call GetGLXDrawable, which looks the XID up in the hash, so if the XID has been reused or raced, then we would have to expect the hash to be incorrect, or else avoid using it in a lot of other places. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] egl: move unofficial extensions to eglmesaext.h
From: Chia-I Wu As suggested by Ian in http://lists.freedesktop.org/archives/mesa-dev/2011-December/016035.html Note that eglext.h has to include eglmesaext.h at the end instead of the beginning because some extensions in eglmesaext.h depend on the official extensions. --- include/EGL/eglext.h | 137 +--- include/EGL/eglmesaext.h | 175 ++ 2 files changed, 176 insertions(+), 136 deletions(-) create mode 100644 include/EGL/eglmesaext.h diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h index 9484b83..800a23d 100644 --- a/include/EGL/eglext.h +++ b/include/EGL/eglext.h @@ -120,43 +120,6 @@ typedef EGLBoolean (EGLAPIENTRYP PFNEGLDESTROYIMAGEKHRPROC) (EGLDisplay dpy, EGL #define EGL_GL_RENDERBUFFER_KHR0x30B9 /* eglCreateImageKHR target */ #endif -#ifndef EGL_MESA_drm_image -#define EGL_MESA_drm_image 1 -#define EGL_DRM_BUFFER_FORMAT_MESA 0x31D0 /* eglCreateImageKHR attribute */ -#define EGL_DRM_BUFFER_USE_MESA0x31D1 - -/* EGL_DRM_BUFFER_FORMAT_MESA tokens */ -#define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 0x31D2 - -/* EGL_DRM_BUFFER_USE_MESA bits */ -#define EGL_DRM_BUFFER_USE_SCANOUT_MESA0x0001 -#define EGL_DRM_BUFFER_USE_SHARE_MESA 0x0002 -#define EGL_DRM_BUFFER_USE_CURSOR_MESA 0x0004 - -#define EGL_DRM_BUFFER_MESA0x31D3 /* eglCreateImageKHR target */ -#define EGL_DRM_BUFFER_STRIDE_MESA 0x31D4 /* eglCreateImageKHR attribute */ - -#ifdef EGL_EGLEXT_PROTOTYPES -EGLAPI EGLImageKHR EGLAPIENTRY eglCreateDRMImageMESA(EGLDisplay dpy, const EGLint *attrib_list); -EGLAPI EGLBoolean EGLAPIENTRY eglExportDRMImageMESA(EGLDisplay dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride); -#endif -typedef EGLImageKHR (EGLAPIENTRYP PFNEGLCREATEDRMIMAGEMESA) (EGLDisplay dpy, const EGLint *attrib_list); -typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESA) (EGLDisplay dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride); -#endif - -#ifndef EGL_WL_bind_wayland_display -#define EGL_WL_bind_wayland_display 1 - -#define EGL_WAYLAND_BUFFER_WL 0x31D5 /* eglCreateImageKHR target */ -struct wl_display; -#ifdef EGL_EGLEXT_PROTOTYPES -EGLAPI EGLBoolean EGLAPIENTRY eglBindWaylandDisplayWL(EGLDisplay dpy, struct wl_display *display); -EGLAPI EGLBoolean EGLAPIENTRY eglUnbindWaylandDisplayWL(EGLDisplay dpy, struct wl_display *display); -#endif -typedef EGLBoolean (EGLAPIENTRYP PFNEGLBINDWAYLANDDISPLAYWL) (EGLDisplay dpy, struct wl_display *display); -typedef EGLBoolean (EGLAPIENTRYP PFNEGLUNBINDWAYLANDDISPLAYWL) (EGLDisplay dpy, struct wl_display *display); -#endif - #if KHRONOS_SUPPORT_INT64 /* EGLTimeKHR requires 64-bit uint support */ #ifndef EGL_KHR_reusable_sync #define EGL_KHR_reusable_sync 1 @@ -189,75 +152,6 @@ typedef EGLBoolean (EGLAPIENTRYP PFNEGLGETSYNCATTRIBKHRPROC) (EGLDisplay dpy, EG #endif #endif -/* EGL_MESA_screen extension >>> PRELIMINARY <<< */ -#ifndef EGL_MESA_screen_surface -#define EGL_MESA_screen_surface 1 - -#define EGL_BAD_SCREEN_MESA0x4000 -#define EGL_BAD_MODE_MESA 0x4001 -#define EGL_SCREEN_COUNT_MESA 0x4002 -#define EGL_SCREEN_POSITION_MESA 0x4003 -#define EGL_SCREEN_POSITION_GRANULARITY_MESA 0x4004 -#define EGL_MODE_ID_MESA 0x4005 -#define EGL_REFRESH_RATE_MESA 0x4006 -#define EGL_OPTIMAL_MESA 0x4007 -#define EGL_INTERLACED_MESA0x4008 -#define EGL_SCREEN_BIT_MESA0x08 - -typedef khronos_uint32_t EGLScreenMESA; -typedef khronos_uint32_t EGLModeMESA; - -#ifdef EGL_EGLEXT_PROTOTYPES -EGLAPI EGLBoolean EGLAPIENTRY eglChooseModeMESA(EGLDisplay dpy, EGLScreenMESA screen, const EGLint *attrib_list, EGLModeMESA *modes, EGLint modes_size, EGLint *num_modes); -EGLAPI EGLBoolean EGLAPIENTRY eglGetModesMESA(EGLDisplay dpy, EGLScreenMESA screen, EGLModeMESA *modes, EGLint modes_size, EGLint *num_modes); -EGLAPI EGLBoolean EGLAPIENTRY eglGetModeAttribMESA(EGLDisplay dpy, EGLModeMESA mode, EGLint attribute, EGLint *value); -EGLAPI EGLBoolean EGLAPIENTRY eglGetScreensMESA(EGLDisplay dpy, EGLScreenMESA *screens, EGLint max_screens, EGLint *num_screens); -EGLAPI EGLSurface EGLAPIENTRY eglCreateScreenSurfaceMESA(EGLDisplay dpy, EGLConfig config, const EGLint *attrib_list); -EGLAPI EGLBoolean EGLAPIENTRY eglShowScreenSurfaceMESA(EGLDisplay dpy, EGLint screen, EGLSurface surface, EGLModeMESA mode); -EGLAPI EGLBoolean EGLAPIENTRY eglScreenPositionMESA(EGLDisplay dpy, EGLScreenMESA screen, EGLint x, EGLint y); -EGLAPI EGLBoolean EGLAPIENTRY eglQueryScreenMESA(EGLDisplay dpy, EGLScreenMESA screen, EGLint attribute, EGLint *value); -EGLAPI EGLBoolean EGLAPIENTRY eglQueryScreenSurfaceMESA(EGLDisplay dpy, EGLScreenMESA screen, EGLSurface *surface); -EG
[Mesa-dev] [PATCH 2/2] egl: update headers
From: Chia-I Wu Update to revision 15052. EGL_MESA_drm_image is now official. But apparently we have our own extension to it and we need this in eglmesaext.h: #ifdef EGL_MESA_drm_image /* Mesa's extension to EGL_MESA_drm_image... */ #ifndef EGL_DRM_BUFFER_USE_CURSOR_MESA #define EGL_DRM_BUFFER_USE_CURSOR_MESA0x0004 #endif #endif --- include/EGL/eglext.h | 65 +++- include/EGL/eglmesaext.h | 23 ++-- include/EGL/eglplatform.h |9 +- 3 files changed, 73 insertions(+), 24 deletions(-) diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h index 800a23d..a7ea2ea 100644 --- a/include/EGL/eglext.h +++ b/include/EGL/eglext.h @@ -34,8 +34,8 @@ extern "C" { /* Header file version number */ /* Current version at http://www.khronos.org/registry/egl/ */ -/* $Revision: 12124 $ on $Date: 2010-07-27 20:12:35 -0700 (Tue, 27 Jul 2010) $ */ -#define EGL_EGLEXT_VERSION 7 +/* $Revision: 15052 $ on $Date: 2011-07-06 17:43:46 -0700 (Wed, 06 Jul 2011) $ */ +#define EGL_EGLEXT_VERSION 10 #ifndef EGL_KHR_config_attribs #define EGL_KHR_config_attribs 1 @@ -267,6 +267,67 @@ typedef EGLSurface (EGLAPIENTRYP PFNEGLCREATEPIXMAPSURFACEHIPROC) (EGLDisplay dp #define EGL_COLOR_ARGB_HI 0x8F73 #endif /* EGL_HI_colorformats */ +#ifndef EGL_MESA_drm_image +#define EGL_MESA_drm_image 1 +#define EGL_DRM_BUFFER_FORMAT_MESA 0x31D0 /* CreateDRMImageMESA attribute */ +#define EGL_DRM_BUFFER_USE_MESA0x31D1 /* CreateDRMImageMESA attribute */ +#define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 0x31D2 /* EGL_IMAGE_FORMAT_MESA attribute value */ +#define EGL_DRM_BUFFER_MESA0x31D3 /* eglCreateImageKHR target */ +#define EGL_DRM_BUFFER_STRIDE_MESA 0x31D4 +#define EGL_DRM_BUFFER_USE_SCANOUT_MESA0x0001 /* EGL_DRM_BUFFER_USE_MESA bits */ +#define EGL_DRM_BUFFER_USE_SHARE_MESA 0x0002 /* EGL_DRM_BUFFER_USE_MESA bits */ +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI EGLImageKHR EGLAPIENTRY eglCreateDRMImageMESA (EGLDisplay dpy, const EGLint *attrib_list); +EGLAPI EGLBoolean EGLAPIENTRY eglExportDRMImageMESA (EGLDisplay dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride); +#endif /* EGL_EGLEXT_PROTOTYPES */ +typedef EGLImageKHR (EGLAPIENTRYP PFNEGLCREATEDRMIMAGEMESAPROC) (EGLDisplay dpy, const EGLint *attrib_list); +typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESAPROC) (EGLDisplay dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride); +#endif + +#ifndef EGL_NV_post_sub_buffer +#define EGL_NV_post_sub_buffer 1 +#define EGL_POST_SUB_BUFFER_SUPPORTED_NV 0x30BE +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI EGLBoolean EGLAPIENTRY eglPostSubBufferNV (EGLDisplay dpy, EGLSurface surface, EGLint x, EGLint y, EGLint width, EGLint height); +#endif /* EGL_EGLEXT_PROTOTYPES */ +typedef EGLBoolean (EGLAPIENTRYP PFNEGLPOSTSUBBUFFERNVPROC) (EGLDisplay dpy, EGLSurface surface, EGLint x, EGLint y, EGLint width, EGLint height); +#endif + +#ifndef EGL_ANGLE_query_surface_pointer +#define EGL_ANGLE_query_surface_pointer 1 +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI EGLBoolean eglQuerySurfacePointerANGLE(EGLDisplay dpy, EGLSurface surface, EGLint attribute, void **value); +#endif +typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYSURFACEPOINTERANGLEPROC) (EGLDisplay dpy, EGLSurface surface, EGLint attribute, void **value); +#endif + +#ifndef EGL_ANGLE_surface_d3d_texture_2d_share_handle +#define EGL_ANGLE_surface_d3d_texture_2d_share_handle 1 +#define EGL_D3D_TEXTURE_2D_SHARE_HANDLE_ANGLE 0x3200 +#endif + +#ifndef EGL_NV_coverage_sample_resolve +#define EGL_NV_coverage_sample_resolve 1 +#define EGL_COVERAGE_SAMPLE_RESOLVE_NV 0x3131 +#define EGL_COVERAGE_SAMPLE_RESOLVE_DEFAULT_NV 0x3132 +#define EGL_COVERAGE_SAMPLE_RESOLVE_NONE_NV0x3133 +#endif + +#if KHRONOS_SUPPORT_INT64 /* EGLTimeKHR requires 64-bit uint support */ +#ifndef EGL_NV_system_time +#define EGL_NV_system_time 1 + +typedef khronos_utime_nanoseconds_t EGLuint64NV; + +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI EGLuint64NV EGLAPIENTRY eglGetSystemTimeFrequencyNV(void); +EGLAPI EGLuint64NV EGLAPIENTRY eglGetSystemTimeNV(void); +#endif /* EGL_EGLEXT_PROTOTYPES */ +typedef EGLuint64NV (EGLAPIENTRYP PFNEGLGETSYSTEMTIMEFREQUENCYNVPROC) (void); +typedef EGLuint64NV (EGLAPIENTRYP PFNEGLGETSYSTEMTIMENVPROC) (void); +#endif +#endif + #include #ifdef __cplusplus diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h index 1b83778..53576ba 100644 --- a/include/EGL/eglmesaext.h +++ b/include/EGL/eglmesaext.h @@ -102,28 +102,11 @@ typedef EGLDisplay (EGLAPIENTRYP PFNEGLGETDRMDISPLAYMESA) (int fd); #endif /* EGL_MESA_drm_display */ -#ifndef EGL_MESA_drm_image -#define EGL_MESA_drm_image 1 -#define EGL_DRM_BUFFER_FORMAT_MESA 0x31D0 /* eglCreateImageKHR attribute */ -#define EGL_DRM_BUFFER_USE_MESA
[Mesa-dev] [PATCH 1/2] softpipe: fix shadow 2d texture array sampling
From: Dave Airlie The 4th texcoord is used in this case for the comparison. This fixes piglit glsl-fs-shadow2DArray* on softpipe. Signed-off-by: Dave Airlie --- src/gallium/auxiliary/tgsi/tgsi_exec.c | 11 ++- src/gallium/drivers/softpipe/sp_tex_sample.c | 17 - 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c index a44ba80..4115e35 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_exec.c +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c @@ -1822,7 +1822,6 @@ exec_tex(struct tgsi_exec_machine *mach, break; case TGSI_TEXTURE_2D_ARRAY: - case TGSI_TEXTURE_SHADOW2D_ARRAY: FETCH(&r[0], 0, CHAN_X); FETCH(&r[1], 0, CHAN_Y); FETCH(&r[2], 0, CHAN_Z); @@ -1837,7 +1836,17 @@ exec_tex(struct tgsi_exec_machine *mach, control, &r[0], &r[1], &r[2], &r[3]); /* outputs */ break; + case TGSI_TEXTURE_SHADOW2D_ARRAY: + FETCH(&r[0], 0, CHAN_X); + FETCH(&r[1], 0, CHAN_Y); + FETCH(&r[2], 0, CHAN_Z); + FETCH(&r[3], 0, CHAN_W); + fetch_texel(mach->Samplers[unit], + &r[0], &r[1], &r[2], &r[3], /* S, T, P, LOD */ + control, + &r[0], &r[1], &r[2], &r[3]); /* outputs */ + break; case TGSI_TEXTURE_3D: case TGSI_TEXTURE_CUBE: FETCH(&r[0], 0, CHAN_X); diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c b/src/gallium/drivers/softpipe/sp_tex_sample.c index 43f201f..8123d7b 100644 --- a/src/gallium/drivers/softpipe/sp_tex_sample.c +++ b/src/gallium/drivers/softpipe/sp_tex_sample.c @@ -2113,15 +2113,22 @@ sample_compare(struct tgsi_sampler *tgsi_sampler, /** * Compare texcoord 'p' (aka R) against texture value 'rgba[0]' +* for 2D Array texture we need to use the 'c0' (aka Q). * When we sampled the depth texture, the depth value was put into all * RGBA channels. We look at the red channel here. */ - pc0 = CLAMP(p[0], 0.0F, 1.0F); - pc1 = CLAMP(p[1], 0.0F, 1.0F); - pc2 = CLAMP(p[2], 0.0F, 1.0F); - pc3 = CLAMP(p[3], 0.0F, 1.0F); - + if (samp->view->texture->target == PIPE_TEXTURE_2D_ARRAY) { + pc0 = CLAMP(c0[0], 0.0F, 1.0F); + pc1 = CLAMP(c0[1], 0.0F, 1.0F); + pc2 = CLAMP(c0[2], 0.0F, 1.0F); + pc3 = CLAMP(c0[3], 0.0F, 1.0F); + } else { + pc0 = CLAMP(p[0], 0.0F, 1.0F); + pc1 = CLAMP(p[1], 0.0F, 1.0F); + pc2 = CLAMP(p[2], 0.0F, 1.0F); + pc3 = CLAMP(p[3], 0.0F, 1.0F); + } /* compare four texcoords vs. four texture samples */ switch (sampler->compare_func) { case PIPE_FUNC_LESS: -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] softpipe: fix shadow1d tests.
From: Dave Airlie This fixes the piglit glsl-1.10 shadow1D related tests. Signed-off-by: Dave Airlie --- src/gallium/auxiliary/tgsi/tgsi_exec.c | 14 +- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c index 4115e35..8df81d1 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_exec.c +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c @@ -1760,7 +1760,6 @@ exec_tex(struct tgsi_exec_machine *mach, switch (inst->Texture.Texture) { case TGSI_TEXTURE_1D: - case TGSI_TEXTURE_SHADOW1D: FETCH(&r[0], 0, CHAN_X); if (modifier == TEX_MODIFIER_PROJECTED) { @@ -1772,6 +1771,19 @@ exec_tex(struct tgsi_exec_machine *mach, control, &r[0], &r[1], &r[2], &r[3]); /* R, G, B, A */ break; + case TGSI_TEXTURE_SHADOW1D: + FETCH(&r[0], 0, CHAN_X); + FETCH(&r[2], 0, CHAN_Z); + + if (modifier == TEX_MODIFIER_PROJECTED) { + micro_div(&r[0], &r[0], &r[3]); + } + + fetch_texel(mach->Samplers[unit], + &r[0], &ZeroVec, &r[2], lod, /* S, T, P, LOD */ + control, + &r[0], &r[1], &r[2], &r[3]); /* R, G, B, A */ + break; case TGSI_TEXTURE_2D: case TGSI_TEXTURE_RECT: -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Maarten Lankhorst wrote: Looks like I made the checking a bit too paranoid, causing it to not always decode last few macroblocks because of fear of reaching end of stream.. Does this work? I removed a few paranoid asserts, and if performance is still bad, I'll alter the patch to swap between multiple decode buffers to fix it. That should bring performance back to old level. This version does fix the macroblocks issue. Perf is still poor. The dvd assert is also still present. It doesn't happen with all dvds - and is not a regression caused by this patch. When playing with -cache and skipping around I get a different assert - attached are backtraces from both types. mplayer: vl/vl_vlc.h:172: vl_vlc_get_vlclbf: Assertion `tbl->length' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0xb6b49a10 (LWP 6986)] 0xe424 in __kernel_vsyscall () (gdb) bt full #0 0xe424 in __kernel_vsyscall () No symbol table info available. #1 0xb6d0715a in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb6d08787 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb6d0069e in __assert_fail () from /lib/libc.so.6 No symbol table info available. #4 0xb5de9573 in motion_vector (bs=0xab51c50, r=, s=, dmv=0, delta=0xbfc0e2d4, dmvector=0xbfc0e2d0) at vl/vl_vlc.h:172 t = 1 __PRETTY_FUNCTION__ = "motion_vector" #5 0xb5deab7f in decode_slice (bs=0xab51c50, code=) at vl/vl_mpeg12_bitstream.c:679 inc = 4 mb = {base = {codec = PIPE_VIDEO_CODEC_MPEG12}, x = 28, y = 1, macroblock_type = 10 '\n', macroblock_modes = {bits = {frame_motion_type = 2, field_motion_type = 0, dct_type = 0}, value = 2}, motion_vertical_field_select = 0 '\0', PMV = {{{0, 0}, {0, 0}}, {{0, 0}, {0, 0}}}, coded_block_pattern = 58, blocks = 0xbfc0dfa4, num_skipped_macroblocks = 3} dct_blocks = {0, 0, -44, -44, -44, 44, 0 , -44, -44, 44, -44, 44, 0, 44, -44, 0 , 44, 44, 0, 0, 44, 0, 0, 0, 0, 44, -132, 0, 0, 0, 0, 0, 0, 0, -44, 0 , 9220, -44, 0, 0, 0, 0, -44, 0 } dct_scale = 44 x = __PRETTY_FUNCTION__ = "decode_slice" #6 0xb5deb72b in vl_mpg12_bs_decode (bs=0xab51c50, n=, len=107065, lens=0xbfc0e390, buffer=0xbfc0e3b0) at vl/vl_mpeg12_bitstream.c:982 __PRETTY_FUNCTION__ = "vl_mpg12_bs_decode" #7 0xb5de808b in vl_mpeg12_decode_bitstream (decoder=0xaab5f98, target=0xaac3c70, picture=0xbfc0e3f8, n=1, total_len=107065, lens=0xbfc0e390, data=0xbfc0e3b0) at vl/vl_mpeg12_decoder.c:707 i = 3 __PRETTY_FUNCTION__ = "vl_mpeg12_decode_bitstream" #8 0xb5d84dd4 in vlVdpDecoderRender (decoder=9, target=19, picture_info=0x8ae38b4, bitstream_buffer_count=1, bitstream_buffers=0xaac3330) at decode.c:382 total_size = 107065 ret = VDP_STATUS_OK dec = (struct pipe_video_decoder *) 0xaab5f98 i = 6986 desc = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, mpeg12 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0xaabb7f8, ref_backward = 0x0, picture_coding_type = 2, picture_structure = 3, frame_pred_frame_dct = 1, q_scale_type = 1, alternate_scan = 0, intra_vlc_format = 1, concealment_motion_vectors = 0, intra_dc_precision = 2, f_code = {{5, 5}, {14, 14}}, top_field_first = 1, full_pel_forward_vector = 0, full_pel_backward_vector = 0, num_slices = 35, intra_matrix = 0x8ae38cf "\b\b\b\b\b\b\b\t\b\b\b\b\b\b\t\t\b\b\b\b\b\t\t\n\b\b\b\b\b\t\t\n\b\b\b\b\b\t\n\f\b\b\b\b\t\n\f\017\b\b\b\t\n\f\016\021\b\b\t\n\f\016\021\025", '\b' , non_intra_matrix = 0x8ae390f '\b' }, mpeg4 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0xaabb7f8, ref_backward = 0x0, trd = {2, 3}, trb = {1, 1}, vop_time_increment_resolution = 0, vop_coding_type = 0 '\0', vop_fcode_forward = 0 '\0', vop_fcode_backward = 1 '\001', resync_marker_disable = 0 '\0', interlaced = 0 '\0', quant_type = 0 '\0', quarter_sample = 0 '\0', short_video_header = 0 '\0', rounding_control = 0 '\0', alternate_vertical_scan_flag = 0 '\0', top_field_first = 2 '\002', intra_matrix = 0x5 , non_intra_matrix = 0x5 }, vc1 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0xaabb7f8, ref_backward = 0x0, slice_count = 2, picture_type = 3 '\003', frame_coding_mode = 0 '\0', postprocflag = 0 '\0', pulldown = 0 '\0', interlace = 1 '\001', tfcntrflag = 0 '\0', finterpflag = 0 '\0', psf = 0 '\0', dquant = 1 '\001', panscan_flag = 0 '\0', refdist_flag = 0 '\0', quantizer = 0 '\0', extended_mv = 0 '\0', extended_dmv = 0 '\0', overlap = 0 '\0', vstransform = 0 '\0', loopfilter = 1 '\001', fastuvmc = 0 '\0', range_mapy_flag = 0 '\0', range_mapy = 0 '\0', range_mapuv_flag = 0 '\0', range_mapuv = 0 '\0', multires = 0 '\0', syncmarker = 0 '\0', rangered = 2 '\002', maxbframes = 0 '\0', deblockEnable = 0 '\0', pquant = 0 '\0'}} #9 0x080f9855 in draw_slice (image=0xbfc0e4cc, stride=0xbfc0e4bc, w=720, h=576, x=0, y=0) at libvo/vo_vdpau.c:995
Re: [Mesa-dev] [PATCH 1/3] vdpau: Add support for parameters
Committed all three with just a minor change: removed check_video_surface in favor of doing the checks directly in the render function. On 19.12.2011 10:10, Maarten Lankhorst wrote: Currently only validating, since nothing else can be done with it yet Signed-off-by: Maarten Lankhorst --- src/gallium/state_trackers/vdpau/mixer.c | 95 +- src/gallium/state_trackers/vdpau/query.c | 41 +- src/gallium/state_trackers/vdpau/vdpau_private.h |3 + 3 files changed, 133 insertions(+), 6 deletions(-) diff --git a/src/gallium/state_trackers/vdpau/mixer.c b/src/gallium/state_trackers/vdpau/mixer.c index 1588744..276f5d5 100644 --- a/src/gallium/state_trackers/vdpau/mixer.c +++ b/src/gallium/state_trackers/vdpau/mixer.c @@ -49,12 +49,16 @@ vlVdpVideoMixerCreate(VdpDevice device, vlVdpVideoMixer *vmixer = NULL; VdpStatus ret; float csc[16]; + struct pipe_screen *screen; + unsigned max_width, max_height, i; + enum pipe_video_profile prof = PIPE_VIDEO_PROFILE_UNKNOWN; VDPAU_MSG(VDPAU_TRACE, "[VDPAU] Creating VideoMixer\n"); vlVdpDevice *dev = vlGetDataHTAB(device); if (!dev) return VDP_STATUS_INVALID_HANDLE; + screen = dev->vscreen->pscreen; vmixer = CALLOC(1, sizeof(vlVdpVideoMixer)); if (!vmixer) @@ -72,7 +76,7 @@ vlVdpVideoMixerCreate(VdpDevice device, vl_compositor_set_csc_matrix(&vmixer->compositor, csc); /* -* TODO: Handle features and parameters +* TODO: Handle features */ *mixer = vlAddDataHTAB(vmixer); @@ -80,10 +84,49 @@ vlVdpVideoMixerCreate(VdpDevice device, ret = VDP_STATUS_ERROR; goto no_handle; } - + vmixer->chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420; + ret = VDP_STATUS_INVALID_VIDEO_MIXER_PARAMETER; + for (i = 0; i< parameter_count; ++i) { + switch (parameters[i]) { + case VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_WIDTH: + vmixer->video_width = *(uint32_t*)parameter_values[i]; + break; + case VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_HEIGHT: + vmixer->video_height = *(uint32_t*)parameter_values[i]; + break; + case VDP_VIDEO_MIXER_PARAMETER_CHROMA_TYPE: + vmixer->chroma_format = ChromaToPipe(*(VdpChromaType*)parameter_values[i]); + break; + case VDP_VIDEO_MIXER_PARAMETER_LAYERS: + vmixer->max_layers = *(uint32_t*)parameter_values[i]; + break; + default: goto no_params; + } + } + ret = VDP_STATUS_INVALID_VALUE; + if (vmixer->max_layers> 4) { + VDPAU_MSG(VDPAU_TRACE, "[VDPAU] Max layers> 4 not supported\n", vmixer->max_layers); + goto no_params; + } + max_width = screen->get_video_param(screen, prof, PIPE_VIDEO_CAP_MAX_WIDTH); + max_height = screen->get_video_param(screen, prof, PIPE_VIDEO_CAP_MAX_HEIGHT); + if (vmixer->video_width< 48 || + vmixer->video_width> max_width) { + VDPAU_MSG(VDPAU_TRACE, "[VDPAU] 48< %u< %u not valid for width\n", vmixer->video_width, max_width); + goto no_params; + } + if (vmixer->video_height< 48 || + vmixer->video_height> max_height) { + VDPAU_MSG(VDPAU_TRACE, "[VDPAU] 48< %u< %u not valid for height\n", vmixer->video_height, max_height); + goto no_params; + } return VDP_STATUS_OK; +no_params: + vlRemoveDataHTAB(*mixer); no_handle: + vl_compositor_cleanup(&vmixer->compositor); + FREE(vmixer); return ret; } @@ -100,6 +143,7 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer) vmixer = vlGetDataHTAB(mixer); if (!vmixer) return VDP_STATUS_INVALID_HANDLE; + vlRemoveDataHTAB(mixer); vl_compositor_cleanup(&vmixer->compositor); @@ -133,6 +177,18 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer, return VDP_STATUS_OK; } +static VdpStatus +check_video_surface(vlVdpVideoMixer *mixer, vlVdpSurface *surf) +{ + if (surf->device != mixer->device) + return VDP_STATUS_HANDLE_DEVICE_MISMATCH; + if (mixer->video_width> surf->video_buffer->width || + mixer->video_height> surf->video_buffer->height || + mixer->chroma_format != surf->video_buffer->chroma_format) + return VDP_STATUS_INVALID_SIZE; + return VDP_STATUS_OK; +} + /** * Perform a video post-processing and compositing operation. */ @@ -153,6 +209,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer, VdpLayer const *layers) { struct pipe_video_rect src_rect, dst_rect, dst_clip; + VdpStatus ret; vlVdpVideoMixer *vmixer; vlVdpSurface *surf; @@ -165,6 +222,11 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer, surf = vlGetDataHTAB(video_surface_current); if (!surf) return VDP_STATUS_INVALID_HANDLE; + ret = check_video_surface(vmixer, surf); + if (ret) + return ret; + if (layer_count> vmixer->max_layers) + return VDP_STATUS_INVALID_VALUE; dst = vlGetDataHTAB(destination_surface); if (!dst) @@
[Mesa-dev] [Bug 43949] New: OSMesa does not work with 565 pixel format
https://bugs.freedesktop.org/show_bug.cgi?id=43949 Bug #: 43949 Summary: OSMesa does not work with 565 pixel format Classification: Unclassified Product: Mesa Version: 7.11 Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: agalak...@gmail.com Created attachment 54568 --> https://bugs.freedesktop.org/attachment.cgi?id=54568 Fix for 565 pixel format The following code did not work due to forgotten case statement: ctx = OSMesaCreateContext(OSMESA_RGB_565, NULL); OSMesaMakeCurrent(ctx, fb, GL_UNSIGNED_SHORT_5_6_5, 800, 480); The attached patch fixes the problem. -- 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 1/2] linker: fix strdup memory leak
On Fri, 16 Dec 2011 10:46:11 -0800 Ian Romanick wrote: > On 12/14/2011 11:26 PM, Pekka Paalanen wrote: > > string_to_uint_map::put() already does a strdup() for the key > > argument, so we leak the memory allocated by strdup() in > > link_uniforms.cpp. > > > > Remove the extra strdup(), fixes a few Valgrind detected leaks. > > Have you run piglit on this? I seem to recall adding the extra > strdup for a reason. The hash table keeps a copy of the key pointer > passed to it, and the underlying object may be deleted before the > hash table is deleted. This can happen if the back-end optimizes > some uniforms away after the linker has generated the list of > "active" uniforms. I'm pretty sure there were one or two test cases > that hit this on i965. Sorry, I didn't. Finally got piglit running, though readPixSanity failed on stencil values. Anyway it's running all.tests now for the upstream Mesa master, and then I'll run it with my patches. Oh, this is Sandybridge, btw. > > --- a/src/glsl/link_uniforms.cpp > > +++ b/src/glsl/link_uniforms.cpp > > @@ -174,8 +174,7 @@ private: > > if (this->map->get(id, name)) > > return; > > > > - char *key = strdup(name); > > - this->map->put(this->num_active_uniforms, key); > > + this->map->put(this->num_active_uniforms, name); > > > > /* Each leaf uniform occupies one entry in the list of > > active > > * uniforms. The whole visit_field() function is this: virtual void visit_field(const glsl_type *type, const char *name) { assert(!type->is_record()); assert(!(type->is_array() && type->fields.array->is_record())); /* Count the number of samplers regardless of whether the uniform is * already in the hash table. The hash table prevents adding the same * uniform for multiple shader targets, but in this case we want to * count it for each shader target. */ const unsigned values = values_for_type(type); if (type->contains_sampler()) { this->num_shader_samplers += type->is_array() ? type->array_size() : 1; } else { /* Accumulate the total number of uniform slots used by this shader. * Note that samplers do not count against this limit because they * don't use any storage on current hardware. */ this->num_shader_uniform_components += values; } /* If the uniform is already in the map, there's nothing more to do. */ unsigned id; if (this->map->get(id, name)) return; char *key = strdup(name); this->map->put(this->num_active_uniforms, key); /* Each leaf uniform occupies one entry in the list of active * uniforms. */ this->num_active_uniforms++; this->num_values += values; } The variable 'key' is not used anywhere else but passed to string_to_uint_map::put(). That function in its whole is: void put(unsigned value, const char *key) { /* The low-level hash table structure returns NULL if key is not in the * hash table. However, users of this map might want to store zero as a * valid value in the table. Bias the value by +1 so that a * user-specified zero is stored as 1. This enables ::get to tell the * difference between a user-specified zero (returned as 1 by * hash_table_find) and the key not in the table (returned as 0 by * hash_table_find). * * The net effect is that we can't store UINT_MAX in the table. This is * because UINT_MAX+1 = 0. */ assert(value != UINT_MAX); hash_table_replace(this->ht, (void *) (intptr_t) (value + 1), strdup(key)); } Therefore, as far as I see, 'key' is not used for anything else than passed again through strdup(), which would effectively be: hash_table_replace(..., ..., strdup(strdup(name))); I don't see any case where this could not be a leak, or prevent a bug. What do I miss? Is there somewhere another put() that overwrites or overloads this version of put()? Thanks, pq ps. As for the other patch, thanks for the advice on how to fix it properly. I don't think I can do that this year, though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] softpipe: fix shadow1d tests.
On 12/19/2011 04:53 AM, Dave Airlie wrote: From: Dave Airlie This fixes the piglit glsl-1.10 shadow1D related tests. Signed-off-by: Dave Airlie --- src/gallium/auxiliary/tgsi/tgsi_exec.c | 14 +- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c index 4115e35..8df81d1 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_exec.c +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c @@ -1760,7 +1760,6 @@ exec_tex(struct tgsi_exec_machine *mach, switch (inst->Texture.Texture) { case TGSI_TEXTURE_1D: - case TGSI_TEXTURE_SHADOW1D: FETCH(&r[0], 0, CHAN_X); if (modifier == TEX_MODIFIER_PROJECTED) { @@ -1772,6 +1771,19 @@ exec_tex(struct tgsi_exec_machine *mach, control, &r[0],&r[1],&r[2],&r[3]); /* R, G, B, A */ break; + case TGSI_TEXTURE_SHADOW1D: + FETCH(&r[0], 0, CHAN_X); + FETCH(&r[2], 0, CHAN_Z); + + if (modifier == TEX_MODIFIER_PROJECTED) { + micro_div(&r[0],&r[0],&r[3]); + } + + fetch_texel(mach->Samplers[unit], +&r[0],&ZeroVec,&r[2], lod, /* S, T, P, LOD */ + control, +&r[0],&r[1],&r[2],&r[3]); /* R, G, B, A */ + break; case TGSI_TEXTURE_2D: case TGSI_TEXTURE_RECT: That looks better. Would you mind checking that the TGSI docs properly describe which coordinate components are used for array indexing, shadow distance, etc. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] softpipe: fix shadow 2d texture array sampling
On 12/19/2011 04:53 AM, Dave Airlie wrote: From: Dave Airlie The 4th texcoord is used in this case for the comparison. This fixes piglit glsl-fs-shadow2DArray* on softpipe. Signed-off-by: Dave Airlie --- src/gallium/auxiliary/tgsi/tgsi_exec.c | 11 ++- src/gallium/drivers/softpipe/sp_tex_sample.c | 17 - 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c index a44ba80..4115e35 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_exec.c +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c @@ -1822,7 +1822,6 @@ exec_tex(struct tgsi_exec_machine *mach, break; case TGSI_TEXTURE_2D_ARRAY: - case TGSI_TEXTURE_SHADOW2D_ARRAY: FETCH(&r[0], 0, CHAN_X); FETCH(&r[1], 0, CHAN_Y); FETCH(&r[2], 0, CHAN_Z); @@ -1837,7 +1836,17 @@ exec_tex(struct tgsi_exec_machine *mach, control, &r[0],&r[1],&r[2],&r[3]); /* outputs */ break; + case TGSI_TEXTURE_SHADOW2D_ARRAY: + FETCH(&r[0], 0, CHAN_X); + FETCH(&r[1], 0, CHAN_Y); + FETCH(&r[2], 0, CHAN_Z); + FETCH(&r[3], 0, CHAN_W); + fetch_texel(mach->Samplers[unit], +&r[0],&r[1],&r[2],&r[3], /* S, T, P, LOD */ + control, +&r[0],&r[1],&r[2],&r[3]); /* outputs */ + break; case TGSI_TEXTURE_3D: case TGSI_TEXTURE_CUBE: FETCH(&r[0], 0, CHAN_X); diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c b/src/gallium/drivers/softpipe/sp_tex_sample.c index 43f201f..8123d7b 100644 --- a/src/gallium/drivers/softpipe/sp_tex_sample.c +++ b/src/gallium/drivers/softpipe/sp_tex_sample.c @@ -2113,15 +2113,22 @@ sample_compare(struct tgsi_sampler *tgsi_sampler, /** * Compare texcoord 'p' (aka R) against texture value 'rgba[0]' +* for 2D Array texture we need to use the 'c0' (aka Q). * When we sampled the depth texture, the depth value was put into all * RGBA channels. We look at the red channel here. */ - pc0 = CLAMP(p[0], 0.0F, 1.0F); - pc1 = CLAMP(p[1], 0.0F, 1.0F); - pc2 = CLAMP(p[2], 0.0F, 1.0F); - pc3 = CLAMP(p[3], 0.0F, 1.0F); - + if (samp->view->texture->target == PIPE_TEXTURE_2D_ARRAY) { + pc0 = CLAMP(c0[0], 0.0F, 1.0F); + pc1 = CLAMP(c0[1], 0.0F, 1.0F); + pc2 = CLAMP(c0[2], 0.0F, 1.0F); + pc3 = CLAMP(c0[3], 0.0F, 1.0F); + } else { + pc0 = CLAMP(p[0], 0.0F, 1.0F); + pc1 = CLAMP(p[1], 0.0F, 1.0F); + pc2 = CLAMP(p[2], 0.0F, 1.0F); + pc3 = CLAMP(p[3], 0.0F, 1.0F); + } /* compare four texcoords vs. four texture samples */ switch (sampler->compare_func) { case PIPE_FUNC_LESS: Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43949] OSMesa does not work with 565 pixel format
https://bugs.freedesktop.org/show_bug.cgi?id=43949 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Brian Paul 2011-12-19 06:41:47 PST --- Thanks for finding that. Patch committed as d334a0fb8cbb368c337858b16cb567a28a35f688 -- 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 43896] Mesa assembly breaks Super Meat Boy, Shank
https://bugs.freedesktop.org/show_bug.cgi?id=43896 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #5 from Brian Paul 2011-12-19 07:00:39 PST --- (In reply to comment #3) > (In reply to comment #2) > > Sounds like a bug in the application to me. From the GLX 1.4 spec (though > > that's certainly not new in 1.4): > > > > "A non-NULL return value for glXGetProcAddress does not guarantee that an > > extension function is actually supported at runtime. The client must also > > query > > glGetString() or glXQueryExtensionsString to determine if an extension is > > supported by a particular context." > > I'm not sure what behaviour is correct. I relied on the the description of > glXGetProcAddress: > http://www.opengl.org/sdk/docs/man/xhtml/glXGetProcAddress.xml > > "A NULL pointer is returned if function requested is not suported in the > implementation being queried." There's no conflict between the quotes above. Getting a non-NULL pointer is no indication whatsoever about whether the extension is supported or not supported. The reason is this: suppose the very first call in main() is glXGetProcAddress("glGenTransformFeedbacks"). At this point, the GL library can't determine whether the extension is supported because it hasn't even opened an X display connection. Depending on which display/GPU is used, the extension may or may not be supported. So if libGL implements the function (or can generate a dispatch stub for it) it must return the pointer for it right away. Later on, the app has to check GL_EXTENSIONS to see if GL_ARB_transform_feedback2 is really supported. If the extension is not supported and the function is called anyway, things might blow up. This is an application bug. -- 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/2] st/mesa: add support for gl_ClipDistance
On 12/17/2011 03:15 PM, Bryan Cain wrote: --- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 49 +--- src/mesa/state_tracker/st_program.c| 18 ++ 2 files changed, 62 insertions(+), 5 deletions(-) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index b929806..3e8df78 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -304,6 +304,7 @@ public: int samplers_used; bool indirect_addr_temps; bool indirect_addr_consts; + int num_clip_distances; int glsl_version; bool native_integers; @@ -4618,9 +4619,16 @@ st_translate_program( } for (i = 0; i< numOutputs; i++) { - t->outputs[i] = ureg_DECL_output(ureg, - outputSemanticName[i], - outputSemanticIndex[i]); + if (outputSemanticName[i] == TGSI_SEMANTIC_CLIPDIST) { +int mask = ((1<< (program->num_clip_distances - 4*outputSemanticIndex[i])) - 1)& 0xf; Being nit-picky, but 0xf should be replaced by TGSI_WRITEMASK_XYZW to be totally clear. +t->outputs[i] = ureg_DECL_output_masked(ureg, +outputSemanticName[i], +outputSemanticIndex[i], +mask); + } else +t->outputs[i] = ureg_DECL_output(ureg, + outputSemanticName[i], + outputSemanticIndex[i]); I'd like to see { } braces around the else clause. if ((outputSemanticName[i] == TGSI_SEMANTIC_PSIZE)&& proginfo->Id) { /* Writing to the point size result register requires special * handling to implement clamping. @@ -4797,7 +4805,8 @@ out: static struct gl_program * get_mesa_program(struct gl_context *ctx, struct gl_shader_program *shader_program, -struct gl_shader *shader) + struct gl_shader *shader, + int num_clip_distances) { glsl_to_tgsi_visitor* v = new glsl_to_tgsi_visitor(); struct gl_program *prog; @@ -4842,6 +4851,7 @@ get_mesa_program(struct gl_context *ctx, v->options = options; v->glsl_version = ctx->Const.GLSLVersion; v->native_integers = ctx->Const.NativeIntegers; + v->num_clip_distances = num_clip_distances; _mesa_generate_parameters_list_for_uniforms(shader_program, shader, prog->Parameters); @@ -4971,6 +4981,27 @@ get_mesa_program(struct gl_context *ctx, return prog; } +/** + * Searches through the IR for a declaration of gl_ClipDistance and returns the + * declared size of the gl_ClipDistance array. Returns 0 if gl_ClipDistance is + * not declared in the IR. + */ +int get_clip_distance_size(exec_list *ir) +{ + foreach_iter (exec_list_iterator, iter, *ir) { + ir_instruction *inst = (ir_instruction *)iter.get(); + ir_variable *var = inst->as_variable(); + if (var == NULL) continue; + if (!strcmp(var->name, "gl_ClipDistance")) + { The { should go on the same line as the 'if' like elsewhere. + fprintf(stderr, "gl_ClipDistance found with size %i\n", var->type->length); Left-over debug code? + return var->type->length; + } + } + + return 0; +} + extern "C" { struct gl_shader * @@ -5009,6 +5040,7 @@ st_new_shader_program(struct gl_context *ctx, GLuint name) GLboolean st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog) { + int num_clip_distances[MESA_SHADER_TYPES]; assert(prog->LinkStatus); for (unsigned i = 0; i< MESA_SHADER_TYPES; i++) { @@ -5020,6 +5052,11 @@ st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog) const struct gl_shader_compiler_options *options = &ctx->ShaderCompilerOptions[_mesa_shader_type_to_index(prog->_LinkedShaders[i]->Type)]; + /* We have to determine the length of the gl_ClipDistance array before + * the array is lowered to two vec4s by lower_clip_distance(). + */ + num_clip_distances[i] = get_clip_distance_size(ir); + do { progress = false; @@ -5036,6 +5073,7 @@ st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog) || progress; progress = lower_quadop_vector(ir, false) || progress; + progress = lower_clip_distance(ir) || progress; if (options->MaxIfDepth == 0) progress = lower_discard(ir) || progress; @@ -5070,7 +5108,8 @@ st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog) if (prog->_LinkedShaders[i] == NULL) continue; - linked_prog = get_mesa_program(ctx, prog, prog->_LinkedShaders[i]); +
Re: [Mesa-dev] [PATCH 1/2] gallium: add support for clip distances
On 12/17/2011 03:15 PM, Bryan Cain wrote: --- src/gallium/auxiliary/tgsi/tgsi_dump.c |3 +- src/gallium/auxiliary/tgsi/tgsi_text.c |3 +- src/gallium/auxiliary/tgsi/tgsi_ureg.c | 36 +--- src/gallium/auxiliary/tgsi/tgsi_ureg.h |6 src/gallium/include/pipe/p_shader_tokens.h |3 +- 5 files changed, 39 insertions(+), 12 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_dump.c b/src/gallium/auxiliary/tgsi/tgsi_dump.c index e830aa5..bd299b0 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_dump.c +++ b/src/gallium/auxiliary/tgsi/tgsi_dump.c @@ -129,7 +129,8 @@ static const char *semantic_names[] = "PRIM_ID", "INSTANCEID", "VERTEXID", - "STENCIL" + "STENCIL", + "CLIPDIST" }; static const char *immediate_type_names[] = diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index eb9190c..f46ba19 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1024,7 +1024,8 @@ static const char *semantic_names[TGSI_SEMANTIC_COUNT] = "PRIM_ID", "INSTANCEID", "VERTEXID", - "STENCIL" + "STENCIL", + "CLIPDIST" }; Just FYI: it looks like semantic_names[] and interplate_names[] (and possibly) other arrays like that are duplicated in at least two tgsi files. It would be nice if someone could move those to a shared header. Also, use STATIC_ASSERT() to check that there's enough entries in the arrays. static const char *interpolate_names[TGSI_INTERPOLATE_COUNT] = diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c b/src/gallium/auxiliary/tgsi/tgsi_ureg.c index 17f9ce2..56c4492 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c @@ -122,6 +122,7 @@ struct ureg_program struct { unsigned semantic_name; unsigned semantic_index; + unsigned usage_mask; Maybe add a comment indicating that the values are TGSI_WRITEMASK_* } output[UREG_MAX_OUTPUT]; unsigned nr_outputs; @@ -396,21 +397,25 @@ ureg_DECL_system_value(struct ureg_program *ureg, struct ureg_dst -ureg_DECL_output( struct ureg_program *ureg, - unsigned name, - unsigned index ) +ureg_DECL_output_masked( struct ureg_program *ureg, + unsigned name, + unsigned index, + unsigned usage_mask ) { unsigned i; I think we could assert that usage_mask != 0, right? A while back I found a bug in st_glsl_to_tgsi.cpp where we had a writemask=0. It took quite a while to find it so an assertion like this could be good. for (i = 0; i< ureg->nr_outputs; i++) { if (ureg->output[i].semantic_name == name&& - ureg->output[i].semantic_index == index) + ureg->output[i].semantic_index == index) { + ureg->output[i].usage_mask |= usage_mask; goto out; + } } if (ureg->nr_outputs< UREG_MAX_OUTPUT) { ureg->output[i].semantic_name = name; ureg->output[i].semantic_index = index; + ureg->output[i].usage_mask = usage_mask; ureg->nr_outputs++; } else { @@ -422,6 +427,15 @@ out: } +struct ureg_dst +ureg_DECL_output( struct ureg_program *ureg, + unsigned name, + unsigned index ) +{ + return ureg_DECL_output_masked(ureg, name, index, TGSI_WRITEMASK_XYZW); +} + + /* Returns a new constant register. Keep track of which have been * referred to so that we can emit decls later. * @@ -1181,7 +1195,8 @@ emit_decl_semantic(struct ureg_program *ureg, unsigned file, unsigned index, unsigned semantic_name, - unsigned semantic_index) + unsigned semantic_index, + unsigned usage_mask) { union tgsi_any_token *out = get_tokens(ureg, DOMAIN_DECL, 3); assert(usage_mask != 0)? @@ -1189,7 +1204,7 @@ emit_decl_semantic(struct ureg_program *ureg, out[0].decl.Type = TGSI_TOKEN_TYPE_DECLARATION; out[0].decl.NrTokens = 3; out[0].decl.File = file; - out[0].decl.UsageMask = TGSI_WRITEMASK_XYZW; /* FIXME! */ + out[0].decl.UsageMask = usage_mask; out[0].decl.Semantic = 1; out[1].value = 0; @@ -1427,7 +1442,8 @@ static void emit_decls( struct ureg_program *ureg ) TGSI_FILE_INPUT, ureg->gs_input[i].index, ureg->gs_input[i].semantic_name, -ureg->gs_input[i].semantic_index); +ureg->gs_input[i].semantic_index, +TGSI_WRITEMASK_XYZW); } } @@ -1436,7 +1452,8 @@ static void emit_decls( struct ureg_program *ureg ) TGSI_FILE_SYSTEM_VALUE, ureg->system_value[i].index,
Re: [Mesa-dev] [PATCH] gallium: remove PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_ATTRIBS
On 12/17/2011 01:09 PM, Marek Olšák wrote: It's the same as PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS. --- src/gallium/drivers/nvc0/nvc0_screen.c |2 -- src/gallium/drivers/r300/r300_screen.c |1 - src/gallium/drivers/r600/r600_pipe.c |1 - src/gallium/include/pipe/p_defines.h |1 - src/mesa/state_tracker/st_extensions.c |2 +- 5 files changed, 1 insertions(+), 6 deletions(-) Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: block attempt to swapbuffer on pixmap. (v2)
On Mon, 2011-12-19 at 09:40 +, Dave Airlie wrote: > On Wed, Dec 7, 2011 at 6:32 PM, Eric Anholt wrote: > > On Wed, 7 Dec 2011 10:24:09 +, Dave Airlie wrote: > >> From: Dave Airlie > >> > >> This keeps track of the creation process and stores a drawable type, > >> it then blocks DRI2 from getting called if the drawable is a pixmap. > >> > >> v2: check if we have a GLX drawable, which means we aren't a pbuffer, > >> avoid doing flush at all since its meant to be a no-op. > > > > I still think this is the wrong way to go. As ajax pointed out, there's > > all sorts of races available from trying to guess client-side, and > > there's no way anybody's relying on the current ("print an error message > > in the xorg log") behavior of the DRI2 protocol for single-buffered, so > > we might as well resolve that DRI2 protocol should do what we want for > > GLX. > > I've been thinking about the races, and I'm not sure they really > apply, like we would have all those races now with the current code, > > Look at the patch, when the glx_drawable struct is created we record > the type of the pixmap, we then call GetGLXDrawable, which looks the > XID up in the hash, > so if the XID has been reused or raced, then we would have to expect > the hash to be incorrect, or else avoid using it in a lot of other > places. True, but we could fix that by moving the UnlockDisplay() to after the DRI2 stanza (and fixing the called code to not try to take the lock itself). There'd still be a race between the GLX and DRI2 requests, in that someone else could Destroy that which you just created, but that's a race against an actively malicious client; it would have to be spamming the server with Destroy requests, since there's no way it can know what XIDs you're going to pick. In contrast, trying to track pixmapness like you're doing here races against at least two app programming techniques that GLX allows and apps actually use: multiple threads, and XID passing between applications. In the latter case you'll not have fixed anything: glx_draw will be NULL because we've not tracked this pixmap since its creation, so we'll carry on with the DRI request. The server is the only thing that knows how to handle this scenario, and it _can_ get this request, so you have to fix it there anyway. All you can do in the client is optimize out sending some requests you know will be no-ops. But thanks for prompting me to re-read that code, it's less thread-safe than I remembered. - ajax signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: DrawTFB should use the vertex count from the last call of EndTFB
On 12/17/2011 06:41 AM, Marek Olšák wrote: From ARB_transform_feedback2: ... the vertex count used for the rendering operation is set by the previous EndTransformFeedback command. --- src/mesa/state_tracker/st_cb_xformfb.c | 53 +-- 1 files changed, 42 insertions(+), 11 deletions(-) diff --git a/src/mesa/state_tracker/st_cb_xformfb.c b/src/mesa/state_tracker/st_cb_xformfb.c index 2fc28dc..e699fb6 100644 --- a/src/mesa/state_tracker/st_cb_xformfb.c +++ b/src/mesa/state_tracker/st_cb_xformfb.c @@ -55,6 +55,11 @@ struct st_transform_feedback_object { unsigned num_targets; struct pipe_stream_output_target *targets[PIPE_MAX_SO_BUFFERS]; + + /* This encapsulates the count that can be used as a source for draw_vbo. +* It contains a stream output target from the last call of +* EndTransformFeedback. */ + struct pipe_stream_output_target *draw_count; }; @@ -81,6 +86,8 @@ st_delete_transform_feedback(struct gl_context *ctx, (struct st_transform_feedback_object*)obj; unsigned i; + pipe_so_target_reference(&sobj->draw_count, NULL); + /* Unreference targets. */ for (i = 0; i< sobj->num_targets; i++) { pipe_so_target_reference(&sobj->targets[i], NULL); @@ -115,6 +122,7 @@ st_begin_transform_feedback(struct gl_context *ctx, GLenum mode, if (bo) { /* Check whether we need to recreate the target. */ if (!sobj->targets[i] || + sobj->targets[i] == sobj->draw_count || sobj->targets[i]->buffer != bo->buffer || sobj->targets[i]->buffer_offset != sobj->base.Offset[i] || sobj->targets[i]->buffer_size != sobj->base.Size[i]) { @@ -141,7 +149,7 @@ st_begin_transform_feedback(struct gl_context *ctx, GLenum mode, static void -st_stop_transform_feedback(struct gl_context *ctx, +st_pause_transform_feedback(struct gl_context *ctx, struct gl_transform_feedback_object *obj) { struct st_context *st = st_context(ctx); @@ -161,11 +169,9 @@ st_resume_transform_feedback(struct gl_context *ctx, ~0); } -/* Set count_from_stream_output to any stream output target - * from the transform feedback object. */ -void -st_transform_feedback_draw_init(struct gl_transform_feedback_object *obj, -struct pipe_draw_info *out) + +static struct pipe_stream_output_target * +st_transform_feedback_get_draw_target(struct gl_transform_feedback_object *obj) { struct st_transform_feedback_object *sobj = (struct st_transform_feedback_object*)obj; @@ -173,13 +179,38 @@ st_transform_feedback_draw_init(struct gl_transform_feedback_object *obj, for (i = 0; i< Elements(sobj->targets); i++) { if (sobj->targets[i]) { - out->count_from_stream_output = sobj->targets[i]; - return; + return sobj->targets[i]; } } assert(0); - out->count_from_stream_output = NULL; + return NULL; +} + + +static void +st_end_transform_feedback(struct gl_context *ctx, + struct gl_transform_feedback_object *obj) +{ + struct st_context *st = st_context(ctx); + struct st_transform_feedback_object *sobj = + (struct st_transform_feedback_object*)obj; + + cso_set_stream_outputs(st->cso_context, 0, NULL, 0); + + pipe_so_target_reference(&sobj->draw_count, +st_transform_feedback_get_draw_target(obj)); +} + + +void +st_transform_feedback_draw_init(struct gl_transform_feedback_object *obj, +struct pipe_draw_info *out) +{ + struct st_transform_feedback_object *sobj = + (struct st_transform_feedback_object*)obj; + + out->count_from_stream_output = sobj->draw_count; } Minor nit: instead of using casts for st_transform_feedback_object, define a cast wrapper as we do for other types: static INLINE struct st_transform_feedback_object * st_transform_feedback_object(struct gl_transform_feedback_object *obj) { return (struct st_transform_feedback_object *) obj; } Looks good otherwise. @@ -189,8 +220,8 @@ st_init_xformfb_functions(struct dd_function_table *functions) functions->NewTransformFeedback = st_new_transform_feedback; functions->DeleteTransformFeedback = st_delete_transform_feedback; functions->BeginTransformFeedback = st_begin_transform_feedback; - functions->EndTransformFeedback = st_stop_transform_feedback; - functions->PauseTransformFeedback = st_stop_transform_feedback; + functions->EndTransformFeedback = st_end_transform_feedback; + functions->PauseTransformFeedback = st_pause_transform_feedback; functions->ResumeTransformFeedback = st_resume_transform_feedback; } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965 gen6: Implement rasterizer discard.
On 16 December 2011 19:53, Kenneth Graunke wrote: > On 12/14/2011 11:59 AM, Paul Berry wrote: > > This patch enables rasterizer discard functionality (a part of > > transform feedback) in Gen6, by generating an alternate GS program > > when rasterizer discard is active. Instead of forwarding vertices > > down the pipeline, the alternate GS program uses a URB Write message > > to deallocate the URB entry that was allocated by FF sync and > > terminate the thread. > > > > Note: parts of the Sandy Bridge PRM seem to imply that we could do > > this more efficiently, by clearing the GEN6_GS_RENDERING_ENABLE bit, > > and not allocating a URB entry at all. However, it's not clear how we > > are supposed to terminate the thread if we do that. Volume 2 part 1, > > section 4.5.4, says "GS threads must terminate by sending a URB_WRITE > > message with the EOT and Complete bits set.", and my experiments so > > far confirm that. > > --- > > > > This patch needs to be applied on top of the series "[PATCH 0/8] i965 > > gen6: Initial implementation of transform feedback.", which is still > > under review on the mailing list. > > Assuming the dirty bit gets sorted out, > Reviewed-by: Kenneth Graunke > > Thanks, Ken. Fortunately, this patch is independent of the dirty bit stuff (since this patch adds a use of ctx->TransformFeedback.RasterDiscard to brw_gs_prog, which already depends on _NEW_TRANSFORM). So I'll push it as soon as the remaining discussion on my main transform feedback series is resolved. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: use SINT/UINT formats for VertexAttribIPointer
--- src/mesa/state_tracker/st_draw.c | 63 +++-- src/mesa/state_tracker/st_draw.h |2 +- src/mesa/state_tracker/st_draw_feedback.c |3 +- 3 files changed, 62 insertions(+), 6 deletions(-) diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c index 87a9978..e8a7fe3 100644 --- a/src/mesa/state_tracker/st_draw.c +++ b/src/mesa/state_tracker/st_draw.c @@ -102,6 +102,13 @@ static GLuint uint_types_scale[4] = { PIPE_FORMAT_R32G32B32A32_USCALED }; +static GLuint uint_types_int[4] = { + PIPE_FORMAT_R32_UINT, + PIPE_FORMAT_R32G32_UINT, + PIPE_FORMAT_R32G32B32_UINT, + PIPE_FORMAT_R32G32B32A32_UINT +}; + static GLuint int_types_norm[4] = { PIPE_FORMAT_R32_SNORM, PIPE_FORMAT_R32G32_SNORM, @@ -116,6 +123,13 @@ static GLuint int_types_scale[4] = { PIPE_FORMAT_R32G32B32A32_SSCALED }; +static GLuint int_types_int[4] = { + PIPE_FORMAT_R32_SINT, + PIPE_FORMAT_R32G32_SINT, + PIPE_FORMAT_R32G32B32_SINT, + PIPE_FORMAT_R32G32B32A32_SINT +}; + static GLuint ushort_types_norm[4] = { PIPE_FORMAT_R16_UNORM, PIPE_FORMAT_R16G16_UNORM, @@ -130,6 +144,13 @@ static GLuint ushort_types_scale[4] = { PIPE_FORMAT_R16G16B16A16_USCALED }; +static GLuint ushort_types_int[4] = { + PIPE_FORMAT_R16_UINT, + PIPE_FORMAT_R16G16_UINT, + PIPE_FORMAT_R16G16B16_UINT, + PIPE_FORMAT_R16G16B16A16_UINT +}; + static GLuint short_types_norm[4] = { PIPE_FORMAT_R16_SNORM, PIPE_FORMAT_R16G16_SNORM, @@ -144,6 +165,13 @@ static GLuint short_types_scale[4] = { PIPE_FORMAT_R16G16B16A16_SSCALED }; +static GLuint short_types_int[4] = { + PIPE_FORMAT_R16_SINT, + PIPE_FORMAT_R16G16_SINT, + PIPE_FORMAT_R16G16B16_SINT, + PIPE_FORMAT_R16G16B16A16_SINT +}; + static GLuint ubyte_types_norm[4] = { PIPE_FORMAT_R8_UNORM, PIPE_FORMAT_R8G8_UNORM, @@ -158,6 +186,13 @@ static GLuint ubyte_types_scale[4] = { PIPE_FORMAT_R8G8B8A8_USCALED }; +static GLuint ubyte_types_int[4] = { + PIPE_FORMAT_R8_UINT, + PIPE_FORMAT_R8G8_UINT, + PIPE_FORMAT_R8G8B8_UINT, + PIPE_FORMAT_R8G8B8A8_UINT +}; + static GLuint byte_types_norm[4] = { PIPE_FORMAT_R8_SNORM, PIPE_FORMAT_R8G8_SNORM, @@ -172,6 +207,13 @@ static GLuint byte_types_scale[4] = { PIPE_FORMAT_R8G8B8A8_SSCALED }; +static GLuint byte_types_int[4] = { + PIPE_FORMAT_R8_SINT, + PIPE_FORMAT_R8G8_SINT, + PIPE_FORMAT_R8G8B8_SINT, + PIPE_FORMAT_R8G8B8A8_SINT +}; + static GLuint fixed_types[4] = { PIPE_FORMAT_R32_FIXED, PIPE_FORMAT_R32G32_FIXED, @@ -186,7 +228,7 @@ static GLuint fixed_types[4] = { */ enum pipe_format st_pipe_vertex_format(GLenum type, GLuint size, GLenum format, - GLboolean normalized) + GLboolean normalized, GLboolean integer) { assert((type >= GL_BYTE && type <= GL_DOUBLE) || type == GL_FIXED || type == GL_HALF_FLOAT || @@ -234,7 +276,18 @@ st_pipe_vertex_format(GLenum type, GLuint size, GLenum format, return PIPE_FORMAT_B8G8R8A8_UNORM; } - if (normalized) { + if (integer) { + switch (type) { + case GL_INT: return int_types_int[size-1]; + case GL_SHORT: return short_types_int[size-1]; + case GL_BYTE: return byte_types_int[size-1]; + case GL_UNSIGNED_INT: return uint_types_int[size-1]; + case GL_UNSIGNED_SHORT: return ushort_types_int[size-1]; + case GL_UNSIGNED_BYTE: return ubyte_types_int[size-1]; + default: assert(0); return 0; + } + } + else if (normalized) { switch (type) { case GL_DOUBLE: return double_types[size-1]; case GL_FLOAT: return float_types[size-1]; @@ -407,7 +460,8 @@ setup_interleaved_attribs(struct gl_context *ctx, velements[attr].src_format = st_pipe_vertex_format(array->Type, array->Size, array->Format, - array->Normalized); + array->Normalized, +array->Integer); assert(velements[attr].src_format); if (!usingVBO) { @@ -564,7 +618,8 @@ setup_non_interleaved_attribs(struct gl_context *ctx, velements[attr].src_format = st_pipe_vertex_format(array->Type, array->Size, array->Format, - array->Normalized); + array->Normalized, + array->Integer); assert(velements[attr].src_format); } diff --git a/src/mesa/state_tracker/st_draw.h b/src/mesa/state_tracker/st_draw.h index 2623cdb..47bdb11 100644 --- a/src/mesa/state_tracker/st_draw.h +++ b/src/mesa/state_t
[Mesa-dev] [PATCH] vl: Use pipe clear_render_target instead of util_clear_render_target
Mapping to software and uploading again clearing is killing performance. Signed-off-by: Maarten Lankhorst --- src/gallium/auxiliary/vl/vl_compositor.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/vl/vl_compositor.c b/src/gallium/auxiliary/vl/vl_compositor.c index 85507ba..1bdd775 100644 --- a/src/gallium/auxiliary/vl/vl_compositor.c +++ b/src/gallium/auxiliary/vl/vl_compositor.c @@ -1002,8 +1002,8 @@ vl_compositor_render(struct vl_compositor *c, if (dirty_area && (dirty_area->x0 < dirty_area->x1 || dirty_area->y0 < dirty_area->y1)) { - util_clear_render_target(c->pipe, dst_surface, &c->clear_color, - 0, 0, dst_surface->width, dst_surface->height); + c->pipe->clear_render_target(c->pipe, dst_surface, &c->clear_color, + 0, 0, dst_surface->width, dst_surface->height); dirty_area->x0 = dirty_area->y0 = MAX_DIRTY; dirty_area->x0 = dirty_area->y1 = MIN_DIRTY; } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: block attempt to swapbuffer on pixmap. (v2)
On Mon, 2011-12-19 at 10:14 -0500, Adam Jackson wrote: > On Mon, 2011-12-19 at 09:40 +, Dave Airlie wrote: > > On Wed, Dec 7, 2011 at 6:32 PM, Eric Anholt wrote: > > > On Wed, 7 Dec 2011 10:24:09 +, Dave Airlie wrote: > > >> From: Dave Airlie > > >> > > >> This keeps track of the creation process and stores a drawable type, > > >> it then blocks DRI2 from getting called if the drawable is a pixmap. > > >> > > >> v2: check if we have a GLX drawable, which means we aren't a pbuffer, > > >> avoid doing flush at all since its meant to be a no-op. > > > > > > I still think this is the wrong way to go. As ajax pointed out, there's > > > all sorts of races available from trying to guess client-side, and > > > there's no way anybody's relying on the current ("print an error message > > > in the xorg log") behavior of the DRI2 protocol for single-buffered, so > > > we might as well resolve that DRI2 protocol should do what we want for > > > GLX. > > > > I've been thinking about the races, and I'm not sure they really > > apply, like we would have all those races now with the current code, > > > > Look at the patch, when the glx_drawable struct is created we record > > the type of the pixmap, we then call GetGLXDrawable, which looks the > > XID up in the hash, > > so if the XID has been reused or raced, then we would have to expect > > the hash to be incorrect, or else avoid using it in a lot of other > > places. > > True, but we could fix that by moving the UnlockDisplay() to after the > DRI2 stanza (and fixing the called code to not try to take the lock > itself). There'd still be a race between the GLX and DRI2 requests, in > that someone else could Destroy that which you just created, but that's > a race against an actively malicious client; it would have to be > spamming the server with Destroy requests, since there's no way it can > know what XIDs you're going to pick. > > In contrast, trying to track pixmapness like you're doing here races > against at least two app programming techniques that GLX allows and apps > actually use: multiple threads, and XID passing between applications. > In the latter case you'll not have fixed anything: glx_draw will be NULL > because we've not tracked this pixmap since its creation, so we'll carry > on with the DRI request. > > The server is the only thing that knows how to handle this scenario, and > it _can_ get this request, so you have to fix it there anyway. Actually no, the DRI2 code in the server can't know, as this is a perfectly legitimate request for a GLXPbuffer. -- 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] vertex array regression
On 12/16/2011 11:28 AM, Mathias Fröhlich wrote: Brian, On Thursday, December 15, 2011 22:36:24 you wrote: I found the problem. It's this chunk in vbo_context.c: [...] For fixed function, the point is to simply place the per-vertex material attributes in the generic attribute arrays. There are 12 such material attributes. So there's four slots left over. Yep, and these map with the old scheme to often used attributes like the vertex position. I still don't get what the purpose of the special mapping of the last four/five elements is all about. Can you explain that? Thanks to your hints I believe that I found the underlying problem: If you look at the resulting bitmasks for the enabled vertex program inputs in isosurf by commenting out the printf in _mesa_set_varying_vp_inputs you will see surprising results with the old numbering. The current checked in numbering looks much more plausible. It turns out that this wrong varying_vp_inputs mask sets the _NEW_ARRAY bit through _mesa_set_varying_vp_inputs. That in turn cares for some (by now in my debug session untracked) state updates. This helps in the end for isosurf. If the varying_vp_inputs mask looks plausible the _NEW_ARRAY bit is not set and isosurf fails. This also explaines that only draw paths going through vbo_exec_array.c are affected, since the imm variants in vbo_exec_{safe,draw} always set the _NEW_ARRAY bit on any draw. Yeah, I see how the incorrect varying_inputs values was causing _NEW_ARRAY to get set, thus hiding the problem. The solution looks correct, but I'm a little worried about performance, as is mentioned in the comment. Marek, made that change back in March. Maybe he can take a look at this too. So for me this change diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c index a6e41e9..a2851c4 100644 --- a/src/mesa/vbo/vbo_exec_array.c +++ b/src/mesa/vbo/vbo_exec_array.c @@ -446,7 +446,7 @@ recalculate_input_bindings(struct gl_context *ctx) * to revalidate vertex arrays. Not marking the state as dirty also * improves performance (quite significantly in some apps). */ - if (!ctx->VertexProgram._MaintainTnlProgram) + /* if (!ctx->VertexProgram._MaintainTnlProgram) */ ctx->NewState |= _NEW_ARRAY; break; makes isosurf work reliable. I will prepare a patch for that. Greetings Mathias -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] gallium/draw: fix two side handling
From: Dave Airlie The previous fix linked the vertex/fragment shader handling in softpipe for the unspecified front color output case, but specified back color case. However in that case we were doing a copy from back to non-existant front, this code checks we have existant front/backs and only does the copy when they both exist. Signed-off-by: Dave Airlie --- src/gallium/auxiliary/draw/draw_pipe_twoside.c | 27 1 files changed, 9 insertions(+), 18 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_twoside.c b/src/gallium/auxiliary/draw/draw_pipe_twoside.c index 9a3f3fe..b1a70a0 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_twoside.c +++ b/src/gallium/auxiliary/draw/draw_pipe_twoside.c @@ -38,8 +38,8 @@ struct twoside_stage { struct draw_stage stage; float sign; /**< +1 or -1 */ - uint attrib_front0, attrib_back0; - uint attrib_front1, attrib_back1; + int attrib_front0, attrib_back0; + int attrib_front1, attrib_back1; }; @@ -48,9 +48,6 @@ static INLINE struct twoside_stage *twoside_stage( struct draw_stage *stage ) return (struct twoside_stage *)stage; } - - - /** * Copy back color(s) to front color(s). */ @@ -60,12 +57,12 @@ copy_bfc( struct twoside_stage *twoside, unsigned idx ) { struct vertex_header *tmp = dup_vert( &twoside->stage, v, idx ); - - if (twoside->attrib_back0) { + + if (twoside->attrib_back0 >= 0 && twoside->attrib_front0 >= 0) { COPY_4FV(tmp->data[twoside->attrib_front0], tmp->data[twoside->attrib_back0]); } - if (twoside->attrib_back1) { + if (twoside->attrib_back1 >= 0 && twoside->attrib_front1 >= 0) { COPY_4FV(tmp->data[twoside->attrib_front1], tmp->data[twoside->attrib_back1]); } @@ -109,10 +106,10 @@ static void twoside_first_tri( struct draw_stage *stage, const struct draw_vertex_shader *vs = stage->draw->vs.vertex_shader; uint i; - twoside->attrib_front0 = 0; - twoside->attrib_front1 = 0; - twoside->attrib_back0 = 0; - twoside->attrib_back1 = 0; + twoside->attrib_front0 = -1; + twoside->attrib_front1 = -1; + twoside->attrib_back0 = -1; + twoside->attrib_back1 = -1; /* Find which vertex shader outputs are front/back colors */ for (i = 0; i < vs->info.num_outputs; i++) { @@ -130,12 +127,6 @@ static void twoside_first_tri( struct draw_stage *stage, } } - if (!twoside->attrib_back0) - twoside->attrib_front0 = 0; - - if (!twoside->attrib_back1) - twoside->attrib_front1 = 0; - /* * We'll multiply the primitive's determinant by this sign to determine * if the triangle is back-facing (negative). -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] softpipe two sided fixes
These two patches fix 13 piglit tests in softpipe, GL2 vertex-program-two-side and glsl-1.10 interpolation tests. I'm not 100% sure that my fixes are the correct way to fix the problem, but I'd probably need some direction if someone knows better, I'm not entirely happy that the fix is in two places, but I'm not really sure where the best place to pick between front/back is, and it might be nice to avoid the copying completely. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.
From: Dave Airlie In the case where a front and back output are specified, the draw code will copy the back output into the front color slot and everything is happy. However if no front is specified then the draw code will do a bad copy (separate patch), but also the frag shader won't pick up the color as there there is no write to COLOR from the vertex shader just BCOLOR. This patch fixes that problem so if it can't find a vertex shader output for the front color slot, it will go and lookup and use one for the back color slot. Signed-off-by: Dave Airlie --- src/gallium/drivers/softpipe/sp_state_derived.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c b/src/gallium/drivers/softpipe/sp_state_derived.c index f89d23c..5685997 100644 --- a/src/gallium/drivers/softpipe/sp_state_derived.c +++ b/src/gallium/drivers/softpipe/sp_state_derived.c @@ -121,6 +121,11 @@ softpipe_get_vertex_info(struct softpipe_context *softpipe) src = draw_find_shader_output(softpipe->draw, fsInfo->input_semantic_name[i], fsInfo->input_semantic_index[i]); +if (fsInfo->input_semantic_name[i] == TGSI_SEMANTIC_COLOR && src == 0) + /* try and find a bcolor */ + src = draw_find_shader_output(softpipe->draw, +TGSI_SEMANTIC_BCOLOR, fsInfo->input_semantic_index[i]); + draw_emit_vertex_attr(vinfo, EMIT_4F, interp, src); } -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] tgsi: update documents with some info on texture lookup
From: Dave Airlie this mentions which channels are used for slice and depth comparison values. Signed-off-by: Dave Airlie --- src/gallium/docs/source/tgsi.rst | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index d7f50b1..45af528 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -585,6 +585,17 @@ This instruction replicates its result. dst = texture_sample(unit, coord, bias) + for array textures src0.y contains the slice for 1D, + and src0.z contain the slice for 2D. + for shadow textures with no arrays, src0.z contains + the reference value. + for shadow textures with arrays, src0.z contains + the reference value for 1D arrays, and src0.w contains + the reference value for 2D arrays. + There is no way to pass a bias in the .w value for + shadow arrays, and GLSL doesn't allow this. + GLSL does allow cube shadows maps to take a bias value, + and we have to determine how this will look in TGSI. .. opcode:: TXD - Texture Lookup with Derivatives -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] softpipe: fix shadow1d tests.
> > > That looks better. Would you mind checking that the TGSI docs properly > describe which coordinate components are used for array indexing, shadow > distance, etc. I've sent a tgsi doc update, not really sure how we plan on handling, float texture (samplerCubeShadow sampler, vec4 P [, float bias] ) from GLSL, but that isn't a problem I'm looking at now, I was just trying to make softpipe pass as many tests as possible for GL2.1, out of idle curiosity. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] softpipe color interpolation
Hi guys, So we have some piglit tests generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_FrontColor-smooth-none.shader_test that piglit fails This seems to be due to its linear interpolation not producing the correct answers compared to the hardware, on the rendered triangle, there is a obvious circle of darkness that isn't there on hw rendered. Looking at tri_linear_coeff I notice a large comment explaining that this could be done better, llvmpipe also uses the same code, is this what is causing the fail? Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: block attempt to swapbuffer on pixmap. (v2)
On Mon, 2011-12-19 at 16:45 +0100, Michel Dänzer wrote: > On Mon, 2011-12-19 at 10:14 -0500, Adam Jackson wrote: > > > The server is the only thing that knows how to handle this scenario, and > > it _can_ get this request, so you have to fix it there anyway. > > Actually no, the DRI2 code in the server can't know, as this is a > perfectly legitimate request for a GLXPbuffer. Only as an artifact of how we implement pbuffers (which is, stylistically, a disaster). And even then I don't think that's true, just that the implementation would be unpleasant. xserver gets DRI2SwapBuffers on an XID for an X pixmap. It can either be backing a GLXPixmap or a GLXPbuffer, but not both*. Therefore DRI2 needs to wrap the glx drawable create path in the server, and stash a note on the PixmapRec private for the GLXPixmap and GLXPbuffer cases. That way SwapBuffers has type information without needing to walk all GLXPixmaps looking for an XID match with the backing pixmap. This works because Pixmaps have to be created before GLXPixmaps, but the backing pixmap for a pbuffer is created after the pbuffer. So technically that * above is a lie. We create the backing pixmap for the pbuffer inside xlib, and we don't leak that XID outside libGL, but the client could guess. The failure cases would be: a) create pbuffer, guess Pixmap XID, bind a GLXPixmap to it b) create Pixmap, create GLXPixmap, fabricate your own protocol for CreatePbuffer and DRI2CreateDrawable to bind to the Pixmap Both of which are detectable, because they involve calling DRI2CreateDrawable a second time after you've already inferred type. Or, better yet, if DRI2 insists on keeping the current weird 'alias' semantics for DRI2CreateDrawable, it could alias based on the GLX resource ID. This would mean moving the creation of the backing pixmap for pbuffers inside the server, but honestly that's a lot cleaner anyway. Among other things, there'd be no possibility of leaking an XID to the client for the backing resource. - ajax signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] tgsi: update documents with some info on texture lookup
On 12/19/2011 09:40 AM, Dave Airlie wrote: From: Dave Airlie this mentions which channels are used for slice and depth comparison values. Signed-off-by: Dave Airlie --- src/gallium/docs/source/tgsi.rst | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index d7f50b1..45af528 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -585,6 +585,17 @@ This instruction replicates its result. dst = texture_sample(unit, coord, bias) + for array textures src0.y contains the slice for 1D, + and src0.z contain the slice for 2D. + for shadow textures with no arrays, src0.z contains + the reference value. + for shadow textures with arrays, src0.z contains + the reference value for 1D arrays, and src0.w contains + the reference value for 2D arrays. + There is no way to pass a bias in the .w value for + shadow arrays, and GLSL doesn't allow this. + GLSL does allow cube shadows maps to take a bias value, + and we have to determine how this will look in TGSI. .. opcode:: TXD - Texture Lookup with Derivatives Thanks! Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] softpipe color interpolation
On 12/19/2011 10:10 AM, Dave Airlie wrote: Hi guys, So we have some piglit tests generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_FrontColor-smooth-none.shader_test that piglit fails This seems to be due to its linear interpolation not producing the correct answers compared to the hardware, on the rendered triangle, there is a obvious circle of darkness that isn't there on hw rendered. Looking at tri_linear_coeff I notice a large comment explaining that this could be done better, llvmpipe also uses the same code, is this what is causing the fail? Quite possibly. It shouldn't be hard to hack softpipe to use perspective-corrected color interpolation to see if that helps. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] gallium/draw: fix two side handling
On 12/19/2011 09:29 AM, Dave Airlie wrote: From: Dave Airlie The previous fix linked the vertex/fragment shader handling in softpipe for the unspecified front color output case, but specified back color case. However in that case we were doing a copy from back to non-existant front, this code checks we have existant front/backs and only does the copy when they both exist. Signed-off-by: Dave Airlie --- src/gallium/auxiliary/draw/draw_pipe_twoside.c | 27 1 files changed, 9 insertions(+), 18 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_twoside.c b/src/gallium/auxiliary/draw/draw_pipe_twoside.c index 9a3f3fe..b1a70a0 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_twoside.c +++ b/src/gallium/auxiliary/draw/draw_pipe_twoside.c @@ -38,8 +38,8 @@ struct twoside_stage { struct draw_stage stage; float sign; /**< +1 or -1 */ - uint attrib_front0, attrib_back0; - uint attrib_front1, attrib_back1; + int attrib_front0, attrib_back0; + int attrib_front1, attrib_back1; }; @@ -48,9 +48,6 @@ static INLINE struct twoside_stage *twoside_stage( struct draw_stage *stage ) return (struct twoside_stage *)stage; } - - - /** * Copy back color(s) to front color(s). */ @@ -60,12 +57,12 @@ copy_bfc( struct twoside_stage *twoside, unsigned idx ) { struct vertex_header *tmp = dup_vert(&twoside->stage, v, idx ); - - if (twoside->attrib_back0) { + + if (twoside->attrib_back0>= 0&& twoside->attrib_front0>= 0) { COPY_4FV(tmp->data[twoside->attrib_front0], tmp->data[twoside->attrib_back0]); } - if (twoside->attrib_back1) { + if (twoside->attrib_back1>= 0&& twoside->attrib_front1>= 0) { COPY_4FV(tmp->data[twoside->attrib_front1], tmp->data[twoside->attrib_back1]); } @@ -109,10 +106,10 @@ static void twoside_first_tri( struct draw_stage *stage, const struct draw_vertex_shader *vs = stage->draw->vs.vertex_shader; uint i; - twoside->attrib_front0 = 0; - twoside->attrib_front1 = 0; - twoside->attrib_back0 = 0; - twoside->attrib_back1 = 0; + twoside->attrib_front0 = -1; + twoside->attrib_front1 = -1; + twoside->attrib_back0 = -1; + twoside->attrib_back1 = -1; /* Find which vertex shader outputs are front/back colors */ for (i = 0; i< vs->info.num_outputs; i++) { @@ -130,12 +127,6 @@ static void twoside_first_tri( struct draw_stage *stage, } } - if (!twoside->attrib_back0) - twoside->attrib_front0 = 0; - - if (!twoside->attrib_back1) - twoside->attrib_front1 = 0; - /* * We'll multiply the primitive's determinant by this sign to determine * if the triangle is back-facing (negative). This looks like a good fix in general. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.
On 12/19/2011 09:29 AM, Dave Airlie wrote: From: Dave Airlie In the case where a front and back output are specified, the draw code will copy the back output into the front color slot and everything is happy. However if no front is specified then the draw code will do a bad copy (separate patch), but also the frag shader won't pick up the color as there there is no write to COLOR from the vertex shader just BCOLOR. This patch fixes that problem so if it can't find a vertex shader output for the front color slot, it will go and lookup and use one for the back color slot. Signed-off-by: Dave Airlie --- src/gallium/drivers/softpipe/sp_state_derived.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c b/src/gallium/drivers/softpipe/sp_state_derived.c index f89d23c..5685997 100644 --- a/src/gallium/drivers/softpipe/sp_state_derived.c +++ b/src/gallium/drivers/softpipe/sp_state_derived.c @@ -121,6 +121,11 @@ softpipe_get_vertex_info(struct softpipe_context *softpipe) src = draw_find_shader_output(softpipe->draw, fsInfo->input_semantic_name[i], fsInfo->input_semantic_index[i]); +if (fsInfo->input_semantic_name[i] == TGSI_SEMANTIC_COLOR&& src == 0) + /* try and find a bcolor */ + src = draw_find_shader_output(softpipe->draw, +TGSI_SEMANTIC_BCOLOR, fsInfo->input_semantic_index[i]); + draw_emit_vertex_attr(vinfo, EMIT_4F, interp, src); } And if the VS emits neither a front color or back color, what happens? It seems to me that if the VS doesn't emit a front color and the polygon ends up being front-facing, the polygon color is undefined. Off-hand I don't recall what the GL/GLSL specs say about this. What is the piglit test expecting? -Brain ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix compilation on cygwin after commit 762c9766c93697af8d7fbaa729aed118789dbe8e
Fix compilation on cygwin after commit 762c9766c93697af8d7fbaa729aed118789dbe8e "Use VERT_ATTRIB_* indexed array in gl_array_object" added the first non-driver use of ffsll(), which exposes the fact that this isn't provided on cygwin. Found by tinderbox, see [1] [1] http://tinderbox.freedesktop.org/builds/2011-11-30-0017/logs/libGL/#build Signed-off-by: Jon TURNEY --- src/mesa/main/imports.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h index 797f357..d5e3859 100644 --- a/src/mesa/main/imports.h +++ b/src/mesa/main/imports.h @@ -568,7 +568,7 @@ _mesa_init_sqrt_table(void); #ifdef __GNUC__ -#if defined(__MINGW32__) || defined(ANDROID) +#if defined(__MINGW32__) || defined(__CYGWIN__) || defined(ANDROID) #define ffs __builtin_ffs #define ffsll __builtin_ffsll #endif -- 1.7.5.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.
On Mon, Dec 19, 2011 at 5:39 PM, Brian Paul wrote: > On 12/19/2011 09:29 AM, Dave Airlie wrote: >> >> From: Dave Airlie >> >> In the case where a front and back output are specified, the draw code >> will >> copy the back output into the front color slot and everything is happy. >> >> However if no front is specified then the draw code will do a bad copy >> (separate patch), but also the frag shader won't pick up the color as there >> there is >> no write to COLOR from the vertex shader just BCOLOR. >> >> This patch fixes that problem so if it can't find a vertex shader output >> for the front color slot, it will go and lookup and use one for the back >> color >> slot. >> >> Signed-off-by: Dave Airlie >> --- >> src/gallium/drivers/softpipe/sp_state_derived.c | 5 + >> 1 files changed, 5 insertions(+), 0 deletions(-) >> >> diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c >> b/src/gallium/drivers/softpipe/sp_state_derived.c >> index f89d23c..5685997 100644 >> --- a/src/gallium/drivers/softpipe/sp_state_derived.c >> +++ b/src/gallium/drivers/softpipe/sp_state_derived.c >> @@ -121,6 +121,11 @@ softpipe_get_vertex_info(struct softpipe_context >> *softpipe) >> src = draw_find_shader_output(softpipe->draw, >> fsInfo->input_semantic_name[i], >> fsInfo->input_semantic_index[i]); >> + if (fsInfo->input_semantic_name[i] == TGSI_SEMANTIC_COLOR&& src >> == 0) >> >> + /* try and find a bcolor */ >> + src = draw_find_shader_output(softpipe->draw, >> + TGSI_SEMANTIC_BCOLOR, >> fsInfo->input_semantic_index[i]); >> + >> draw_emit_vertex_attr(vinfo, EMIT_4F, interp, src); >> } >> > > And if the VS emits neither a front color or back color, what happens? Well the same as happens now, which from what I can see is undefined. Since if the VS emits no colors and the FS expects a color, you have a problem, I'm not sure if the linker deals with this. > It seems to me that if the VS doesn't emit a front color and the polygon > ends up being front-facing, the polygon color is undefined. Yes the test seems to not care about the value in the front in this case at all, but maybe Ian or someone with more spec can say what the chapter/verse is. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] softpipe color interpolation
On 19.12.2011 18:10, Dave Airlie wrote: > Hi guys, > > So we have some piglit tests > generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_FrontColor-smooth-none.shader_test > that piglit fails > > This seems to be due to its linear interpolation not producing the > correct answers compared to the hardware, on the rendered triangle, > there is a obvious circle of darkness that isn't there on hw rendered. > > Looking at tri_linear_coeff I notice a large comment explaining that > this could be done better, llvmpipe also uses the same code, is this > what is causing the fail? I noticed that a while ago, the lighting in a level in nexuiz was looking weird on nv50, and I discovered it was due to colours using linear (noperspective) interpolation instead of perspective correct interpolation, at TGSI's behest. It looked fine on llvmpipe, because its linear interpolation was more like the perspective correct interpolation on nv50 ... We should probably do GL_PERSPECTIVE_CORRECTION_HINT GL_NICEST, as newer GL versions require anyway, and set the COLOR interpolants to TGSI_INTERPOLATE_PERSPECTIVE in the state tracker. For visualization: http://people.freedesktop.org/~chrisbmr/linterp.png (that's supposed to be noperspective, iirc) > Dave. > ___ > 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
Re: [Mesa-dev] [PATCH] i965: Implement bounds checking for transform feedback output.
On 15 December 2011 15:20, Kenneth Graunke wrote: > Signed-off-by: Kenneth Graunke > --- > 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_emit.c | 10 > src/mesa/drivers/dri/i965/gen6_sol.c| 38 > +++ > 4 files changed, 52 insertions(+), 0 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_context.c > b/src/mesa/drivers/dri/i965/brw_context.c > index 7d360b0..fd60853 100644 > --- a/src/mesa/drivers/dri/i965/brw_context.c > +++ b/src/mesa/drivers/dri/i965/brw_context.c > @@ -117,6 +117,7 @@ static void brwInitDriverFunctions( struct > dd_function_table *functions ) >brw_init_queryobj_functions(functions); > >functions->PrepareExecBegin = brwPrepareExecBegin; > + functions->BeginTransformFeedback = brw_begin_transform_feedback; >functions->EndTransformFeedback = brw_end_transform_feedback; > } > > diff --git a/src/mesa/drivers/dri/i965/brw_context.h > b/src/mesa/drivers/dri/i965/brw_context.h > index 8e52488..20623d4 100644 > --- a/src/mesa/drivers/dri/i965/brw_context.h > +++ b/src/mesa/drivers/dri/i965/brw_context.h > @@ -1073,6 +1073,9 @@ brw_fprog_uses_noperspective(const struct > gl_fragment_program *fprog); > > /* gen6_sol.c */ > void > +brw_begin_transform_feedback(struct gl_context *ctx, > +struct gl_transform_feedback_object *obj); > Argh, I fail at code review. I found another problem: this function is missing the argument "GLenum mode", which should come after "gl_context ctx", causing the function pointer assignment in brw_context.c to generate a warning. It's a benign warning, because the function only uses the ctx argument, and the calling conventions work out so that it gets passed in the same way regardless of whether mode is present. But for portability we should make the function signatures match. > +void > brw_end_transform_feedback(struct gl_context *ctx, >struct gl_transform_feedback_object *obj); > > diff --git a/src/mesa/drivers/dri/i965/brw_gs_emit.c > b/src/mesa/drivers/dri/i965/brw_gs_emit.c > index 72d4eca..5dd3734 100644 > --- a/src/mesa/drivers/dri/i965/brw_gs_emit.c > +++ b/src/mesa/drivers/dri/i965/brw_gs_emit.c > @@ -352,6 +352,15 @@ gen6_sol_program(struct brw_gs_compile *c, struct > brw_gs_prog_key *key, >*/ > brw_MOV(p, get_element_ud(c->reg.header, 5), > get_element_ud(c->reg.SVBI, 0)); > + > + /* Make sure that the buffers have enough room for all the > vertices. */ > + brw_ADD(p, get_element_ud(c->reg.temp, 0), > +get_element_ud(c->reg.SVBI, 0), brw_imm_ud(num_verts)); > + brw_CMP(p, vec1(brw_null_reg()), BRW_CONDITIONAL_L, > +get_element_ud(c->reg.temp, 0), > +get_element_ud(c->reg.SVBI, 4)); > + brw_IF(p, BRW_EXECUTE_1); > + > /* For each vertex, generate code to output each varying using the >* appropriate binding table entry. >*/ > @@ -392,6 +401,7 @@ gen6_sol_program(struct brw_gs_compile *c, struct > brw_gs_prog_key *key, > get_element_ud(c->reg.header, 5), brw_imm_ud(1)); > } > } > + brw_ENDIF(p); > > /* Now, reinitialize the header register from R0 to restore the > parts of >* the register that we overwrote while streaming out transform > feedback > diff --git a/src/mesa/drivers/dri/i965/gen6_sol.c > b/src/mesa/drivers/dri/i965/gen6_sol.c > index b11bce2..56d4a6a 100644 > --- a/src/mesa/drivers/dri/i965/gen6_sol.c > +++ b/src/mesa/drivers/dri/i965/gen6_sol.c > @@ -26,6 +26,7 @@ > * Code to initialize the binding table entries used by transform feedback. > */ > > +#include "main/macros.h" > #include "brw_context.h" > #include "intel_buffer_objects.h" > #include "intel_batchbuffer.h" > @@ -101,6 +102,43 @@ const struct brw_tracked_state gen6_sol_surface = { > }; > > void > +brw_begin_transform_feedback(struct gl_context *ctx, > +struct gl_transform_feedback_object *obj) > +{ > + struct intel_context *intel = intel_context(ctx); > + const struct gl_shader_program *vs_prog = > + ctx->Shader.CurrentVertexProgram; > + const struct gl_transform_feedback_info *linked_xfb_info = > + &vs_prog->LinkedTransformFeedback; > + struct gl_transform_feedback_object *xfb_obj = > + ctx->TransformFeedback.CurrentObject; > + > + unsigned max_index = 0x; > + > + /* Compute the maximum number of vertices that we can write without > +* overflowing any of the buffers currently being used for feedback. > +*/ > + for (int i = 0; i < MAX_FEEDBACK_ATTRIBS; ++i) { > + unsigned stride = linked_xfb_info->BufferStride[i]; > + > + /* Skip any inactive buffers, which have a stride of 0. */ > + if (stride == 0) > +continue; > + > + unsigned max_for_this_buffer = xfb_obj->Size[i] / (4 * stride); > +
[Mesa-dev] Willing to take Haiku support Patches? (Was: DEATH to old drivers!)
Good afternoon! The Haiku OS project (not-for-profit organization, founded in 2001) has found ourselves in a weird spot, we have a working Mesa software render library based on a *heavily* modified Mesa 7.4.4. http://cgit.haiku-os.org/haiku/tree/src/libs/mesa However as you can imagine, updating that is going to be a *big* pain point. As Haiku is looking to get some basic 3D rendering going on it's cards, we need to do upgrade to a newer version of Mesa. If we produced well thought out Haiku OS support patches, would Mesa as a project be interested in accepting them upstream? I think a better direction may be to move away from the heavily custom integrated mesa library and move to stock version. These patches would likely start as run-of-the-mill #ifdef __HAIKU__ macros. As Haiku has a much smaller developer base then Mesa (20-30 commiters) these first steps would greatly assist us in getting hardware assisted 3d acceleration going. Keep in mind this is all early analysis, I haven't tried porting 7.11.2 yet :) Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Don't minify depth when setting up cube map miptrees on Gen4.
Prior to Ironlake, cube maps were stored as 3D textures. In recent refactoring, we removed a separate "layers" parameter in favor of using depth. Unfortunately, depth was getting minified, which is only correct for actual 3D textures. Fixes piglit tests: - bugs/crash-cubemap-order - fbo/fbo-cubemap - texturing/cubemap Also changes texturing/cubemap npot from abort to fail. This hasn't seen a full test run since Piglit on Mesa master hangs GM45 a lot. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_tex_layout.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c b/src/mesa/drivers/dri/i965/brw_tex_layout.c index eaea49b..4c7e88c 100644 --- a/src/mesa/drivers/dri/i965/brw_tex_layout.c +++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c @@ -124,7 +124,8 @@ brw_miptree_layout(struct intel_context *intel, struct intel_mipmap_tree *mt) mt->total_height += y; width = minify(width); height = minify(height); -depth = minify(depth); +if (mt->target == GL_TEXTURE_3D) + depth = minify(depth); if (mt->compressed) { pack_y_pitch = (height + 3) / 4; -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Willing to take Haiku support Patches? (Was: DEATH to old drivers!)
On Mon, Dec 19, 2011 at 11:18 AM, Alexander von Gluck wrote: > Good afternoon! > > The Haiku OS project (not-for-profit organization, founded in 2001) has > found ourselves in a weird spot, we have a working Mesa software > render library based on a *heavily* modified Mesa 7.4.4. > > http://cgit.haiku-os.org/haiku/tree/src/libs/mesa > > However as you can imagine, updating that is going to be a *big* > pain point. As Haiku is looking to get some basic 3D rendering > going on it's cards, we need to do upgrade to a newer version of > Mesa. > > If we produced well thought out Haiku OS support patches, would > Mesa as a project be interested in accepting them upstream? I think > a better direction may be to move away from the heavily custom > integrated mesa library and move to stock version. > > These patches would likely start as run-of-the-mill #ifdef __HAIKU__ > macros. > > As Haiku has a much smaller developer base then Mesa (20-30 commiters) > these first steps would greatly assist us in getting hardware assisted > 3d acceleration going. > > Keep in mind this is all early analysis, I haven't tried porting 7.11.2 > yet :) In general I'm happy to take patches for Haiku. But I wouldn't want to see #ifdef __HAIKU__ lines scattered all over the code. Hopefully, that can be limited to header files as with other platforms. What GPUs/cards do you need to support? Does this involve restoring any legacy drivers that were removed a few weeks ago? Could you move to Gallium-based drivers? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix compilation on cygwin after commit 762c9766c93697af8d7fbaa729aed118789dbe8e
On 12/19/2011 10:45 AM, Jon TURNEY wrote: Fix compilation on cygwin after commit 762c9766c93697af8d7fbaa729aed118789dbe8e "Use VERT_ATTRIB_* indexed array in gl_array_object" added the first non-driver use of ffsll(), which exposes the fact that this isn't provided on cygwin. Found by tinderbox, see [1] [1] http://tinderbox.freedesktop.org/builds/2011-11-30-0017/logs/libGL/#build Signed-off-by: Jon TURNEY --- src/mesa/main/imports.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h index 797f357..d5e3859 100644 --- a/src/mesa/main/imports.h +++ b/src/mesa/main/imports.h @@ -568,7 +568,7 @@ _mesa_init_sqrt_table(void); #ifdef __GNUC__ -#if defined(__MINGW32__) || defined(ANDROID) +#if defined(__MINGW32__) || defined(__CYGWIN__) || defined(ANDROID) #define ffs __builtin_ffs #define ffsll __builtin_ffsll #endif LGTM. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/8] i965 gen6: Initial implementation of transform feedback.
On 17 December 2011 11:50, Eric Anholt wrote: > On Tue, 13 Dec 2011 15:35:18 -0800, Paul Berry > wrote: > > diff --git a/src/mesa/drivers/dri/i965/brw_gs.c > b/src/mesa/drivers/dri/i965/brw_gs.c > > index f5d5898..c323a73 100644 > > --- a/src/mesa/drivers/dri/i965/brw_gs.c > > +++ b/src/mesa/drivers/dri/i965/brw_gs.c > > @@ -183,7 +183,31 @@ static void populate_key( struct brw_context *brw, > > } else if (intel->gen == 6) { > >/* On Gen6, GS is used for transform feedback. */ > >/* _NEW_TRANSFORM_FEEDBACK */ > > - key->need_gs_prog = ctx->TransformFeedback.CurrentObject->Active; > > + if (ctx->TransformFeedback.CurrentObject->Active) { > > + const struct gl_shader_program *shaderprog = > > +ctx->Shader.CurrentVertexProgram; > > + const struct gl_transform_feedback_info *linked_xfb_info = > > +&shaderprog->LinkedTransformFeedback; > > + int i; > > + > > + /* Make sure that the VUE slots won't overflow the unsigned > chars in > > + * key->transform_feedback_bindings[]. > > + */ > > + assert (BRW_VERT_RESULT_MAX <= 256); > > We generally don't put a space between assert and the opening paren. > I prefer to put a space before the opening paren to highlight whenever the thing I am doing is not a function call, as a reminder that flow control or argument evaluation may not be as expected--we follow this convention fairly consistently in i965 for if, for, switch, and while. I think we should do it for assert as well, since assert has both flow control implications (it may abort) and argument evaluation implications (it won't evaluate its argument under non-debug builds). > > Also, this assert is really weird to me. Neither of the two fields in > the key are related to 256 -- there's a 7-bit field, and a > BRW_MAX_SOL_BINDINGS field. (Also, for compile-time checks like this, > we now have STATIC_ASSERT. Hooray!) > The "BRW_MAX_SOL_BINDINGS field" (key->transform_feedback_bindings[]) is related to 256 because it's an array of unsigned chars. Each entry in the array of unsigned chars stores a gl_vert_result, so the assertion is to make sure that all possible gl_vert_result values can fit in an unsigned char without overflow. In retrospect, the assertion should read (VERT_RESULT_MAX <= 256), since the brw-specific extensions to gl_vert_result will never appear in key->transform_feedback_bindings[]. I'll fix that and change the assertion to a STATIC_ASSERT. > > > @@ -107,12 +119,27 @@ static void brw_gs_overwrite_header_dw2(struct > brw_gs_compile *c, > > * of DWORD 2. URB_WRITE messages need the primitive type in bits 6:2 > of > > * DWORD 2. So this function extracts the primitive type field, > bitshifts it > > * appropriately, and stores it in c->reg.header. > > + * > > + * Also, if num_verts is 3, it converts primitive type > > + * _3DPRIM_TRISTRIP_REVERSE to _3DPRIM_TRISTRIP, so that odd numbered > > + * triangles in a triangle strip will render correctly. > > */ > > -static void brw_gs_overwrite_header_dw2_from_r0(struct brw_gs_compile > *c) > > +static void brw_gs_overwrite_header_dw2_from_r0(struct brw_gs_compile > *c, > > +unsigned num_verts) > > { > > struct brw_compile *p = &c->func; > > brw_AND(p, get_element_ud(c->reg.header, 2), > get_element_ud(c->reg.R0, 2), > > brw_imm_ud(0x1f)); > > + if (num_verts == 3) { > > + brw_CMP(p, vec1(brw_null_reg()), BRW_CONDITIONAL_EQ, > > + get_element_ud(c->reg.header, 2), > > + brw_imm_ud(_3DPRIM_TRISTRIP_REVERSE)); > > + { > > + brw_MOV(p, get_element_ud(c->reg.header, 2), > > + brw_imm_ud(_3DPRIM_TRISTRIP)); > > + brw_set_predicate_control(p, BRW_PREDICATE_NONE); > > + } > > + } > > This doesn't mess up normal rendering of tristrips in any way? It looks > like it could be a separate commit to me. > It doesn't mess up normal rendering of tristrips because we also set the GEN6_GS_REORDER bit of gen6_gs_state.c--this causes alternate triangles in a tristrip to be reordered so that they all have the same orientation, so in the geometry shader we need to map _3DPRIM_TRISTRIP_REVERSE to _3DPRIM_TRISTRIP to prevent future pipeline stages from trying to undo the reordering. Having said that, though, I'm going to revert this change, because the reordering performed by GEN6_GS_REORDER is not the reordering we need for transform feedback. For a tristrip with vertices A, B, C, D, and E (in that order), the hardware normally generates triangles in the order ABC, BCD, CDE (which is wrong because BCD is improperly oriented). With reordering it generates ABC, BDC, CDE. However, to ensure that the transform feedback output will render properly when flatshading, we need the order to be ABC, CBD, CDE. So consider this part of the patch NAK'd. I want to wait until we are implementing transform feedbac
Re: [Mesa-dev] [PATCH 1/2] linker: fix strdup memory leak
On 12/19/2011 05:23 AM, Pekka Paalanen wrote: > On Fri, 16 Dec 2011 10:46:11 -0800 > Ian Romanick wrote: > >> On 12/14/2011 11:26 PM, Pekka Paalanen wrote: >>> string_to_uint_map::put() already does a strdup() for the key >>> argument, so we leak the memory allocated by strdup() in >>> link_uniforms.cpp. >>> >>> Remove the extra strdup(), fixes a few Valgrind detected leaks. >> >> Have you run piglit on this? I seem to recall adding the extra >> strdup for a reason. The hash table keeps a copy of the key pointer >> passed to it, and the underlying object may be deleted before the >> hash table is deleted. This can happen if the back-end optimizes >> some uniforms away after the linker has generated the list of >> "active" uniforms. I'm pretty sure there were one or two test cases >> that hit this on i965. > > Sorry, I didn't. Finally got piglit running, though readPixSanity > failed on stencil values. Anyway it's running all.tests now for the > upstream Mesa master, and then I'll run it with my patches. For future reference, you probably want to use quick.tests. It skips valgrind and doesn't iterate over every single visual, so it takes a fraction of the time but still runs basically all the tests. > Oh, this is Sandybridge, btw. > >>> --- a/src/glsl/link_uniforms.cpp >>> +++ b/src/glsl/link_uniforms.cpp >>> @@ -174,8 +174,7 @@ private: >>> if (this->map->get(id, name)) >>> return; >>> >>> - char *key = strdup(name); >>> - this->map->put(this->num_active_uniforms, key); >>> + this->map->put(this->num_active_uniforms, name); >>> >>> /* Each leaf uniform occupies one entry in the list of >>> active >>> * uniforms. > > The whole visit_field() function is this: > >virtual void visit_field(const glsl_type *type, const char *name) >{ > assert(!type->is_record()); > assert(!(type->is_array() && type->fields.array->is_record())); > > /* Count the number of samplers regardless of whether the uniform is >* already in the hash table. The hash table prevents adding the same >* uniform for multiple shader targets, but in this case we want to >* count it for each shader target. >*/ > const unsigned values = values_for_type(type); > if (type->contains_sampler()) { >this->num_shader_samplers += > type->is_array() ? type->array_size() : 1; > } else { >/* Accumulate the total number of uniform slots used by this shader. > * Note that samplers do not count against this limit because they > * don't use any storage on current hardware. > */ >this->num_shader_uniform_components += values; > } > > /* If the uniform is already in the map, there's nothing more to do. >*/ > unsigned id; > if (this->map->get(id, name)) >return; > > char *key = strdup(name); > this->map->put(this->num_active_uniforms, key); > > /* Each leaf uniform occupies one entry in the list of active >* uniforms. >*/ > this->num_active_uniforms++; > this->num_values += values; >} > > The variable 'key' is not used anywhere else but passed to > string_to_uint_map::put(). That function in its whole is: > >void put(unsigned value, const char *key) >{ > /* The low-level hash table structure returns NULL if key is not in the >* hash table. However, users of this map might want to store zero as a >* valid value in the table. Bias the value by +1 so that a >* user-specified zero is stored as 1. This enables ::get to tell the >* difference between a user-specified zero (returned as 1 by >* hash_table_find) and the key not in the table (returned as 0 by >* hash_table_find). >* >* The net effect is that we can't store UINT_MAX in the table. This is >* because UINT_MAX+1 = 0. >*/ > assert(value != UINT_MAX); > hash_table_replace(this->ht, >(void *) (intptr_t) (value + 1), >strdup(key)); >} > > Therefore, as far as I see, 'key' is not used for anything else than > passed again through strdup(), which would effectively be: > >hash_table_replace(..., ..., strdup(strdup(name))); > > I don't see any case where this could not be a leak, or prevent a bug. > > What do I miss? Is there somewhere another put() that overwrites or > overloads this version of put()? > > > Thanks, > pq > > ps. As for the other patch, thanks for the advice on how to fix it > properly. I don't think I can do that this year, though. > ___ > 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
Re: [Mesa-dev] Willing to take Haiku support Patches? (Was: DEATH to old drivers!)
On Mon, 19 Dec 2011 11:44:51 -0700, Brian Paul wrote: On Mon, Dec 19, 2011 at 11:18 AM, Alexander von Gluck wrote: Good afternoon! The Haiku OS project (not-for-profit organization, founded in 2001) has found ourselves in a weird spot, we have a working Mesa software render library based on a *heavily* modified Mesa 7.4.4. http://cgit.haiku-os.org/haiku/tree/src/libs/mesa However as you can imagine, updating that is going to be a *big* pain point. As Haiku is looking to get some basic 3D rendering going on it's cards, we need to do upgrade to a newer version of Mesa. If we produced well thought out Haiku OS support patches, would Mesa as a project be interested in accepting them upstream? I think a better direction may be to move away from the heavily custom integrated mesa library and move to stock version. These patches would likely start as run-of-the-mill #ifdef __HAIKU__ macros. As Haiku has a much smaller developer base then Mesa (20-30 commiters) these first steps would greatly assist us in getting hardware assisted 3d acceleration going. Keep in mind this is all early analysis, I haven't tried porting 7.11.2 yet :) In general I'm happy to take patches for Haiku. But I wouldn't want to see #ifdef __HAIKU__ lines scattered all over the code. Hopefully, that can be limited to header files as with other platforms. What GPUs/cards do you need to support? Does this involve restoring any legacy drivers that were removed a few weeks ago? Could you move to Gallium-based drivers? We are mostly looking for Radeon HD and Intel at the moment (because they represent the newest chipsets we support at the moment) It does not involve restoring the legacy drivers. We want to make sure we support do things correctly to minimize Mesa impact / work, while keeping to the Haiku (aka BeOS) method of graphic driver design as much as possible. Example, in order from top to bottom: Kernel space graphic driver http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/graphics/radeon_hd User space graphic accelerant that maps graphic driver memory http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd User space OpenGL / 3d render that ties back to the accelerant http://cgit.haiku-os.org/haiku/tree/src/add-ons/opengl We can work on getting something working prior to providing patches, I mostly wanted to test the waters to see how the Mesa developers felt before putting the work in :) Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] i965 gen6: Initial implementation of transform feedback.
This patch adds basic transform feedback capability for Gen6 hardware. This consists of several related pieces of functionality: (1) In gen6_sol.c, we set up binding table entries for use by transform feedback. We use one binding table entry per transform feedback varying (this allows us to avoid doing pointer arithmetic in the shader, since we can set up the binding table entries with the appropriate offsets and surface pitches to place each varying at the correct address). (2) In brw_context.c, we advertise the hardware capabilities, which are as follows: MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS 64 MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS4 MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS16 OpenGL 3.0 requires these values to be at least 64, 4, and 4, respectively. The reason we advertise a larger value than required for MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS is that we have already set aside 64 binding table entries, so we might as well make them all available in both separate attribs and interleaved modes. (3) We set aside a single SVBI ("streamed vertex buffer index") for use by transform feedback. The hardware supports four independent SVBI's, but we only need one, since vertices are added to all transform feedback buffers at the same rate. Note: at the moment this index is reset to 0 only when the driver is initialized. It needs to be reset to 0 whenever BeginTransformFeedback() is called, and otherwise preserved. (4) In brw_gs_emit.c and brw_gs.c, we modify the geometry shader program to output transform feedback data as a side effect. (5) In gen6_gs_state.c, we configure the geometry shader stage to handle the SVBI pointer correctly. Note: ordering of vertices is not yet correct for triangle strips (alternate triangles are improperly oriented). This will be addressed in a future patch. Reviewed-by: Kenneth Graunke --- v2 has been updated to reflect Eric Anholt's comments on 12/17 11:50am, as well as Marek Olšák's suggestion to compute offsets in the linker (from "Re: [Mesa-dev] [PATCH 1/8] mesa: Record transform feedback stride in linker output.", 12/14 05:48am). src/mesa/drivers/dri/i965/Makefile.sources |1 + src/mesa/drivers/dri/i965/brw_context.c | 20 + src/mesa/drivers/dri/i965/brw_context.h | 47 +++- src/mesa/drivers/dri/i965/brw_defines.h |6 ++ src/mesa/drivers/dri/i965/brw_eu.h |7 ++ src/mesa/drivers/dri/i965/brw_eu_emit.c | 39 + src/mesa/drivers/dri/i965/brw_gs.c | 26 ++- src/mesa/drivers/dri/i965/brw_gs.h | 20 + src/mesa/drivers/dri/i965/brw_gs_emit.c | 93 - src/mesa/drivers/dri/i965/brw_misc_state.c |2 +- src/mesa/drivers/dri/i965/brw_state.h|1 + src/mesa/drivers/dri/i965/brw_state_upload.c |1 + src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 85 src/mesa/drivers/dri/i965/gen6_gs_state.c|8 ++- src/mesa/drivers/dri/i965/gen6_sol.c | 71 15 files changed, 417 insertions(+), 10 deletions(-) create mode 100644 src/mesa/drivers/dri/i965/gen6_sol.c diff --git a/src/mesa/drivers/dri/i965/Makefile.sources b/src/mesa/drivers/dri/i965/Makefile.sources index cd6a8f4..e50f9c3 100644 --- a/src/mesa/drivers/dri/i965/Makefile.sources +++ b/src/mesa/drivers/dri/i965/Makefile.sources @@ -93,6 +93,7 @@ i965_C_SOURCES := \ gen6_sampler_state.c \ gen6_scissor_state.c \ gen6_sf_state.c \ +gen6_sol.c \ gen6_urb.c \ gen6_viewport_state.c \ gen6_vs_state.c \ diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index faa02bf..eb68bf4 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -178,6 +178,26 @@ brwCreateContext(int api, ctx->Const.MaxTextureMaxAnisotropy = 16.0; + /* Hardware only supports a limited number of transform feedback buffers. +* So we need to override the Mesa default (which is based only on software +* limits). +*/ + ctx->Const.MaxTransformFeedbackSeparateAttribs = BRW_MAX_SOL_BUFFERS; + + /* On Gen6, in the worst case, we use up one binding table entry per +* transform feedback component (see comments above the definition of +* BRW_MAX_SOL_BINDINGS, in brw_context.h), so we need to advertise a value +* for MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS equal to +* BRW_MAX_SOL_BINDINGS. +* +* In "separate components" mode, we need to divide this value by +* BRW_MAX_SOL_BUFFERS, so that the total number of binding table entries +* used up by all buffers will not exceed BRW_MAX_SOL_BINDINGS. +*/ + ctx->Const.MaxTransformFeedbackInterleavedComponents = BRW_MAX_SOL_BINDINGS; + ctx->Const.MaxTransformFeedbackSeparateComponents = + BRW_MAX_SOL_BINDINGS / BRW_MAX
[Mesa-dev] [PATCH 01/10] i965: Add missing SIMD4x2 sample_l_c message #defines.
Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_defines.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h index 0eb7512..1854602 100644 --- a/src/mesa/drivers/dri/i965/brw_defines.h +++ b/src/mesa/drivers/dri/i965/brw_defines.h @@ -799,6 +799,7 @@ enum brw_message_target { #define BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_COMPARE0 #define BRW_SAMPLER_MESSAGE_SIMD16_SAMPLE_COMPARE 2 #define BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_BIAS_COMPARE 0 +#define BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_LOD_COMPARE 1 #define BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_LOD_COMPARE 1 #define BRW_SAMPLER_MESSAGE_SIMD4X2_RESINFO 2 #define BRW_SAMPLER_MESSAGE_SIMD16_RESINFO2 -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] i965/vs: Implement vec4_visitor::generate_tex().
This is the part that takes the vec4_instruction IR and turns it into actual Gen ISA. v2: Add Gen4 messages, don't retype m0 to UW. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_vec4.h|4 + src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 106 +++ 2 files changed, 110 insertions(+), 0 deletions(-) Somehow I completely forgot Gen4 in the last revision. diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h b/src/mesa/drivers/dri/i965/brw_vec4.h index 5bf8027..d3505c3 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4.h +++ b/src/mesa/drivers/dri/i965/brw_vec4.h @@ -549,6 +549,10 @@ public: struct brw_reg src0, struct brw_reg src1); + void generate_tex(vec4_instruction *inst, +struct brw_reg dst, +struct brw_reg src); + void generate_urb_write(vec4_instruction *inst); void generate_oword_dual_block_offsets(struct brw_reg m1, struct brw_reg index); diff --git a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp index 54bbe13..c131343 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp @@ -355,6 +355,104 @@ vec4_visitor::generate_math2_gen4(vec4_instruction *inst, } void +vec4_visitor::generate_tex(vec4_instruction *inst, + struct brw_reg dst, + struct brw_reg src) +{ + int msg_type = -1; + + if (intel->gen >= 5) { + switch (inst->opcode) { + case SHADER_OPCODE_TEX: + case SHADER_OPCODE_TXL: +if (inst->shadow_compare) { + msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LOD_COMPARE; +} else { + msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LOD; +} +break; + case SHADER_OPCODE_TXD: +/* There is no sample_d_c message; comparisons are done manually. */ +msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_DERIVS; +break; + case SHADER_OPCODE_TXF: +msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LD; +break; + case SHADER_OPCODE_TXS: +msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_RESINFO; +break; + default: +assert(!"should not get here: invalid VS texture opcode"); +break; + } + } else { + switch (inst->opcode) { + case SHADER_OPCODE_TEX: + case SHADER_OPCODE_TXL: +if (inst->shadow_compare) { + msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_LOD_COMPARE; + assert(inst->mlen == 3); +} else { + msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_LOD; + assert(inst->mlen == 2); +} +break; + case SHADER_OPCODE_TXD: +/* There is no sample_d_c message; comparisons are done manually. */ +msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_GRADIENTS; +assert(inst->mlen == 4); +break; + case SHADER_OPCODE_TXF: +msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_LD; +assert(inst->mlen == 2); +break; + case SHADER_OPCODE_TXS: +msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_RESINFO; +assert(inst->mlen == 2); +break; + default: +assert(!"should not get here: invalid VS texture opcode"); +break; + } + } + + assert(msg_type != -1); + + if (inst->header_present) { + /* Set up an implied move from g0 to the MRF. */ + src = brw_vec8_grf(0, 0); + } + + uint32_t return_format; + + switch (dst.type) { + case BRW_REGISTER_TYPE_D: + return_format = BRW_SAMPLER_RETURN_FORMAT_SINT32; + break; + case BRW_REGISTER_TYPE_UD: + return_format = BRW_SAMPLER_RETURN_FORMAT_UINT32; + break; + default: + return_format = BRW_SAMPLER_RETURN_FORMAT_FLOAT32; + break; + } + + brw_SAMPLE(p, + dst, + inst->base_mrf, + src, + SURF_INDEX_TEXTURE(inst->sampler), + inst->sampler, + WRITEMASK_XYZW, + msg_type, + 1, /* response length */ + inst->mlen, + inst->header_present, + BRW_SAMPLER_SIMD_MODE_SIMD4X2, + return_format); +} + +void vec4_visitor::generate_urb_write(vec4_instruction *inst) { brw_urb_WRITE(p, @@ -593,6 +691,14 @@ vec4_visitor::generate_vs_instruction(vec4_instruction *instruction, } break; + case SHADER_OPCODE_TEX: + case SHADER_OPCODE_TXD: + case SHADER_OPCODE_TXF: + case SHADER_OPCODE_TXL: + case SHADER_OPCODE_TXS: + generate_tex(inst, dst, src[0]); + break; + case VS_OPCODE_URB_WRITE: generate_urb_write(inst); break; -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] i965/vs: Implement vec4_visitor::visit(ir_texture *).
This translates the GLSL compiler's IR into vec4_instruction IR, generating code to load coordinates, LOD info, shadow comparitors, and so on into the appropriate message registers. It turns out that the SIMD4x2 parameters are identical on Gen 5-7, and the Gen4 code is similar enough that, unlike in the FS, it's easy enough to support all generations in a single function. v2: Load zeros for missing coordinates (fixing vs-texelFetch-sampler1D and 2D on G45), and fix G45 message length for shadow comparisons. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 127 ++-- 1 files changed, 120 insertions(+), 7 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index 853c3ee..b49cf9c 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -25,6 +25,7 @@ extern "C" { #include "main/macros.h" #include "program/prog_parameter.h" +#include "program/sampler.h" } namespace brw { @@ -1755,13 +1756,125 @@ vec4_visitor::visit(ir_call *ir) void vec4_visitor::visit(ir_texture *ir) { - /* FINISHME: Implement vertex texturing. -* -* With 0 vertex samplers available, the linker will reject -* programs that do vertex texturing, but after our visitor has -* run. -*/ - this->result = src_reg(this, glsl_type::vec4_type); + int sampler = _mesa_get_sampler_uniform_value(ir->sampler, prog, &vp->Base); + sampler = vp->Base.SamplerUnits[sampler]; + + /* Should be lowered by do_lower_texture_projection */ + assert(!ir->projector); + + vec4_instruction *inst; + switch (ir->op) { + case ir_tex: + case ir_txl: + inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXL); + break; + case ir_txd: + inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXD); + break; + case ir_txf: + inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXF); + break; + case ir_txs: + inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXS); + break; + case ir_txb: + assert(!"TXB is not valid for vertex shaders."); + } + + inst->header_present = intel->gen < 5; + inst->base_mrf = 2; + inst->mlen = inst->header_present + 1; /* always at least one */ + inst->sampler = sampler; + inst->dst = dst_reg(this, glsl_type::get_instance(ir->type->base_type,4,1)); + inst->shadow_compare = ir->shadow_comparitor != NULL; + + /* MRF for the first parameter */ + int param_base = inst->base_mrf + inst->header_present; + + if (ir->op == ir_txs) { + ir->lod_info.lod->accept(this); + int writemask = intel->gen == 4 ? WRITEMASK_W : WRITEMASK_X; + emit(MOV(dst_reg(MRF, param_base, ir->lod_info.lod->type, writemask), + this->result)); + } else { + int i, coord_mask = 0, zero_mask = 0; + /* Load the coordinate */ + /* FINISHME: gl_clamp_mask and saturate */ + for (i = 0; i < ir->coordinate->type->vector_elements; i++) +coord_mask |= (1 << i); + for (; i < 4; i++) +zero_mask |= (1 << i); + + ir->coordinate->accept(this); + emit(MOV(dst_reg(MRF, param_base, ir->coordinate->type, coord_mask), + this->result)); + emit(MOV(dst_reg(MRF, param_base, ir->coordinate->type, zero_mask), + src_reg(0))); + /* Load the shadow comparitor */ + if (ir->shadow_comparitor) { +ir->shadow_comparitor->accept(this); +emit(MOV(dst_reg(MRF, param_base + 1, ir->shadow_comparitor->type, + WRITEMASK_X), + this->result)); +inst->mlen++; + } + + /* Load the LOD info */ + if (ir->op == ir_txl) { +int mrf, writemask; +if (intel->gen >= 5) { + mrf = param_base + 1; + if (ir->shadow_comparitor) { + writemask = WRITEMASK_Y; + /* mlen already incremented */ + } else { + writemask = WRITEMASK_X; + inst->mlen++; + } +} else /* intel->gen == 4 */ { + mrf = param_base; + writemask = WRITEMASK_Z; +} +ir->lod_info.lod->accept(this); +emit(MOV(dst_reg(MRF, mrf, ir->lod_info.lod->type, writemask), + this->result)); + } else if (ir->op == ir_txf) { +ir->lod_info.lod->accept(this); +emit(MOV(dst_reg(MRF, param_base, ir->lod_info.lod->type, WRITEMASK_W), + this->result)); + } else if (ir->op == ir_txd) { +const glsl_type *type = ir->lod_info.grad.dPdx->type; + +ir->lod_info.grad.dPdx->accept(this); +src_reg dPdx = this->result; +ir->lod_info.grad.dPdy->accept(this); +src_reg dPdy = this->result; + +if (intel->gen >= 5) { + dPdx.swizzle = BRW_SWIZZLE4(SWIZZLE_X,SWIZZLE_X,SWIZZLE_Y,SWIZZLE_Y); + dPdy.swizzle = BRW_SWIZZLE4(SWIZZLE_X
[Mesa-dev] [PATCH 04/10] i965/fs: Factor out texture offset bitfield computation.
We'll want to reuse this for the VS, and it's complex enough that I'd rather not cut and paste it. Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt --- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 19 +-- src/mesa/drivers/dri/i965/brw_shader.cpp | 23 +++ src/mesa/drivers/dri/i965/brw_shader.h |2 ++ 3 files changed, 26 insertions(+), 18 deletions(-) Unchanged from v1. diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp index 9ce6696..1143951 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp @@ -1077,24 +1077,7 @@ fs_visitor::visit(ir_texture *ir) fs_reg coordinate = this->result; if (ir->offset != NULL) { - ir_constant *offset = ir->offset->as_constant(); - assert(offset != NULL); - - signed char offsets[3]; - for (unsigned i = 0; i < ir->offset->type->vector_elements; i++) -offsets[i] = (signed char) offset->value.i[i]; - - /* Combine all three offsets into a single unsigned dword: - * - *bits 11:8 - U Offset (X component) - *bits 7:4 - V Offset (Y component) - *bits 3:0 - R Offset (Z component) - */ - unsigned offset_bits = 0; - for (unsigned i = 0; i < ir->offset->type->vector_elements; i++) { -const unsigned shift = 4 * (2 - i); -offset_bits |= (offsets[i] << shift) & (0xF << shift); - } + uint32_t offset_bits = brw_texture_offset(ir->offset->as_constant()); /* Explicitly set up the message header by copying g0 to msg reg m1. */ emit(BRW_OPCODE_MOV, fs_reg(MRF, 1, BRW_REGISTER_TYPE_UD), diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp b/src/mesa/drivers/dri/i965/brw_shader.cpp index 33c9ae5..1845c3d 100644 --- a/src/mesa/drivers/dri/i965/brw_shader.cpp +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp @@ -239,3 +239,26 @@ brw_math_function(enum opcode op) return 0; } } + +uint32_t +brw_texture_offset(ir_constant *offset) +{ + assert(offset != NULL); + + signed char offsets[3]; + for (unsigned i = 0; i < offset->type->vector_elements; i++) + offsets[i] = (signed char) offset->value.i[i]; + + /* Combine all three offsets into a single unsigned dword: +* +*bits 11:8 - U Offset (X component) +*bits 7:4 - V Offset (Y component) +*bits 3:0 - R Offset (Z component) +*/ + unsigned offset_bits = 0; + for (unsigned i = 0; i < offset->type->vector_elements; i++) { + const unsigned shift = 4 * (2 - i); + offset_bits |= (offsets[i] << shift) & (0xF << shift); + } + return offset_bits; +} diff --git a/src/mesa/drivers/dri/i965/brw_shader.h b/src/mesa/drivers/dri/i965/brw_shader.h index 1054d7a..3e6f579 100644 --- a/src/mesa/drivers/dri/i965/brw_shader.h +++ b/src/mesa/drivers/dri/i965/brw_shader.h @@ -23,9 +23,11 @@ #include #include "brw_defines.h" +#include "glsl/ir.h" #pragma once int brw_type_for_base_type(const struct glsl_type *type); uint32_t brw_conditional_for_comparison(unsigned int op); uint32_t brw_math_function(enum opcode op); +uint32_t brw_texture_offset(ir_constant *offset); -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/10] i965/vs: Add support for texel offsets.
The visit() half computes the values to put in the header based on the IR and simply stuffs that in the vec4_instruction; the emit() half uses this to set up the message header. This works out well since emit() can use brw_reg directly and access individual DWords without kludgery. Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt --- src/mesa/drivers/dri/i965/brw_vec4.h |1 + src/mesa/drivers/dri/i965/brw_vec4_emit.cpp| 18 +- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |6 +- 3 files changed, 23 insertions(+), 2 deletions(-) Unchanged from v1. diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h b/src/mesa/drivers/dri/i965/brw_vec4.h index d3505c3..28da8c0 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4.h +++ b/src/mesa/drivers/dri/i965/brw_vec4.h @@ -271,6 +271,7 @@ public: int conditional_mod; /**< BRW_CONDITIONAL_* */ int sampler; + uint32_t texture_offset; /**< Texture Offset bitfield */ int target; /**< MRT target. */ bool shadow_compare; diff --git a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp index c131343..b2427da 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp @@ -418,7 +418,23 @@ vec4_visitor::generate_tex(vec4_instruction *inst, assert(msg_type != -1); - if (inst->header_present) { + /* Load the message header if present. If there's a texture offset, we need +* to set it up explicitly and load the offset bitfield. Otherwise, we can +* use an implied move from g0 to the first message register. +*/ + if (inst->texture_offset) { + /* Explicitly set up the message header by copying g0 to the MRF. */ + brw_MOV(p, retype(brw_message_reg(inst->base_mrf), BRW_REGISTER_TYPE_UD), +retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD)); + + /* Then set the offset bits in DWord 2. */ + brw_set_access_mode(p, BRW_ALIGN_1); + brw_MOV(p, + retype(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE, inst->base_mrf, 2), +BRW_REGISTER_TYPE_UD), + brw_imm_uw(inst->texture_offset)); + brw_set_access_mode(p, BRW_ALIGN_16); + } else if (inst->header_present) { /* Set up an implied move from g0 to the MRF. */ src = brw_vec8_grf(0, 0); } diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index b49cf9c..b424a0f 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -1781,13 +1781,17 @@ vec4_visitor::visit(ir_texture *ir) assert(!"TXB is not valid for vertex shaders."); } - inst->header_present = intel->gen < 5; + /* Texel offsets go in the message header; Gen4 also requires headers. */ + inst->header_present = ir->offset || intel->gen < 5; inst->base_mrf = 2; inst->mlen = inst->header_present + 1; /* always at least one */ inst->sampler = sampler; inst->dst = dst_reg(this, glsl_type::get_instance(ir->type->base_type,4,1)); inst->shadow_compare = ir->shadow_comparitor != NULL; + if (ir->offset != NULL) + inst->texture_offset = brw_texture_offset(ir->offset->as_constant()); + /* MRF for the first parameter */ int param_base = inst->base_mrf + inst->header_present; -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] i965/fs: Factor out texturing related data from brw_wm_prog_key.
The idea is to reuse this for the VS and (in the future) GS as well. v2: Include yuvtex data since we're not dropping GL_MESA_ycbycr. Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt [v1] --- src/mesa/drivers/dri/i965/brw_fs.cpp |4 +- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 26 ++-- src/mesa/drivers/dri/i965/brw_program.h | 60 ++ src/mesa/drivers/dri/i965/brw_wm.c | 162 + src/mesa/drivers/dri/i965/brw_wm.h | 19 +--- src/mesa/drivers/dri/i965/brw_wm_emit.c |2 +- src/mesa/drivers/dri/i965/brw_wm_fp.c| 10 +- 7 files changed, 168 insertions(+), 115 deletions(-) create mode 100644 src/mesa/drivers/dri/i965/brw_program.h diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index 339044c..8ca4a87 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -1904,10 +1904,10 @@ brw_fs_precompile(struct gl_context *ctx, struct gl_shader_program *prog) for (int i = 0; i < BRW_MAX_TEX_UNIT; i++) { if (fp->Base.ShadowSamplers & (1 << i)) -key.compare_funcs[i] = GL_LESS; +key.tex.compare_funcs[i] = GL_LESS; /* FINISHME: depth compares might use (0,0,0,W) for example */ - key.tex_swizzles[i] = SWIZZLE_XYZW; + key.tex.swizzles[i] = SWIZZLE_XYZW; } if (fp->Base.InputsRead & FRAG_BIT_WPOS) { diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp index 1143951..9f8a44a 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp @@ -623,7 +623,7 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst, fs_reg coordinate, for (int i = 0; i < ir->coordinate->type->vector_elements; i++) { fs_inst *inst = emit(BRW_OPCODE_MOV, fs_reg(MRF, base_mrf + mlen + i), coordinate); -if (i < 3 && c->key.gl_clamp_mask[i] & (1 << sampler)) +if (i < 3 && c->key.tex.gl_clamp_mask[i] & (1 << sampler)) inst->saturate = true; coordinate.reg_offset++; @@ -655,7 +655,7 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst, fs_reg coordinate, for (int i = 0; i < ir->coordinate->type->vector_elements; i++) { fs_inst *inst = emit(BRW_OPCODE_MOV, fs_reg(MRF, base_mrf + mlen + i), coordinate); -if (i < 3 && c->key.gl_clamp_mask[i] & (1 << sampler)) +if (i < 3 && c->key.tex.gl_clamp_mask[i] & (1 << sampler)) inst->saturate = true; coordinate.reg_offset++; } @@ -718,7 +718,7 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst, fs_reg coordinate, base_mrf + mlen + i * 2, coordinate.type), coordinate); -if (i < 3 && c->key.gl_clamp_mask[i] & (1 << sampler)) +if (i < 3 && c->key.tex.gl_clamp_mask[i] & (1 << sampler)) inst->saturate = true; coordinate.reg_offset++; } @@ -830,7 +830,7 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg dst, fs_reg coordinate, fs_reg(MRF, base_mrf + mlen + i * reg_width, coordinate.type), coordinate); - if (i < 3 && c->key.gl_clamp_mask[i] & (1 << sampler)) + if (i < 3 && c->key.tex.gl_clamp_mask[i] & (1 << sampler)) inst->saturate = true; coordinate.reg_offset++; } @@ -978,7 +978,7 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg dst, fs_reg coordinate, for (int i = 0; i < ir->coordinate->type->vector_elements; i++) { fs_inst *inst = emit(BRW_OPCODE_MOV, fs_reg(MRF, base_mrf + mlen), coordinate); -if (i < 3 && c->key.gl_clamp_mask[i] & (1 << sampler)) +if (i < 3 && c->key.tex.gl_clamp_mask[i] & (1 << sampler)) inst->saturate = true; coordinate.reg_offset++; mlen += reg_width; @@ -1023,7 +1023,7 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg dst, fs_reg coordinate, for (int i = 0; i < ir->coordinate->type->vector_elements; i++) { fs_inst *inst = emit(BRW_OPCODE_MOV, fs_reg(MRF, base_mrf + mlen), coordinate); -if (i < 3 && c->key.gl_clamp_mask[i] & (1 << sampler)) +if (i < 3 && c->key.tex.gl_clamp_mask[i] & (1 << sampler)) inst->saturate = true; coordinate.reg_offset++; mlen += reg_width; @@ -1064,11 +1064,11 @@ fs_visitor::visit(ir_texture *ir) */ bool hw_compare_supported = ir->op != ir_txd; if (ir->shadow_comparitor && !hw_compare_supported) { - assert(c->key.compare_funcs[sampler] != GL_NONE); + assert(c->key.tex.compare_funcs[sampler] != GL_NONE); /* No need to
[Mesa-dev] [PATCH 07/10] i965/fs: Only set brw_wm_prog_key data for samplers used by the WM.
This should avoid state-dependent FS recompiles when samplers that are only used by the VS change. Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt --- src/mesa/drivers/dri/i965/brw_wm.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) Unchanged from v1. diff --git a/src/mesa/drivers/dri/i965/brw_wm.c b/src/mesa/drivers/dri/i965/brw_wm.c index f23edfa..cad0af8 100644 --- a/src/mesa/drivers/dri/i965/brw_wm.c +++ b/src/mesa/drivers/dri/i965/brw_wm.c @@ -412,6 +412,7 @@ static void brw_wm_populate_key( struct brw_context *brw, /* BRW_NEW_FRAGMENT_PROGRAM */ const struct brw_fragment_program *fp = (struct brw_fragment_program *)brw->fragment_program; + const struct gl_program *prog = (struct gl_program *) brw->fragment_program; GLuint lookup = 0; GLuint line_aa; GLuint i; @@ -487,7 +488,8 @@ static void brw_wm_populate_key( struct brw_context *brw, /* _NEW_TEXTURE */ for (i = 0; i < BRW_MAX_TEX_UNIT; i++) { - brw_populate_sampler_prog_key_data(ctx, &key->tex, i); + if (prog->TexturesUsed[i]) +brw_populate_sampler_prog_key_data(ctx, &key->tex, i); } /* _NEW_BUFFERS */ -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/10] i965/vs: Add texture related data to brw_vs_prog_key.
Now that this is all factored out, it's trivial to do. Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt --- src/mesa/drivers/dri/i965/brw_vs.c |8 src/mesa/drivers/dri/i965/brw_vs.h |3 +++ 2 files changed, 11 insertions(+), 0 deletions(-) Unchanged from v1. diff --git a/src/mesa/drivers/dri/i965/brw_vs.c b/src/mesa/drivers/dri/i965/brw_vs.c index 81d5f88..6eec973 100644 --- a/src/mesa/drivers/dri/i965/brw_vs.c +++ b/src/mesa/drivers/dri/i965/brw_vs.c @@ -279,8 +279,10 @@ static void brw_upload_vs_prog(struct brw_context *brw) struct intel_context *intel = &brw->intel; struct gl_context *ctx = &intel->ctx; struct brw_vs_prog_key key; + /* BRW_NEW_VERTEX_PROGRAM */ struct brw_vertex_program *vp = (struct brw_vertex_program *)brw->vertex_program; + struct gl_program *prog = (struct gl_program *) brw->vertex_program; int i; memset(&key, 0, sizeof(key)); @@ -316,6 +318,12 @@ static void brw_upload_vs_prog(struct brw_context *brw) } } + /* _NEW_TEXTURE */ + for (i = 0; i < BRW_MAX_TEX_UNIT; i++) { + if (prog->TexturesUsed[i]) +brw_populate_sampler_prog_key_data(ctx, &key.tex, i); + } + /* BRW_NEW_VERTICES */ for (i = 0; i < VERT_ATTRIB_MAX; i++) { if (vp->program.Base.InputsRead & BITFIELD64_BIT(i) && diff --git a/src/mesa/drivers/dri/i965/brw_vs.h b/src/mesa/drivers/dri/i965/brw_vs.h index 8701116..8814251 100644 --- a/src/mesa/drivers/dri/i965/brw_vs.h +++ b/src/mesa/drivers/dri/i965/brw_vs.h @@ -36,6 +36,7 @@ #include "brw_context.h" #include "brw_eu.h" +#include "brw_program.h" #include "program/program.h" @@ -76,6 +77,8 @@ struct brw_vs_prog_key { GLuint copy_edgeflag:1; GLuint point_coord_replace:8; GLuint clamp_vertex_color:1; + + struct brw_sampler_prog_key_data tex; }; -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/10] i965/vs: Implement EXT_texture_swizzle support for VS texturing.
Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_vec4.h |2 + src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 51 +++- 2 files changed, 52 insertions(+), 1 deletions(-) Unchanged from v1 (we decided it worked, but I never officially got a R-b) diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h b/src/mesa/drivers/dri/i965/brw_vec4.h index 28da8c0..2555fa7 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4.h +++ b/src/mesa/drivers/dri/i965/brw_vec4.h @@ -497,6 +497,8 @@ public: void emit_math2_gen4(enum opcode opcode, dst_reg dst, src_reg src0, src_reg src1); void emit_math(enum opcode opcode, dst_reg dst, src_reg src0, src_reg src1); + void swizzle_result(ir_texture *ir, src_reg orig_val, int sampler); + void emit_ndc_computation(); void emit_psiz_and_flags(struct brw_reg reg); void emit_clip_distances(struct brw_reg reg, int offset); diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index b424a0f..74e486c 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -1878,7 +1878,56 @@ vec4_visitor::visit(ir_texture *ir) emit(inst); - this->result = src_reg(inst->dst); + swizzle_result(ir, src_reg(inst->dst), sampler); +} + +void +vec4_visitor::swizzle_result(ir_texture *ir, src_reg orig_val, int sampler) +{ + this->result = orig_val; + + int s = c->key.tex.swizzles[sampler]; + + if (ir->op == ir_txs || ir->type == glsl_type::float_type + || s == SWIZZLE_NOOP) + return; + + int zero_mask = 0, one_mask = 0, copy_mask = 0; + int swizzle[4]; + + for (int i = 0; i < 4; i++) { + switch (GET_SWZ(s, i)) { + case SWIZZLE_ZERO: +zero_mask |= (1 << i); +break; + case SWIZZLE_ONE: +one_mask |= (1 << i); +break; + default: +copy_mask |= (1 << i); +swizzle[i] = GET_SWZ(s, i); +break; + } + } + + this->result = src_reg(this, ir->type); + dst_reg swizzled_result(this->result); + + if (copy_mask) { + orig_val.swizzle = BRW_SWIZZLE4(swizzle[0], swizzle[1], swizzle[2], swizzle[3]); + swizzled_result.writemask = copy_mask; + emit(MOV(swizzled_result, orig_val)); + } + + if (zero_mask) { + swizzled_result.writemask = zero_mask; + emit(MOV(swizzled_result, src_reg(0.0f))); + } + + if (one_mask) { + swizzled_result.writemask = one_mask; + emit(MOV(swizzled_result, src_reg(1.0f))); + } } void -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/10] i965: Advertise our vertex shader texture units.
Previously, we advertised 0 VS texture units. Now that we have proper support for using the sampling engine in the VS, we can advertise 16, which is conveniently the number required for OpenGL 3.0. v2: Enable on Gen4. I hacked up my tests to not use flat ivec varyings and they pass. Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt --- src/mesa/drivers/dri/i965/brw_context.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index faa02bf..5e9cb1f 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -159,7 +159,7 @@ brwCreateContext(int api, ctx->Const.MaxTextureCoordUnits = 8; /* Mesa limit */ ctx->Const.MaxTextureUnits = MIN2(ctx->Const.MaxTextureCoordUnits, ctx->Const.MaxTextureImageUnits); - ctx->Const.MaxVertexTextureImageUnits = 0; /* no vertex shader textures */ + ctx->Const.MaxVertexTextureImageUnits = BRW_MAX_TEX_UNIT; ctx->Const.MaxCombinedTextureImageUnits = ctx->Const.MaxVertexTextureImageUnits + ctx->Const.MaxTextureImageUnits; -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] egl: move unofficial extensions to eglmesaext.h
On 12/19/2011 02:05 AM, Chia-I Wu wrote: > From: Chia-I Wu > > As suggested by Ian in > > http://lists.freedesktop.org/archives/mesa-dev/2011-December/016035.html > > Note that eglext.h has to include eglmesaext.h at the end instead of the > beginning because some extensions in eglmesaext.h depend on the official > extensions. Looks good to me (or at least much better!) For both patches: Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/8] i965 gen6: Initial implementation of transform feedback.
On 16 December 2011 19:50, Kenneth Graunke wrote: > On 12/13/2011 03:35 PM, Paul Berry wrote: > [snip] > > +static void > > +brw_update_sol_surface(struct brw_context *brw, drm_intel_bo *bo, > > + uint32_t *out_offset, unsigned > num_vector_components, > > + unsigned stride_dwords, unsigned offset_dwords, > > + uint32_t buffer_size_minus_1) > > +{ > > + uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 6 * > 4, 32, > > +out_offset); > > + uint32_t width = buffer_size_minus_1 & 0x7f; > > + uint32_t height = (buffer_size_minus_1 & 0xfff80) >> 7; > > + uint32_t depth = (buffer_size_minus_1 & 0x7f0) >> 20; > > + uint32_t pitch_minus_1 = 4*stride_dwords - 1; > > + uint32_t surface_format; > > + uint32_t offset_bytes = 4 * offset_dwords; > > + switch (num_vector_components) { > > + case 1: > > + surface_format = BRW_SURFACEFORMAT_R32_FLOAT; > > + break; > > + case 2: > > + surface_format = BRW_SURFACEFORMAT_R32G32_FLOAT; > > + break; > > + case 3: > > + surface_format = BRW_SURFACEFORMAT_R32G32B32_FLOAT; > > + break; > > + case 4: > > + surface_format = BRW_SURFACEFORMAT_R32G32B32A32_FLOAT; > > + break; > > + default: > > + assert (!"Invalid vector size for transform feedback output"); > > + surface_format = BRW_SURFACEFORMAT_R32_FLOAT; > > + break; > > + } > > Is it possible to have integer transform feedback outputs? If so, we'd > need to adjust this. But we can do that later (if at all). > Yes, integer transform feedback outputs are possible, but I believe that it won't be necessary to adjust this because the data port doesn't do any format conversions on "streamed vertex buffer write" messages. But I'll make sure we have the necessary piglit tests to verify this, and if I'm wrong I'll do a follow-up patch. > > Looks good, Paul. > > Reviewed-by: Kenneth Graunke > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] vertex array regression
Brian, On Monday, December 19, 2011 17:01:07 you wrote: > I still don't get what the purpose of the special mapping of the last > four/five elements is all about. Can you explain that? As far as I can see the last ones should not map to anything. The map is used only in fixed function mode. And there these arrays should not show up as inputs to any fixed function shader. I think that the purpose of the previous mapping was just to fill in anything. The changes I did serve exactly this purpose. But I agree that here should not be any mapping of these attributes in this mode. Attached is a small change that is probably a more clean solution to this mapping problem. The change passes a quick r600g piglit test. > Yeah, I see how the incorrect varying_inputs values was causing > _NEW_ARRAY to get set, thus hiding the problem. The solution looks > correct, but I'm a little worried about performance, as is mentioned > in the comment. > > Marek, made that change back in March. Maybe he can take a look at > this too. I cannot comment on this, since I do not see a performance regression on my use cases. Marek? Greetings Mathias From 67f3e817dfd6cc0e937e95c9fc8b671da9bf406c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?= Date: Mon, 19 Dec 2011 20:53:51 +0100 Subject: [PATCH] vbo: Set unused arrays in fixed function mode to invalid. The vbo module uses index maps to map VBO arrays into VERT_ATTRIB* arrays. The fixed function map contains some entries that are basically unused and are curretly mapped to any array. This change will explicitly map these unused arrays to an invalid array index which is then filtered out. Signed-off-by: Mathias Froehlich --- src/mesa/vbo/vbo_context.c |2 +- src/mesa/vbo/vbo_exec_draw.c |2 ++ src/mesa/vbo/vbo_save_draw.c |2 ++ 3 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c index b2e6bbc..2542c5d 100644 --- a/src/mesa/vbo/vbo_context.c +++ b/src/mesa/vbo/vbo_context.c @@ -185,7 +185,7 @@ GLboolean _vbo_CreateContext( struct gl_context *ctx ) vbo->map_vp_none[VERT_ATTRIB_GENERIC(i)] = VBO_ATTRIB_MAT_FRONT_AMBIENT + i; for (i = NR_MAT_ATTRIBS; i < VERT_ATTRIB_GENERIC_MAX; i++) - vbo->map_vp_none[VERT_ATTRIB_GENERIC(i)] = i; + vbo->map_vp_none[VERT_ATTRIB_GENERIC(i)] = ~((GLuint)0); for (i = 0; i < Elements(vbo->map_vp_arb); i++) vbo->map_vp_arb[i] = i; diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c index dd5363b..ac3ada3 100644 --- a/src/mesa/vbo/vbo_exec_draw.c +++ b/src/mesa/vbo/vbo_exec_draw.c @@ -218,6 +218,8 @@ vbo_exec_bind_arrays( struct gl_context *ctx ) */ for (attr = 0; attr < VERT_ATTRIB_MAX ; attr++) { const GLuint src = map[attr]; + if (VBO_ATTRIB_MAX <= src) + continue; if (exec->vtx.attrsz[src]) { GLsizeiptr offset = (GLbyte *)exec->vtx.attrptr[src] - diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c index fa93ca4..8e84c2e 100644 --- a/src/mesa/vbo/vbo_save_draw.c +++ b/src/mesa/vbo/vbo_save_draw.c @@ -185,6 +185,8 @@ static void vbo_bind_vertex_list(struct gl_context *ctx, for (attr = 0; attr < VERT_ATTRIB_MAX; attr++) { const GLuint src = map[attr]; + if (VBO_ATTRIB_MAX <= src) + continue; if (node_attrsz[src]) { /* override the default array set above */ -- 1.7.4.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.
On Mon, Dec 19, 2011 at 5:49 PM, Dave Airlie wrote: > On Mon, Dec 19, 2011 at 5:39 PM, Brian Paul wrote: >> On 12/19/2011 09:29 AM, Dave Airlie wrote: >>> >>> From: Dave Airlie >>> >>> In the case where a front and back output are specified, the draw code >>> will >>> copy the back output into the front color slot and everything is happy. >>> >>> However if no front is specified then the draw code will do a bad copy >>> (separate patch), but also the frag shader won't pick up the color as there >>> there is >>> no write to COLOR from the vertex shader just BCOLOR. >>> >>> This patch fixes that problem so if it can't find a vertex shader output >>> for the front color slot, it will go and lookup and use one for the back >>> color >>> slot. >>> >>> Signed-off-by: Dave Airlie >>> --- >>> src/gallium/drivers/softpipe/sp_state_derived.c | 5 + >>> 1 files changed, 5 insertions(+), 0 deletions(-) >>> >>> diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c >>> b/src/gallium/drivers/softpipe/sp_state_derived.c >>> index f89d23c..5685997 100644 >>> --- a/src/gallium/drivers/softpipe/sp_state_derived.c >>> +++ b/src/gallium/drivers/softpipe/sp_state_derived.c >>> @@ -121,6 +121,11 @@ softpipe_get_vertex_info(struct softpipe_context >>> *softpipe) >>> src = draw_find_shader_output(softpipe->draw, >>> fsInfo->input_semantic_name[i], >>> fsInfo->input_semantic_index[i]); >>> + if (fsInfo->input_semantic_name[i] == TGSI_SEMANTIC_COLOR&& src >>> == 0) >>> >>> + /* try and find a bcolor */ >>> + src = draw_find_shader_output(softpipe->draw, >>> + TGSI_SEMANTIC_BCOLOR, >>> fsInfo->input_semantic_index[i]); >>> + >>> draw_emit_vertex_attr(vinfo, EMIT_4F, interp, src); >>> } >>> >> >> And if the VS emits neither a front color or back color, what happens? > > Well the same as happens now, which from what I can see is undefined. > Since if the > VS emits no colors and the FS expects a color, you have a problem, I'm > not sure if the > linker deals with this. > >> It seems to me that if the VS doesn't emit a front color and the polygon >> ends up being front-facing, the polygon color is undefined. > > Yes the test seems to not care about the value in the front in this case at > all, > but maybe Ian or someone with more spec can say what the chapter/verse is. > GLSL 1.30 7.6 says "The following built-in vertex output variables are available. A particular one should be written to if any functionality in a corresponding fragment shader or fixed pipeline uses it or state derived from it. Otherwise, behavior is undefined." where it defines the front/back builtins. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: remove stray GL_TEXTURE_1D_ARRAY code in _mesa_store_teximage3d()
GL_TEXTURE_1D_ARRAY is never a legal target for glTexImage3D. This was probably copy&paste code from the _mesa_store_teximage2d() function above. --- src/mesa/main/texstore.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c index a57a38e..cfe1c24 100644 --- a/src/mesa/main/texstore.c +++ b/src/mesa/main/texstore.c @@ -4775,11 +4775,6 @@ _mesa_store_teximage3d(struct gl_context *ctx, GLenum target, GLint level, return; } - if (target == GL_TEXTURE_1D_ARRAY) { - depth = height; - height = 1; - } - sliceMaps = (GLubyte **) calloc(depth, sizeof(GLubyte *)); /* Map dest texture buffer slices */ -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Maarten Lankhorst wrote: Hey Andy, On 12/19/2011 01:50 PM, Andy Furniss wrote: Maarten Lankhorst wrote: Looks like I made the checking a bit too paranoid, causing it to not always decode last few macroblocks because of fear of reaching end of stream.. Does this work? I removed a few paranoid asserts, and if performance is still bad, I'll alter the patch to swap between multiple decode buffers to fix it. That should bring performance back to old level. This version does fix the macroblocks issue. Perf is still poor. The dvd assert is also still present. It doesn't happen with all dvds - and is not a regression caused by this patch. When playing with -cache and skipping around I get a different assert - attached are backtraces from both types. Yeah that version didn't fix performance yet, this one should have the same performance as before. However those backtraces miss the interesting parts, could you build with -O0 instead of -O2 for a complete backtrace? Perf is back to how it was - just good enough (vdpau is not exactly fast compared to anything else), xvmc is better, but has an issue (not new) where sometimes it looks jittery like the frame order is wrong (only seen on HD with my card on low). I compiled with -O0 but the backtraces are different - maybe there is some randomness. When getting the skip one I managed to get a couple of hangs rather than crashes. One of which I could see was trying some strange resize, eg. instead of VO: [vdpau] 720x576 => 1024x576 MPEG2 VDPAU acceleration I could see something like (from memory) VO: [vdpau] 19x1893 => 2032x2125 MPEG2 VDPAU acceleration and it hung in the process of enlarging the window. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Andy Furniss wrote: I compiled with -O0 but the backtraces are different - maybe there is some randomness. Remembered to attach them this time :-) mplayer: vl/vl_vlc.h:172: vl_vlc_get_vlclbf: Assertion `tbl->length' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0xb6c03a10 (LWP 26420)] 0xe424 in __kernel_vsyscall () (gdb) bt full #0 0xe424 in __kernel_vsyscall () No symbol table info available. #1 0xb6dc115a in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb6dc2787 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb6dba69e in __assert_fail () from /lib/libc.so.6 No symbol table info available. #4 0xb5eafd61 in vl_vlc_get_vlclbf (vlc=0x9e921c8, tbl=0xb5f3d720, num_bits=11) at vl/vl_vlc.h:172 __PRETTY_FUNCTION__ = "vl_vlc_get_vlclbf" #5 0xb5eaf79d in decode_slice (bs=0x9e9216c, code=2) at vl/vl_mpeg12_bitstream.c:829 inc = 0 mb = {base = {codec = PIPE_VIDEO_CODEC_MPEG12}, x = 92, y = 1, macroblock_type = 10 '\n', macroblock_modes = {bits = {frame_motion_type = 2, field_motion_type = 0, dct_type = 0}, value = 2}, motion_vertical_field_select = 0 '\0', PMV = {{{0, 17}, {0, 0}}, {{0, 17}, {0, 0}}}, coded_block_pattern = 40, blocks = 0xbfb0b624, num_skipped_macroblocks = 0} dct_blocks = {0, 0, 0, 5, 0, 5, -5, 0 , 5, 0 } dct_scale = 5 x = 92 __PRETTY_FUNCTION__ = "decode_slice" #6 0xb5eaf1bc in vl_mpg12_bs_decode (bs=0x9e9216c, n=1, len=92477, lens=0xbfb0ba00, buffer=0xbfb0ba20) at vl/vl_mpeg12_bitstream.c:982 code = 2 __PRETTY_FUNCTION__ = "vl_mpg12_bs_decode" #7 0xb5eace48 in vl_mpeg12_decode_bitstream (decoder=0x9e91420, target=0x9faa850, picture=0xbfb0ba68, n=1, total_len=92477, lens=0xbfb0ba00, data=0xbfb0ba20) at vl/vl_mpeg12_decoder.c:702 dec = (struct vl_mpeg12_decoder *) 0x9e91420 buf = (struct vl_mpeg12_buffer *) 0x9e92114 i = 3 __PRETTY_FUNCTION__ = "vl_mpeg12_decode_bitstream" #8 0xb5e40658 in vlVdpDecoderRender (decoder=9, target=17, picture_info=0x8ae32f4, bitstream_buffer_count=1, bitstream_buffers=0x9fada58) at decode.c:382 data = 0xbfb0ba20 sizes = 0xbfb0ba00 total_size = 92477 vldecoder = (vlVdpDecoder *) 0x9e621a8 vlsurf = (vlVdpSurface *) 0x9f53888 ret = VDP_STATUS_OK dec = (struct pipe_video_decoder *) 0x9e91420 i = 1 desc = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, mpeg12 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0x9ef4fa0, ref_backward = 0x0, picture_coding_type = 2, picture_structure = 3, frame_pred_frame_dct = 1, q_scale_type = 1, alternate_scan = 0, intra_vlc_format = 1, concealment_motion_vectors = 0, intra_dc_precision = 2, f_code = {{5, 5}, {4, 3}}, top_field_first = 1, full_pel_forward_vector = 0, full_pel_backward_vector = 0, num_slices = 35, intra_matrix = 0x8ae330f "\b\b\n\v\r\016\017\021\b\b\v\f\016\017\021\023\n\v\r\016\017\021\021\023\v\v\r\016\017\021\023\024\v\r\016\017\020\022\024\030\r\016\017\020\022\024\030\035\r\016\017\021\023\027\034#\016\017\022\023\027\034#*\b\t\t\n\n\v\v\f\t\t\n\n\v\v\f\f\t\n\n\v\v\f\f\r\n\n\v\v\f\f\r\016\n\v\v\f\r\r\016\016\v\v\f\f\r\016\016\017\v\f\f\r\016\016\017\020\f\f\r\016\016\017\020\021", non_intra_matrix = 0x8ae334f "\b\t\t\n\n\v\v\f\t\t\n\n\v\v\f\f\t\n\n\v\v\f\f\r\n\n\v\v\f\f\r\016\n\v\v\f\r\r\016\016\v\v\f\f\r\016\016\017\v\f\f\r\016\016\017\020\f\f\r\016\016\017\020\021"}, mpeg4 = {base = { profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0x9ef4fa0, ref_backward = 0x0, trd = {2, 3}, trb = {1, 1}, vop_time_increment_resolution = 0, vop_coding_type = 0 '\0', vop_fcode_forward = 0 '\0', vop_fcode_backward = 1 '\001', resync_marker_disable = 0 '\0', interlaced = 0 '\0', quant_type = 0 '\0', quarter_sample = 0 '\0', short_video_header = 0 '\0', rounding_control = 0 '\0', alternate_vertical_scan_flag = 0 '\0', top_field_first = 2 '\002', intra_matrix = 0x5 , non_intra_matrix = 0x5 }, vc1 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0x9ef4fa0, ref_backward = 0x0, slice_count = 2, picture_type = 3 '\003', frame_coding_mode = 0 '\0', postprocflag = 0 '\0', pulldown = 0 '\0', interlace = 1 '\001', tfcntrflag = 0 '\0', finterpflag = 0 '\0', psf = 0 '\0', dquant = 1 '\001', panscan_flag = 0 '\0', refdist_flag = 0 '\0', quantizer = 0 '\0', extended_mv = 0 '\0', extended_dmv = 0 '\0', overlap = 0 '\0', vstransform = 0 '\0', loopfilter = 1 '\001', fastuvmc = 0 '\0', range_mapy_flag = 0 '\0', range_mapy = 0 '\0', range_mapuv_flag = 0 '\0', range_mapuv = 0 '\0', multires = 0 '\0', syncmarker = 0 '\0', rangered = 2 '\002', maxbframes = 0 '\0', deblockEnable = 0 '\0', pquant = 0 '\0'}} #9 0x080f9855 in draw_slice (image=0xbfb0bb5c, stride=0xbfb0bb4c, w=720, h=576, x=0, y=0) at libvo/vo_vdpau.c:995 vdp_st = rndr = (struct vdpau_render_state *) 0x
Re: [Mesa-dev] [PATCH 1/2] linker: fix strdup memory leak
On 12/19/2011 05:23 AM, Pekka Paalanen wrote: On Fri, 16 Dec 2011 10:46:11 -0800 Ian Romanick wrote: On 12/14/2011 11:26 PM, Pekka Paalanen wrote: string_to_uint_map::put() already does a strdup() for the key argument, so we leak the memory allocated by strdup() in link_uniforms.cpp. Remove the extra strdup(), fixes a few Valgrind detected leaks. Have you run piglit on this? I seem to recall adding the extra strdup for a reason. The hash table keeps a copy of the key pointer passed to it, and the underlying object may be deleted before the hash table is deleted. This can happen if the back-end optimizes some uniforms away after the linker has generated the list of "active" uniforms. I'm pretty sure there were one or two test cases that hit this on i965. Sorry, I didn't. Finally got piglit running, though readPixSanity failed on stencil values. Anyway it's running all.tests now for the upstream Mesa master, and then I'll run it with my patches. Oh, this is Sandybridge, btw. --- a/src/glsl/link_uniforms.cpp +++ b/src/glsl/link_uniforms.cpp @@ -174,8 +174,7 @@ private: if (this->map->get(id, name)) return; - char *key = strdup(name); - this->map->put(this->num_active_uniforms, key); + this->map->put(this->num_active_uniforms, name); /* Each leaf uniform occupies one entry in the list of active * uniforms. The whole visit_field() function is this: virtual void visit_field(const glsl_type *type, const char *name) { assert(!type->is_record()); assert(!(type->is_array()&& type->fields.array->is_record())); /* Count the number of samplers regardless of whether the uniform is * already in the hash table. The hash table prevents adding the same * uniform for multiple shader targets, but in this case we want to * count it for each shader target. */ const unsigned values = values_for_type(type); if (type->contains_sampler()) { this->num_shader_samplers += type->is_array() ? type->array_size() : 1; } else { /* Accumulate the total number of uniform slots used by this shader. * Note that samplers do not count against this limit because they * don't use any storage on current hardware. */ this->num_shader_uniform_components += values; } /* If the uniform is already in the map, there's nothing more to do. */ unsigned id; if (this->map->get(id, name)) return; char *key = strdup(name); this->map->put(this->num_active_uniforms, key); /* Each leaf uniform occupies one entry in the list of active * uniforms. */ this->num_active_uniforms++; this->num_values += values; } The variable 'key' is not used anywhere else but passed to string_to_uint_map::put(). That function in its whole is: void put(unsigned value, const char *key) { /* The low-level hash table structure returns NULL if key is not in the * hash table. However, users of this map might want to store zero as a * valid value in the table. Bias the value by +1 so that a * user-specified zero is stored as 1. This enables ::get to tell the * difference between a user-specified zero (returned as 1 by * hash_table_find) and the key not in the table (returned as 0 by * hash_table_find). * * The net effect is that we can't store UINT_MAX in the table. This is * because UINT_MAX+1 = 0. */ assert(value != UINT_MAX); hash_table_replace(this->ht, (void *) (intptr_t) (value + 1), strdup(key)); } Therefore, as far as I see, 'key' is not used for anything else than passed again through strdup(), which would effectively be: Ah yes, I forgot that I added that in string_to_uint_map::put. You are quite correct. Okay, the original patch is: Reviewed-by: Ian Romanick hash_table_replace(..., ..., strdup(strdup(name))); I don't see any case where this could not be a leak, or prevent a bug. What do I miss? Is there somewhere another put() that overwrites or overloads this version of put()? Thanks, pq ps. As for the other patch, thanks for the advice on how to fix it properly. I don't think I can do that this year, though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] egl: move unofficial extensions to eglmesaext.h
On 12/19/2011 02:05 AM, Chia-I Wu wrote: From: Chia-I Wu As suggested by Ian in http://lists.freedesktop.org/archives/mesa-dev/2011-December/016035.html Note that eglext.h has to include eglmesaext.h at the end instead of the beginning because some extensions in eglmesaext.h depend on the official extensions. Reviewed-by: Ian Romanick --- include/EGL/eglext.h | 137 +--- include/EGL/eglmesaext.h | 175 ++ 2 files changed, 176 insertions(+), 136 deletions(-) create mode 100644 include/EGL/eglmesaext.h diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h index 9484b83..800a23d 100644 --- a/include/EGL/eglext.h +++ b/include/EGL/eglext.h @@ -120,43 +120,6 @@ typedef EGLBoolean (EGLAPIENTRYP PFNEGLDESTROYIMAGEKHRPROC) (EGLDisplay dpy, EGL #define EGL_GL_RENDERBUFFER_KHR 0x30B9 /* eglCreateImageKHR target */ #endif -#ifndef EGL_MESA_drm_image -#define EGL_MESA_drm_image 1 -#define EGL_DRM_BUFFER_FORMAT_MESA 0x31D0 /* eglCreateImageKHR attribute */ -#define EGL_DRM_BUFFER_USE_MESA0x31D1 - -/* EGL_DRM_BUFFER_FORMAT_MESA tokens */ -#define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 0x31D2 - -/* EGL_DRM_BUFFER_USE_MESA bits */ -#define EGL_DRM_BUFFER_USE_SCANOUT_MESA0x0001 -#define EGL_DRM_BUFFER_USE_SHARE_MESA 0x0002 -#define EGL_DRM_BUFFER_USE_CURSOR_MESA 0x0004 - -#define EGL_DRM_BUFFER_MESA0x31D3 /* eglCreateImageKHR target */ -#define EGL_DRM_BUFFER_STRIDE_MESA 0x31D4 /* eglCreateImageKHR attribute */ - -#ifdef EGL_EGLEXT_PROTOTYPES -EGLAPI EGLImageKHR EGLAPIENTRY eglCreateDRMImageMESA(EGLDisplay dpy, const EGLint *attrib_list); -EGLAPI EGLBoolean EGLAPIENTRY eglExportDRMImageMESA(EGLDisplay dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride); -#endif -typedef EGLImageKHR (EGLAPIENTRYP PFNEGLCREATEDRMIMAGEMESA) (EGLDisplay dpy, const EGLint *attrib_list); -typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESA) (EGLDisplay dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride); -#endif - -#ifndef EGL_WL_bind_wayland_display -#define EGL_WL_bind_wayland_display 1 - -#define EGL_WAYLAND_BUFFER_WL 0x31D5 /* eglCreateImageKHR target */ -struct wl_display; -#ifdef EGL_EGLEXT_PROTOTYPES -EGLAPI EGLBoolean EGLAPIENTRY eglBindWaylandDisplayWL(EGLDisplay dpy, struct wl_display *display); -EGLAPI EGLBoolean EGLAPIENTRY eglUnbindWaylandDisplayWL(EGLDisplay dpy, struct wl_display *display); -#endif -typedef EGLBoolean (EGLAPIENTRYP PFNEGLBINDWAYLANDDISPLAYWL) (EGLDisplay dpy, struct wl_display *display); -typedef EGLBoolean (EGLAPIENTRYP PFNEGLUNBINDWAYLANDDISPLAYWL) (EGLDisplay dpy, struct wl_display *display); -#endif - #if KHRONOS_SUPPORT_INT64 /* EGLTimeKHR requires 64-bit uint support */ #ifndef EGL_KHR_reusable_sync #define EGL_KHR_reusable_sync 1 @@ -189,75 +152,6 @@ typedef EGLBoolean (EGLAPIENTRYP PFNEGLGETSYNCATTRIBKHRPROC) (EGLDisplay dpy, EG #endif #endif -/* EGL_MESA_screen extension>>> PRELIMINARY<<< */ -#ifndef EGL_MESA_screen_surface -#define EGL_MESA_screen_surface 1 - -#define EGL_BAD_SCREEN_MESA0x4000 -#define EGL_BAD_MODE_MESA 0x4001 -#define EGL_SCREEN_COUNT_MESA 0x4002 -#define EGL_SCREEN_POSITION_MESA 0x4003 -#define EGL_SCREEN_POSITION_GRANULARITY_MESA 0x4004 -#define EGL_MODE_ID_MESA 0x4005 -#define EGL_REFRESH_RATE_MESA 0x4006 -#define EGL_OPTIMAL_MESA 0x4007 -#define EGL_INTERLACED_MESA0x4008 -#define EGL_SCREEN_BIT_MESA0x08 - -typedef khronos_uint32_t EGLScreenMESA; -typedef khronos_uint32_t EGLModeMESA; - -#ifdef EGL_EGLEXT_PROTOTYPES -EGLAPI EGLBoolean EGLAPIENTRY eglChooseModeMESA(EGLDisplay dpy, EGLScreenMESA screen, const EGLint *attrib_list, EGLModeMESA *modes, EGLint modes_size, EGLint *num_modes); -EGLAPI EGLBoolean EGLAPIENTRY eglGetModesMESA(EGLDisplay dpy, EGLScreenMESA screen, EGLModeMESA *modes, EGLint modes_size, EGLint *num_modes); -EGLAPI EGLBoolean EGLAPIENTRY eglGetModeAttribMESA(EGLDisplay dpy, EGLModeMESA mode, EGLint attribute, EGLint *value); -EGLAPI EGLBoolean EGLAPIENTRY eglGetScreensMESA(EGLDisplay dpy, EGLScreenMESA *screens, EGLint max_screens, EGLint *num_screens); -EGLAPI EGLSurface EGLAPIENTRY eglCreateScreenSurfaceMESA(EGLDisplay dpy, EGLConfig config, const EGLint *attrib_list); -EGLAPI EGLBoolean EGLAPIENTRY eglShowScreenSurfaceMESA(EGLDisplay dpy, EGLint screen, EGLSurface surface, EGLModeMESA mode); -EGLAPI EGLBoolean EGLAPIENTRY eglScreenPositionMESA(EGLDisplay dpy, EGLScreenMESA screen, EGLint x, EGLint y); -EGLAPI EGLBoolean EGLAPIENTRY eglQueryScreenMESA(EGLDisplay dpy, EGLScreenMESA screen, EGLint attribute, EGLint *value); -EGLAPI EGLBoolean EGLAPIENTRY eglQueryS
Re: [Mesa-dev] [PATCH 2/2] egl: update headers
On 12/19/2011 02:05 AM, Chia-I Wu wrote: From: Chia-I Wu Update to revision 15052. EGL_MESA_drm_image is now official. But apparently we have our own extension to it and we need this in eglmesaext.h: #ifdef EGL_MESA_drm_image /* Mesa's extension to EGL_MESA_drm_image... */ #ifndef EGL_DRM_BUFFER_USE_CURSOR_MESA #define EGL_DRM_BUFFER_USE_CURSOR_MESA 0x0004 #endif #endif Where is this actually from? Is it in the extension? A layered extension? Outer space? :) It sounds like we need to propagate and update back to the Khronos registry. --- include/EGL/eglext.h | 65 +++- include/EGL/eglmesaext.h | 23 ++-- include/EGL/eglplatform.h |9 +- 3 files changed, 73 insertions(+), 24 deletions(-) diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h index 800a23d..a7ea2ea 100644 --- a/include/EGL/eglext.h +++ b/include/EGL/eglext.h @@ -34,8 +34,8 @@ extern "C" { /* Header file version number */ /* Current version at http://www.khronos.org/registry/egl/ */ -/* $Revision: 12124 $ on $Date: 2010-07-27 20:12:35 -0700 (Tue, 27 Jul 2010) $ */ -#define EGL_EGLEXT_VERSION 7 +/* $Revision: 15052 $ on $Date: 2011-07-06 17:43:46 -0700 (Wed, 06 Jul 2011) $ */ +#define EGL_EGLEXT_VERSION 10 #ifndef EGL_KHR_config_attribs #define EGL_KHR_config_attribs 1 @@ -267,6 +267,67 @@ typedef EGLSurface (EGLAPIENTRYP PFNEGLCREATEPIXMAPSURFACEHIPROC) (EGLDisplay dp #define EGL_COLOR_ARGB_HI 0x8F73 #endif /* EGL_HI_colorformats */ +#ifndef EGL_MESA_drm_image +#define EGL_MESA_drm_image 1 +#define EGL_DRM_BUFFER_FORMAT_MESA 0x31D0 /* CreateDRMImageMESA attribute */ +#define EGL_DRM_BUFFER_USE_MESA0x31D1 /* CreateDRMImageMESA attribute */ +#define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 0x31D2 /* EGL_IMAGE_FORMAT_MESA attribute value */ +#define EGL_DRM_BUFFER_MESA0x31D3 /* eglCreateImageKHR target */ +#define EGL_DRM_BUFFER_STRIDE_MESA 0x31D4 +#define EGL_DRM_BUFFER_USE_SCANOUT_MESA0x0001 /* EGL_DRM_BUFFER_USE_MESA bits */ +#define EGL_DRM_BUFFER_USE_SHARE_MESA 0x0002 /* EGL_DRM_BUFFER_USE_MESA bits */ +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI EGLImageKHR EGLAPIENTRY eglCreateDRMImageMESA (EGLDisplay dpy, const EGLint *attrib_list); +EGLAPI EGLBoolean EGLAPIENTRY eglExportDRMImageMESA (EGLDisplay dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride); +#endif /* EGL_EGLEXT_PROTOTYPES */ +typedef EGLImageKHR (EGLAPIENTRYP PFNEGLCREATEDRMIMAGEMESAPROC) (EGLDisplay dpy, const EGLint *attrib_list); +typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESAPROC) (EGLDisplay dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride); +#endif + +#ifndef EGL_NV_post_sub_buffer +#define EGL_NV_post_sub_buffer 1 +#define EGL_POST_SUB_BUFFER_SUPPORTED_NV 0x30BE +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI EGLBoolean EGLAPIENTRY eglPostSubBufferNV (EGLDisplay dpy, EGLSurface surface, EGLint x, EGLint y, EGLint width, EGLint height); +#endif /* EGL_EGLEXT_PROTOTYPES */ +typedef EGLBoolean (EGLAPIENTRYP PFNEGLPOSTSUBBUFFERNVPROC) (EGLDisplay dpy, EGLSurface surface, EGLint x, EGLint y, EGLint width, EGLint height); +#endif + +#ifndef EGL_ANGLE_query_surface_pointer +#define EGL_ANGLE_query_surface_pointer 1 +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI EGLBoolean eglQuerySurfacePointerANGLE(EGLDisplay dpy, EGLSurface surface, EGLint attribute, void **value); +#endif +typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYSURFACEPOINTERANGLEPROC) (EGLDisplay dpy, EGLSurface surface, EGLint attribute, void **value); +#endif + +#ifndef EGL_ANGLE_surface_d3d_texture_2d_share_handle +#define EGL_ANGLE_surface_d3d_texture_2d_share_handle 1 +#define EGL_D3D_TEXTURE_2D_SHARE_HANDLE_ANGLE 0x3200 +#endif + +#ifndef EGL_NV_coverage_sample_resolve +#define EGL_NV_coverage_sample_resolve 1 +#define EGL_COVERAGE_SAMPLE_RESOLVE_NV 0x3131 +#define EGL_COVERAGE_SAMPLE_RESOLVE_DEFAULT_NV 0x3132 +#define EGL_COVERAGE_SAMPLE_RESOLVE_NONE_NV0x3133 +#endif + +#if KHRONOS_SUPPORT_INT64 /* EGLTimeKHR requires 64-bit uint support */ +#ifndef EGL_NV_system_time +#define EGL_NV_system_time 1 + +typedef khronos_utime_nanoseconds_t EGLuint64NV; + +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI EGLuint64NV EGLAPIENTRY eglGetSystemTimeFrequencyNV(void); +EGLAPI EGLuint64NV EGLAPIENTRY eglGetSystemTimeNV(void); +#endif /* EGL_EGLEXT_PROTOTYPES */ +typedef EGLuint64NV (EGLAPIENTRYP PFNEGLGETSYSTEMTIMEFREQUENCYNVPROC) (void); +typedef EGLuint64NV (EGLAPIENTRYP PFNEGLGETSYSTEMTIMENVPROC) (void); +#endif +#endif + #include #ifdef __cplusplus diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h index 1b83778..53576ba 100644 --- a/include/EGL/eglmesaext.h +++ b/include/EGL/eglmesaext.h @@ -102,28 +102,11 @@ typedef EGLDisplay (EGLAPIENTRYP PFNEGLGETDRMDISPLAYMESA) (int fd)
Re: [Mesa-dev] [PATCH] i965: Don't minify depth when setting up cube map miptrees on Gen4.
On Mon, 19 Dec 2011 10:38:38 -0800, Kenneth Graunke wrote: > Prior to Ironlake, cube maps were stored as 3D textures. In recent > refactoring, we removed a separate "layers" parameter in favor of using > depth. Unfortunately, depth was getting minified, which is only correct > for actual 3D textures. > > Fixes piglit tests: > - bugs/crash-cubemap-order > - fbo/fbo-cubemap > - texturing/cubemap > > Also changes texturing/cubemap npot from abort to fail. > > This hasn't seen a full test run since Piglit on Mesa master hangs > GM45 a lot. > > Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt pgpEvXwcYxrz8.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 5/6] vl: Remove most members of pipe_video_decoder
Hey Andy, On 12/19/2011 10:17 PM, Andy Furniss wrote: > Andy Furniss wrote: > >> I compiled with -O0 but the backtraces are different - maybe there is >> some randomness. > > Remembered to attach them this time :-) Thanks, but nothing seems to be obviously wrong there. I don't suppose you could find a small sample file that would trigger the problem? ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove stray GL_TEXTURE_1D_ARRAY code in _mesa_store_teximage3d()
On Mon, 19 Dec 2011 13:47:42 -0700, Brian Paul wrote: > GL_TEXTURE_1D_ARRAY is never a legal target for glTexImage3D. This was > probably copy&paste code from the _mesa_store_teximage2d() function above. Radeon and intel use texstore3d for all our TexImage* storage. Though it does look like we could dump our 1D and 3D overrides of 1D and 3D, and then use texstore2d. pgpcSPyYdBnOL.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] mesa: remove stray GL_TEXTURE_1D_ARRAY code in _mesa_store_teximage3d()
On 12/19/2011 02:56 PM, Eric Anholt wrote: On Mon, 19 Dec 2011 13:47:42 -0700, Brian Paul wrote: GL_TEXTURE_1D_ARRAY is never a legal target for glTexImage3D. This was probably copy&paste code from the _mesa_store_teximage2d() function above. Radeon and intel use texstore3d for all our TexImage* storage. Though it does look like we could dump our 1D and 3D overrides of 1D and 3D, and then use texstore2d. OK, I'll leave that as-is for now. There should probably be a comment explaining what's going on there. I found this when I was looking at consolidating the texstore code. I think that all six variations of 1D/2D/3D whole/sub-image could be consolidated into one function. I'll see if I can finish that up tonight. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix build with LLVM >= r145623.
This is a workaround for https://bugs.freedesktop.org/show_bug.cgi?id=43861. Actually the issue which makes -pedantic failing should be solved. --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index a4943e1..8e809b9 100644 --- a/configure.ac +++ b/configure.ac @@ -1753,7 +1753,7 @@ if test "x$enable_gallium_llvm" = xyes; then if test "x$LLVM_CONFIG" != xno; then LLVM_VERSION=`$LLVM_CONFIG --version` - LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed 's/-DNDEBUG\>//g'` + LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed -e 's/-DNDEBUG\>//g' -e 's/-pedantic//g'` LLVM_LIBS="`$LLVM_CONFIG --libs`" LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` -- 1.7.7 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix build with LLVM >= r145623.
> -Original Message- > > This is a workaround for > https://bugs.freedesktop.org/show_bug.cgi?id=43861. > > Actually the issue which makes -pedantic failing should be solved. > --- > configure.ac |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/configure.ac b/configure.ac > index a4943e1..8e809b9 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1753,7 +1753,7 @@ if test "x$enable_gallium_llvm" = xyes; then > > if test "x$LLVM_CONFIG" != xno; then > LLVM_VERSION=`$LLVM_CONFIG --version` > - LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed 's/-DNDEBUG\>//g'` > + LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed -e 's/-DNDEBUG\>//g' -e > 's/-pedantic//g'` > LLVM_LIBS="`$LLVM_CONFIG --libs`" > > LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` > -- > 1.7.7 > I don't see this issue with llvm-3.1svn. $ svnversion . 146915 $ llvm-config --version 3.1svn $ llvm-config --cppflags -I/usr/local/include -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Maarten Lankhorst wrote: Hey Andy, On 12/19/2011 10:17 PM, Andy Furniss wrote: Andy Furniss wrote: I compiled with -O0 but the backtraces are different - maybe there is some randomness. Remembered to attach them this time :-) Thanks, but nothing seems to be obviously wrong there. I don't suppose you could find a small sample file that would trigger the problem? I'll try, but I don't think I'll have much luck. I think this one may need a disk involved - maybe also libdvdcss (I can reproduce with different versions of mplayer and softpipe). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] i965: Add missing SIMD4x2 sample_l_c message #defines.
On 12/19/2011 11:09 AM, Kenneth Graunke wrote: Signed-off-by: Kenneth Graunke All but patch 03/10 are: Reviewed-by: Ian Romanick I don't know the code well enough to give a credible R-b for 3. --- src/mesa/drivers/dri/i965/brw_defines.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h index 0eb7512..1854602 100644 --- a/src/mesa/drivers/dri/i965/brw_defines.h +++ b/src/mesa/drivers/dri/i965/brw_defines.h @@ -799,6 +799,7 @@ enum brw_message_target { #define BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_COMPARE0 #define BRW_SAMPLER_MESSAGE_SIMD16_SAMPLE_COMPARE 2 #define BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_BIAS_COMPARE 0 +#define BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_LOD_COMPARE 1 #define BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_LOD_COMPARE 1 #define BRW_SAMPLER_MESSAGE_SIMD4X2_RESINFO 2 #define BRW_SAMPLER_MESSAGE_SIMD16_RESINFO2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glx: Deliver an xlib style error to the application from an XCB error
From: Ian Romanick Signed-off-by: Ian Romanick --- src/glx/glx_error.c | 19 +++ src/glx/glx_error.h |4 2 files changed, 23 insertions(+), 0 deletions(-) diff --git a/src/glx/glx_error.c b/src/glx/glx_error.c index 0855c35..b3860db 100644 --- a/src/glx/glx_error.c +++ b/src/glx/glx_error.c @@ -65,3 +65,22 @@ __glXSendError(Display * dpy, int_fast8_t errorCode, uint_fast32_t resourceID, UnlockDisplay(dpy); } + +void +__glXSendErrorForXcb(Display * dpy, const xcb_generic_error_t *err) +{ + xError error; + + LockDisplay(dpy); + + error.type = X_Error; + error.errorCode = err->error_code; + error.sequenceNumber = err->sequence; + error.resourceID = err->resource_id; + error.minorCode = err->minor_code; + error.majorCode = err->major_code; + + _XError(dpy, &error); + + UnlockDisplay(dpy); +} diff --git a/src/glx/glx_error.h b/src/glx/glx_error.h index 19be38b..eaf6b81 100644 --- a/src/glx/glx_error.h +++ b/src/glx/glx_error.h @@ -29,7 +29,11 @@ #include #include #include +#include void __glXSendError(Display * dpy, int_fast8_t errorCode, uint_fast32_t resourceID, uint_fast16_t minorCode, bool coreX11error); + +_X_HIDDEN void __glXSendErrorForXcb(Display * dpy, + const xcb_generic_error_t *err); -- 1.7.6.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glx: Propagate the glXIsDirect protocol error back to the application
From: Ian Romanick If the server returned BadContext, the error would just get droped on the floor. Fixes the piglit test glx-import-context-single-process NOTE: This is a candidate for the 7.11 branch, but it also requires the previous patch. Signed-off-by: Ian Romanick --- src/glx/glxcmds.c | 29 ++--- 1 files changed, 26 insertions(+), 3 deletions(-) diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c index 0c77817..d3f5bf0 100644 --- a/src/glx/glxcmds.c +++ b/src/glx/glxcmds.c @@ -37,12 +37,12 @@ #include "glapi.h" #include "glxextensions.h" #include "indirect.h" +#include "glx_error.h" #ifdef GLX_DIRECT_RENDERING #ifdef GLX_USE_APPLEGL #include "apple_glx_context.h" #include "apple_glx.h" -#include "glx_error.h" #else #include #ifdef XF86VIDMODE @@ -589,12 +589,19 @@ __glXIsDirect(Display * dpy, GLXContextID contextID) #ifdef USE_XCB xcb_connection_t *c = XGetXCBConnection(dpy); + xcb_generic_error_t *err; xcb_glx_is_direct_reply_t *reply = xcb_glx_is_direct_reply(c, xcb_glx_is_direct (c, contextID), - NULL); + &err); const Bool is_direct = (reply != NULL && reply->is_direct) ? True : False; + + if (err != NULL) { + __glXSendErrorForXcb(dpy, err); + free(err); + } + free(reply); return is_direct; @@ -1429,7 +1436,23 @@ glXImportContextEXT(Display *dpy, GLXContextID contextID) uint32_t screen; Bool got_screen = False; - if (contextID == None || __glXIsDirect(dpy, contextID)) + /* The GLX_EXT_import_context spec says: +* +* "If does not refer to a valid context, then a BadContext +* error is generated; if refers to direct rendering +* context then no error is generated but glXImportContextEXT returns +* NULL." +* +* If contextID is None, generate BadContext on the client-side. Other +* sorts of invalid contexts will be detected by the server in the +* __glXIsDirect call. +*/ + if (contextID == None) { + __glXSendError(dpy, GLXBadContext, contextID, X_GLXIsDirect, false); + return NULL; + } + + if (__glXIsDirect(dpy, contextID)) return NULL; opcode = __glXSetupForCommand(dpy); -- 1.7.6.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/6] i965 gen6: Transform feedback queries
This patch series adds support for the transform feedback queries (PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN) for i965 Gen6. For now, the queries are implemented using software counters, since we don't yet have the necessary kernel support to use the hardware counters. (The kernel support that would be required is the ability to save and restore GPU registers on a context switch, so that primitives rendered by other processes would not be accidentally counted). We'll need to change these to hardware counters before implementing geometry shaders or primitive restart. In addition, patch 3/6 adds logic to re-program the SVBI registers at the start of each new batch. This is necessary to work around the same kernel issue: since the kernel does not save and restore GPU registers, we have to reprogram the SVBI registers at any time when a context switch might have occurred; this means at the start of each batch. At this point transform feedback support for i965 is complete, with the exception of fixing a few of the Piglit EXT_transform_feedback/tessellation tests. I think that it's reasonable to postpone that work until a later bugfix patch, for the following reasons: (a) The tessellation tests that are failing are subtle edge cases (e.g. tessellation of triangle strips flips the orientation of some triangles, and tessellation of quads and polygons fails to preserve the provoking vertex, causing flatshading errors). (b) Transform feedback operates in a completely different way on Gen7, and it's likely that some of these tessellation failures will be unfixable on Gen7. It seems silly to fix subtle edge cases on Gen6 that will be unfixable on Gen7, so I'd rather wait until we have implemented transform feedback on Gen7, and then do whatever is necessary to make Gen6 behave just as well as Gen7. (c) Enabling transform feedback now will allow us to get valuable feedback from the field and from Intel QA. Accordingly, patch 6/6 unconditionally switches on the EXT_transform_feedback extension for i965 gen6. Note: this patch series depends on several previous patches that are still under review on the mailing list: - [PATCH 0/8] i965 gen6: Initial implementation of transform feedback. - [PATCH] i965: Implement bounds checking for transform feedback output. - [PATCH 2/2] i965 gen6: Implement rasterizer discard. If you want to see this patch series in its proper context, you can pull from branch "xf-queries" on git://github.com/stereotype441/mesa.git. [PATCH 1/6] mesa: Add count_tessellated_primitives() function. [PATCH 2/6] mesa: Add a function to query whether a meta-op is in progress. [PATCH 3/6] i965 gen6: Ensure correct transform feedback indices on new batch. [PATCH 4/6] i965: Convert if/else to switch statements in brw_queryobj.c [PATCH 5/6] i965 gen6: Implement transform feedback queries. [PATCH 6/6] i965 gen6: Turn on transform feedback extension unconditionally. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] mesa: Add count_tessellated_primitives() function.
This function computes the number of primitives that will be generated when the given drawing operation is performed. It accounts for the tessellation that is performed on line strips, line loops, triangle strips, triangle fans, quads, quad strips, and polygons, so it is suitable for implementing the primitive counters needed by transform feedback. --- src/mesa/vbo/vbo.h |3 ++ src/mesa/vbo/vbo_exec.c | 48 +++ 2 files changed, 51 insertions(+), 0 deletions(-) diff --git a/src/mesa/vbo/vbo.h b/src/mesa/vbo/vbo.h index f357657..7384790 100644 --- a/src/mesa/vbo/vbo.h +++ b/src/mesa/vbo/vbo.h @@ -137,6 +137,9 @@ void vbo_check_buffers_are_unmapped(struct gl_context *ctx); void vbo_bind_arrays(struct gl_context *ctx); +size_t +count_tessellated_primitives(const struct _mesa_prim *prim); + void GLAPIENTRY _es_Color4f(GLfloat r, GLfloat g, GLfloat b, GLfloat a); diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c index e8d5b39..f1b9dd2 100644 --- a/src/mesa/vbo/vbo_exec.c +++ b/src/mesa/vbo/vbo_exec.c @@ -90,3 +90,51 @@ void vbo_exec_invalidate_state( struct gl_context *ctx, GLuint new_state ) _ae_invalidate_state(ctx, new_state); } + + +/** + * Figure out the number of transform feedback primitives that will be output + * by the given _mesa_prim command, assuming that no geometry shading is done + * and primitive restart is not used. + * + * This is intended for use by driver back-ends in implementing the + * PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries. + */ +size_t +count_tessellated_primitives(const struct _mesa_prim *prim) +{ + size_t num_primitives; + switch (prim->mode) { + case GL_POINTS: + num_primitives = prim->count; + break; + case GL_LINE_STRIP: + num_primitives = prim->count >= 2 ? prim->count - 1 : 0; + break; + case GL_LINE_LOOP: + num_primitives = prim->count >= 2 ? prim->count : 0; + break; + case GL_LINES: + num_primitives = prim->count / 2; + break; + case GL_TRIANGLE_STRIP: + case GL_TRIANGLE_FAN: + case GL_POLYGON: + num_primitives = prim->count >= 3 ? prim->count - 2 : 0; + break; + case GL_TRIANGLES: + num_primitives = prim->count / 3; + break; + case GL_QUAD_STRIP: + num_primitives = prim->count >= 4 ? ((prim->count / 2) - 1) * 2 : 0; + break; + case GL_QUADS: + num_primitives = (prim->count / 4) * 2; + break; + default: + assert (!"Unexpected primitive type in count_tessellated_primitives"); + num_primitives = 0; + break; + } + return num_primitives * prim->num_instances; +} -- 1.7.6.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] mesa: Add a function to query whether a meta-op is in progress.
This is needed by i965 to ensure that transform feedback counters are not incremented during meta-ops. --- src/mesa/drivers/common/meta.c | 10 ++ src/mesa/drivers/common/meta.h |3 +++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index 1683c85..c5c59eb 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -985,6 +985,16 @@ _mesa_meta_end(struct gl_context *ctx) /** + * Determine whether Mesa is currently in a meta state. + */ +GLboolean +_mesa_meta_in_progress(struct gl_context *ctx) +{ + return ctx->Meta->SaveStackDepth != 0; +} + + +/** * Convert Z from a normalized value in the range [0, 1] to an object-space * Z coordinate in [-1, +1] so that drawing at the new Z position with the * default/identity ortho projection results in the original Z value. diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h index 7198139..d13796e 100644 --- a/src/mesa/drivers/common/meta.h +++ b/src/mesa/drivers/common/meta.h @@ -69,6 +69,9 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state); extern void _mesa_meta_end(struct gl_context *ctx); +extern GLboolean +_mesa_meta_in_progress(struct gl_context *ctx); + extern void _mesa_meta_BlitFramebuffer(struct gl_context *ctx, GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1, -- 1.7.6.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] i965 gen6: Ensure correct transform feedback indices on new batch.
We don't currently have kernel support for saving GPU registers on a context switch, so if multiple processes are performing transform feedback at the same time, their SVBI registers will interfere with each other. To avoid this situation, we keep a software shadow of the state of the SVBI 0 register (which is the only register we use), and re-upload it on every new batch. The function that updates the shadow state of SVBI 0 is called brw_update_primitive_count, since it will also be used to update the counters for the PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries. --- src/mesa/drivers/dri/i965/brw_context.h |7 + src/mesa/drivers/dri/i965/brw_draw.c | 33 ++ src/mesa/drivers/dri/i965/brw_state.h|1 + src/mesa/drivers/dri/i965/brw_state_upload.c |1 + src/mesa/drivers/dri/i965/gen6_sol.c | 38 - 5 files changed, 72 insertions(+), 8 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h index e8ebea8..8840a83 100644 --- a/src/mesa/drivers/dri/i965/brw_context.h +++ b/src/mesa/drivers/dri/i965/brw_context.h @@ -145,6 +145,7 @@ enum brw_state_id { BRW_STATE_PROGRAM_CACHE, BRW_STATE_STATE_BASE_ADDRESS, BRW_STATE_HIZ, + BRW_STATE_SOL_INDICES, }; #define BRW_NEW_URB_FENCE (1 << BRW_STATE_URB_FENCE) @@ -174,6 +175,7 @@ enum brw_state_id { #define BRW_NEW_PROGRAM_CACHE (1 << BRW_STATE_PROGRAM_CACHE) #define BRW_NEW_STATE_BASE_ADDRESS (1 << BRW_STATE_STATE_BASE_ADDRESS) #define BRW_NEW_HIZ(1 << BRW_STATE_HIZ) +#define BRW_NEW_SOL_INDICES(1 << BRW_STATE_SOL_INDICES) struct brw_state_flags { /** State update flags signalled by mesa internals */ @@ -983,6 +985,11 @@ struct brw_context struct gl_renderbuffer *depth_rb; } hiz; + struct brw_sol_state { + uint32_t svbi_0_starting_index; + uint32_t svbi_0_max_index; + } sol; + uint32_t render_target_format[MESA_FORMAT_COUNT]; bool format_supported_as_render_target[MESA_FORMAT_COUNT]; }; diff --git a/src/mesa/drivers/dri/i965/brw_draw.c b/src/mesa/drivers/dri/i965/brw_draw.c index 6627a48..774a5ca 100644 --- a/src/mesa/drivers/dri/i965/brw_draw.c +++ b/src/mesa/drivers/dri/i965/brw_draw.c @@ -33,10 +33,12 @@ #include "main/samplerobj.h" #include "main/state.h" #include "main/enums.h" +#include "main/macros.h" #include "tnl/tnl.h" #include "vbo/vbo_context.h" #include "swrast/swrast.h" #include "swrast_setup/swrast_setup.h" +#include "drivers/common/meta.h" #include "brw_draw.h" #include "brw_defines.h" @@ -377,6 +379,34 @@ static void brw_postdraw_set_buffers_need_resolve(struct brw_context *brw) } } +/** + * Update internal counters based on the the drawing operation described in + * prim. + */ +static void +brw_update_primitive_count(struct brw_context *brw, + const struct _mesa_prim *prim) +{ + uint32_t count = count_tessellated_primitives(prim); + if (brw->intel.ctx.TransformFeedback.CurrentObject->Active) { + /* Update brw->sol.svbi_0_max_index to reflect the amount by which the + * hardware is going to increment SVBI 0 when this drawing operation + * occurs. This is necessary because the kernel does not (yet) save and + * restore GPU registers when context switching, so we'll need to be + * able to reload SVBI 0 with the correct value in case we have to start + * a new batch buffer. + */ + unsigned svbi_postincrement_value = + brw->gs.prog_data->svbi_postincrement_value; + uint32_t space_avail = + (brw->sol.svbi_0_max_index - brw->sol.svbi_0_starting_index) + / svbi_postincrement_value; + uint32_t primitives_written = MIN2 (space_avail, count); + brw->sol.svbi_0_starting_index += + svbi_postincrement_value * primitives_written; + } +} + /* May fail if out of video memory for texture or vbo upload, or on * fallback conditions. */ @@ -498,6 +528,9 @@ retry: } } } + + if (!_mesa_meta_in_progress(ctx)) + brw_update_primitive_count(brw, &prim[i]); } if (intel->always_flush_batch) diff --git a/src/mesa/drivers/dri/i965/brw_state.h b/src/mesa/drivers/dri/i965/brw_state.h index a3a470f..d271569 100644 --- a/src/mesa/drivers/dri/i965/brw_state.h +++ b/src/mesa/drivers/dri/i965/brw_state.h @@ -92,6 +92,7 @@ extern const struct brw_tracked_state gen6_gs_state; extern const struct brw_tracked_state gen6_renderbuffer_surfaces; extern const struct brw_tracked_state gen6_sampler_state; extern const struct brw_tracked_state gen6_scissor_state; +extern const struct brw_tracked_state gen6_sol_indices; extern const struct brw_tracked_state gen6_sol_surface; extern const struct brw_tracked_state gen6_sf_state; extern const struct brw_tracked_state gen6_sf_vp; diff --git a/src/mesa/drivers/
[Mesa-dev] [PATCH 4/6] i965: Convert if/else to switch statements in brw_queryobj.c
Previously, i965 only supported two query types: GL_TIME_ELAPSED_EXT and GL_SAMPLES_PASSED_ARB, and it distinguished between the two using if/else statements that compared query->Base.Target to GL_TIME_ELAPSED_EXT. This patch changes the if/else statements to switch statements so that we can add more query types without having to have a chain of else-ifs. --- src/mesa/drivers/dri/i965/brw_queryobj.c | 36 +- 1 files changed, 30 insertions(+), 6 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c b/src/mesa/drivers/dri/i965/brw_queryobj.c index 8875541..3cbd3a6 100644 --- a/src/mesa/drivers/dri/i965/brw_queryobj.c +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c @@ -60,16 +60,24 @@ brw_queryobj_get_results(struct gl_context *ctx, drm_intel_bo_map(query->bo, false); results = query->bo->virtual; - if (query->Base.Target == GL_TIME_ELAPSED_EXT) { + switch (query->Base.Target) { + case GL_TIME_ELAPSED_EXT: if (intel->gen >= 6) query->Base.Result += 80 * (results[1] - results[0]); else query->Base.Result += 1000 * ((results[1] >> 32) - (results[0] >> 32)); - } else { + break; + + case GL_SAMPLES_PASSED_ARB: /* Map and count the pixels from the current query BO */ for (i = query->first_index; i <= query->last_index; i++) { query->Base.Result += results[i * 2 + 1] - results[i * 2]; } + break; + + default: + assert (!"Unrecognized query target in brw_queryobj_get_results()"); + break; } drm_intel_bo_unmap(query->bo); @@ -108,7 +116,8 @@ brw_begin_query(struct gl_context *ctx, struct gl_query_object *q) struct intel_context *intel = intel_context(ctx); struct brw_query_object *query = (struct brw_query_object *)q; - if (query->Base.Target == GL_TIME_ELAPSED_EXT) { + switch (query->Base.Target) { + case GL_TIME_ELAPSED_EXT: drm_intel_bo_unreference(query->bo); query->bo = drm_intel_bo_alloc(intel->bufmgr, "timer query", 4096, 4096); @@ -136,7 +145,9 @@ brw_begin_query(struct gl_context *ctx, struct gl_query_object *q) OUT_BATCH(0); ADVANCE_BATCH(); } - } else { + break; + + case GL_SAMPLES_PASSED_ARB: /* Reset our driver's tracking of query state. */ drm_intel_bo_unreference(query->bo); query->bo = NULL; @@ -145,6 +156,11 @@ brw_begin_query(struct gl_context *ctx, struct gl_query_object *q) brw->query.obj = query; intel->stats_wm++; + break; + + default: + assert (!"Unrecognized query target in brw_begin_query()"); + break; } } @@ -158,7 +174,8 @@ brw_end_query(struct gl_context *ctx, struct gl_query_object *q) struct intel_context *intel = intel_context(ctx); struct brw_query_object *query = (struct brw_query_object *)q; - if (query->Base.Target == GL_TIME_ELAPSED_EXT) { + switch (query->Base.Target) { + case GL_TIME_ELAPSED_EXT: if (intel->gen >= 6) { BEGIN_BATCH(4); OUT_BATCH(_3DSTATE_PIPE_CONTROL); @@ -184,7 +201,9 @@ brw_end_query(struct gl_context *ctx, struct gl_query_object *q) } intel_batchbuffer_flush(intel); - } else { + break; + + case GL_SAMPLES_PASSED_ARB: /* Flush the batchbuffer in case it has writes to our query BO. * Have later queries write to a new query BO so that further rendering * doesn't delay the collection of our results. @@ -200,6 +219,11 @@ brw_end_query(struct gl_context *ctx, struct gl_query_object *q) brw->query.obj = NULL; intel->stats_wm--; + break; + + default: + assert (!"Unrecognized query target in brw_end_query()"); + break; } } -- 1.7.6.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] i965 gen6: Implement transform feedback queries.
This patch adds software-based PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries that work by keeping track of the number of primitives that are sent down the pipeline, and adjusting as necessary to account for the way each primitive type is tessellated. In the long run we'll want to replace this with a hardware-based implementation, because the software approach won't work with geometry shaders or primitive restart. However, at the moment, we don't have the necessary kernel support to implement a hardware-based query (we would need the kernel to save GPU registers when context switching, so that drawing performed by another process doesn't get counted). Fixes Piglit tests EXT_transform_feedback/query-primitives_generated-* and EXT_transform_feedback/query-primitives-written-*. --- src/mesa/drivers/dri/i965/brw_context.h |2 + src/mesa/drivers/dri/i965/brw_draw.c |4 ++ src/mesa/drivers/dri/i965/brw_queryobj.c | 48 ++ 3 files changed, 54 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h index 8840a83..15a781b 100644 --- a/src/mesa/drivers/dri/i965/brw_context.h +++ b/src/mesa/drivers/dri/i965/brw_context.h @@ -988,6 +988,8 @@ struct brw_context struct brw_sol_state { uint32_t svbi_0_starting_index; uint32_t svbi_0_max_index; + uint32_t primitives_generated; + uint32_t primitives_written; } sol; uint32_t render_target_format[MESA_FORMAT_COUNT]; diff --git a/src/mesa/drivers/dri/i965/brw_draw.c b/src/mesa/drivers/dri/i965/brw_draw.c index 774a5ca..082bb9a 100644 --- a/src/mesa/drivers/dri/i965/brw_draw.c +++ b/src/mesa/drivers/dri/i965/brw_draw.c @@ -388,6 +388,7 @@ brw_update_primitive_count(struct brw_context *brw, const struct _mesa_prim *prim) { uint32_t count = count_tessellated_primitives(prim); + brw->sol.primitives_generated += count; if (brw->intel.ctx.TransformFeedback.CurrentObject->Active) { /* Update brw->sol.svbi_0_max_index to reflect the amount by which the * hardware is going to increment SVBI 0 when this drawing operation @@ -404,6 +405,9 @@ brw_update_primitive_count(struct brw_context *brw, uint32_t primitives_written = MIN2 (space_avail, count); brw->sol.svbi_0_starting_index += svbi_postincrement_value * primitives_written; + + /* And update the TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN query. */ + brw->sol.primitives_written += primitives_written; } } diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c b/src/mesa/drivers/dri/i965/brw_queryobj.c index 3cbd3a6..fac7070 100644 --- a/src/mesa/drivers/dri/i965/brw_queryobj.c +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c @@ -75,6 +75,14 @@ brw_queryobj_get_results(struct gl_context *ctx, } break; + case GL_PRIMITIVES_GENERATED: + case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN: + /* We don't actually query the hardware for this value, so query->bo + * should always be NULL and execution should never reach here. + */ + assert (!"Unreachable"); + break; + default: assert (!"Unrecognized query target in brw_queryobj_get_results()"); break; @@ -158,6 +166,20 @@ brw_begin_query(struct gl_context *ctx, struct gl_query_object *q) intel->stats_wm++; break; + case GL_PRIMITIVES_GENERATED: + /* We don't actually query the hardware for this value; we keep track of + * it a software counter. So just reset the counter. + */ + brw->sol.primitives_generated = 0; + break; + + case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN: + /* We don't actually query the hardware for this value; we keep track of + * it a software counter. So just reset the counter. + */ + brw->sol.primitives_written = 0; + break; + default: assert (!"Unrecognized query target in brw_begin_query()"); break; @@ -221,6 +243,32 @@ brw_end_query(struct gl_context *ctx, struct gl_query_object *q) intel->stats_wm--; break; + case GL_PRIMITIVES_GENERATED: + /* We don't actually query the hardware for this value; we keep track of + * it in a software counter. So just read the counter and store it in + * the query object. + */ + query->Base.Result = brw->sol.primitives_generated; + + /* And set brw->query.obj to NULL so that this query won't try to wait + * for any rendering to complete. + */ + query->bo = NULL; + break; + + case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN: + /* We don't actually query the hardware for this value; we keep track of + * it in a software counter. So just read the counter and store it in + * the query object. + */ + query->Base.Result = brw->sol.primitives_written; + + /* And set brw->query.obj to NULL so that this query won't try to w
[Mesa-dev] [PATCH 6/6] i965 gen6: Turn on transform feedback extension unconditionally.
Previously, we only enabled transform feedback when MESA_GL_VERSION_OVERRIDE was 3.0 or greater, since transform feedback support was not completely finished, so it didn't make sense to advertise support for it unless absolutely necessary. Now that transform feedback is fully implemented on gen6, we can enable this extension unconditionally. --- src/mesa/drivers/dri/intel/intel_extensions.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c b/src/mesa/drivers/dri/intel/intel_extensions.c index 2daa2c8..0f2f956 100644 --- a/src/mesa/drivers/dri/intel/intel_extensions.c +++ b/src/mesa/drivers/dri/intel/intel_extensions.c @@ -104,7 +104,7 @@ intelInitExtensions(struct gl_context *ctx) ctx->Const.GLSLVersion = 120; _mesa_override_glsl_version(ctx); - if (intel->gen == 6 && override_version >= 30) + if (intel->gen == 6) ctx->Extensions.EXT_transform_feedback = true; if (intel->gen >= 5) -- 1.7.6.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] vertex array regression
2011/12/19 Mathias Fröhlich : > > Brian, > > On Monday, December 19, 2011 17:01:07 you wrote: >> I still don't get what the purpose of the special mapping of the last >> four/five elements is all about. Can you explain that? > > As far as I can see the last ones should not map to anything. > The map is used only in fixed function mode. And there these arrays should not > show up as inputs to any fixed function shader. I think that the purpose of > the > previous mapping was just to fill in anything. The changes I did serve exactly > this purpose. > > But I agree that here should not be any mapping of these attributes in this > mode. Attached is a small change that is probably a more clean solution to > this mapping problem. > > The change passes a quick r600g piglit test. > >> Yeah, I see how the incorrect varying_inputs values was causing >> _NEW_ARRAY to get set, thus hiding the problem. The solution looks >> correct, but I'm a little worried about performance, as is mentioned >> in the comment. >> >> Marek, made that change back in March. Maybe he can take a look at >> this too. > I cannot comment on this, since I do not see a performance regression on my > use cases. > Marek? The problem back in March and earlier was that the vertex array state was completely recomputed for each draw call even if the user did not change any state at all! There was the validation in the vbo module and then in st/mesa, which were basically needless. It turned out to be the major bottleneck in the game Torcs (in the track called Forza). I checked the source code of Torcs and it confirmed my findings. There was a loop that looked like this: for (i = 0; i < very large number; i++) glDrawElements(...); From that point, it became clear that Mesa is underperforming and that it's fixable. Then I came up with a set of patches which did not address the issue completely, but some cases (like with Torcs) were optimized (well maybe not cleanly as it caused a few regressions too). There still is a lot of cases where the vertex array state is recomputed needlessly, so it still is an open issue. I did not fully understand how the entire vbo module works and why so much state validation was being done there. Even today, drivers have almost no way to know in draw_prims whether the vertex array state is _really_ changed, because core Mesa almost always says "yes, it changed of course! why wouldn't it?" Sadly, performance is usually being put aside and energy is put into more important stuff like new features. I was profiling Mesa quite extensively because there was simply nothing better to do for r300g. I don't expect that's the case with the other drivers. Back on topic. The reason why you don't see a performance regression may be: 1) The vertex array state management is not the bottleneck. 2) You already hit the slowest path, that is recomputing the state completely in every draw call. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] i965 gen6: Transform feedback queries
On 12/19/2011 04:18 PM, Paul Berry wrote: [snip] > - [PATCH 0/8] i965 gen6: Initial implementation of transform feedback. > - [PATCH] i965: Implement bounds checking for transform feedback output. > - [PATCH 2/2] i965 gen6: Implement rasterizer discard. > > If you want to see this patch series in its proper context, you can > pull from branch "xf-queries" on > git://github.com/stereotype441/mesa.git. > > [PATCH 1/6] mesa: Add count_tessellated_primitives() function. > [PATCH 2/6] mesa: Add a function to query whether a meta-op is in progress. > [PATCH 3/6] i965 gen6: Ensure correct transform feedback indices on new batch. > [PATCH 4/6] i965: Convert if/else to switch statements in brw_queryobj.c > [PATCH 5/6] i965 gen6: Implement transform feedback queries. > [PATCH 6/6] i965 gen6: Turn on transform feedback extension unconditionally. For the series: Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: Set the correct ctx->NewState bitfield for rasterizer discard.
On Thu, Dec 15, 2011 at 7:21 PM, Paul Berry wrote: > On 15 December 2011 08:02, Eric Anholt wrote: >> >> On Thu, 15 Dec 2011 00:00:49 +0100, Marek Olšák wrote: >> > On Wed, Dec 14, 2011 at 11:25 PM, Paul Berry >> > wrote: >> > > (c) Do nothing, and rely on programmers to remember that RasterDiscard >> > > is an >> > > exception to the usual correspondence between dirty bits and >> > > substructures >> > > of gl_context. >> > > >> > > I'm really not comfortable with (c) because of the risk of future >> > > bugs. I >> > > suppose I could be talked into (b) if there's popular support for it, >> > > but >> > > it's not my favourite, because as I said earlier, I think there are >> > > actually >> > > a lot of good reasons to think of rasterizer discard as related to >> > > transform >> > > feedback. My preference is to do (a). >> > >> > (d) Rework the _NEW_* flags such that they roughly match hardware >> > state groups, not OpenGL state groups. Direct3D 11 and Gallium are two >> > examples of how it could be done. >> >> The problem is that everyone disagrees on what "hardware state group" a >> piece of state is in. On i965, rasterizer discard is really in the >> transform feedback state -- the SOL (transform feedback) unit on gen7, >> and the GS on gen6. > > > I have been thinking about this more this morning, and I have an idea for > how to accomplish (d) that I think would address this problem. It's not a > trivial change, but it's something we could implement incrementally, so we > apply it to rasterizer discard now, and over time extend it to cover other > pieces of state. Here's the idea: > > The key problem is that there are so many distinct pieces of state that we > could never possibly assign a separate bit to each one--we would run out of > space in the bitfield. So instead of having core Mesa decide how they are > grouped (and, inevitably, wind up grouping them in a way that doesn't work > well for some drivers), let each driver decide how they are grouped. The > drivers communicate this grouping to core Mesa by populating a new data > structure (at initialization time) called ctx->StateFlags. ctx->StateFlags > has an entry for each distinct piece of state, which tells which bits in > ctx->NewState should be set when that state changes. > > So, for example, in BeginTransformFeedback() and EndTransformFeedback(), > instead of doing this: > > FLUSH_VERTICES(ctx, _NEW_TRANSFORM_FEEDBACK); > > We would do this: > > FLUSH_VERTICES(ctx, ctx->StateFlags->TransformFeedback_Active); > > In PauseTransformFeedback() and ResumeTransformFeedback() we would do: > > FLUSH_VERTICES(ctx, ctx->StateFlags->TransformFeedback_Paused); > > And in enable.c, when rasterizer discard is turned on or off, we would do: > > FLUSH_VERTICES(ctx, ctx->StateFlags->RasterizerDiscard); > > In the i965 driver, where all of these features map to the GS stage of the > pipeline, we would initialize TransformFeedback_Active, > TransformFeedback_Paused, and RasterizerDiscard all to the same value. In > the r600 driver, where rasterizer discard is implemented using face culling, > StateFlags->RasterizerDiscard would indicate a totally different bit than > those used for transform feedback. > > In the short term, we could implement this technique just for rasterizer > discard, to address the differences between r600 and i965 that we're > discussing in this email thread. In the long term, our goal would be to > replace all of the _NEW_* constants with a fine-grained set of values in > StateFlags. Once we've done that, each driver can set up StateFlags in a > way that precisely matches how state is grouped for that particular piece of > hardware. > > What do y'all think? If there's support for this idea I'd be glad to make > an RFC patch. I like this idea very much. However, there is a catch that some _NEW flags are used for core Mesa, others are used for the vbo module, others are used for generating fixed function programs, others just notify about a change in constant buffers (e.g. the gl_* variables in GLSL) and so on, and finally, most are consumed by drivers to generate states. I am sure we can do this incrementally though and doing the easy stuff first. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: consolidate texstore functions
From: Brian Paul The code for storing 1D, 2D and 3D tex images (whole or sub-images) was all pretty similar. This consolidates those six paths. --- src/mesa/main/texstore.c | 475 ++ 1 files changed, 144 insertions(+), 331 deletions(-) diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c index fb1ad04..10cd751 100644 --- a/src/mesa/main/texstore.c +++ b/src/mesa/main/texstore.c @@ -4565,9 +4565,128 @@ get_read_write_mode(GLenum userFormat, gl_format texFormat) return GL_MAP_WRITE_BIT; } + +/** + * Helper function for storing 1D, 2D, 3D whole and subimages into texture + * memory. + * The source of the image data may be user memory or a PBO. In the later + * case, we'll map the PBO, copy from it, then unmap it. + */ +static void +store_texsubimage(struct gl_context *ctx, + struct gl_texture_image *texImage, + GLint xoffset, GLint yoffset, GLint zoffset, + GLint width, GLint height, GLint depth, + GLenum format, GLenum type, const GLvoid *pixels, + const struct gl_pixelstore_attrib *packing, + const char *caller) + +{ + const GLbitfield mapMode = get_read_write_mode(format, texImage->TexFormat); + const GLenum target = texImage->TexObject->Target; + GLboolean success = GL_FALSE; + GLuint dims, slice, numSlices = 1, sliceOffset = 0; + GLint srcImageStride = 0; + const GLubyte *src; + + assert(xoffset + width <= texImage->Width); + assert(yoffset + height <= texImage->Height); + assert(zoffset + depth <= texImage->Depth); + + switch (target) { + case GL_TEXTURE_1D: + dims = 1; + break; + case GL_TEXTURE_2D_ARRAY: + case GL_TEXTURE_3D: + dims = 3; + break; + default: + dims = 2; + } + + /* get pointer to src pixels (may be in a pbo which we'll map here) */ + src = (const GLubyte *) + _mesa_validate_pbo_teximage(ctx, dims, width, height, depth, + format, type, pixels, packing, caller); + if (!pixels) + return; + + /* compute slice info (and do some sanity checks) */ + switch (target) { + case GL_TEXTURE_1D: + assert(height == 1); + assert(depth == 1); + assert(yoffset == 0); + assert(zoffset == 0); + break; + case GL_TEXTURE_1D_ARRAY: + assert(depth == 1); + assert(zoffset == 0); + numSlices = height; + sliceOffset = yoffset; + height = 1; + yoffset = 0; + srcImageStride = _mesa_image_row_stride(packing, width, format, type); + break; + case GL_TEXTURE_2D_ARRAY: + numSlices = depth; + sliceOffset = zoffset; + depth = 1; + zoffset = 0; + srcImageStride = _mesa_image_image_stride(packing, width, height, +format, type); + break; + case GL_TEXTURE_3D: + /* we'll store 3D images as a series of slices */ + numSlices = depth; + sliceOffset = zoffset; + srcImageStride = _mesa_image_image_stride(packing, width, height, +format, type); + break; + default: + /* GL_TEXTURE_2D, cube face, etc */ + ; + } + + assert(numSlices == 1 || srcImageStride != 0); + + for (slice = 0; slice < numSlices; slice++) { + GLubyte *dstMap; + GLint dstRowStride; + + ctx->Driver.MapTextureImage(ctx, texImage, + slice + sliceOffset, + xoffset, yoffset, width, height, + mapMode, &dstMap, &dstRowStride); + if (dstMap) { + success = _mesa_texstore(ctx, 2, texImage->_BaseFormat, + texImage->TexFormat, + 0, 0, 0, /* dstX/Y/Zoffset */ + dstRowStride, + &dstMap, + width, height, 1, /* w, h, d */ + format, type, src, packing); + + ctx->Driver.UnmapTextureImage(ctx, texImage, slice + sliceOffset); + } + + src += srcImageStride; + + if (!success) + break; + } + + if (!success) + _mesa_error(ctx, GL_OUT_OF_MEMORY, "%s", caller); + + _mesa_unmap_teximage_pbo(ctx, packing); +} + + + /** - * This is the software fallback for Driver.TexImage1D(). - * \sa _mesa_store_teximage2d() + * This is the fallback for Driver.TexImage1D(). */ void _mesa_store_teximage1d(struct gl_context *ctx, GLenum target, GLint level, @@ -4578,13 +4697,6 @@ _mesa_store_teximage1d(struct gl_context *ctx, GLenum target, GLint level, struct gl_texture_object *texObj, struct gl_texture_image *texImage) { - const GLbitfield rwMode = get_read_write_mode(format, texImage->TexFormat); - GLubyte *dstMap; - GLint dstRowStride; - GLboolean success; - - (vo
Re: [Mesa-dev] vertex array regression
Marek, On Tuesday, December 20, 2011 01:40:46 Marek Olšák wrote: > The problem back in March and earlier was that the vertex array state > was completely recomputed for each draw call even if the user did not > change any state at all! There was the validation in the vbo module > and then in st/mesa, which were basically needless. It turned out to > be the major bottleneck in the game Torcs (in the track called Forza). > I checked the source code of Torcs and it confirmed my findings. There > was a loop that looked like this: > > for (i = 0; i < very large number; i++) glDrawElements(...); > > From that point, it became clear that Mesa is underperforming and that > it's fixable. Then I came up with a set of patches which did not > address the issue completely, but some cases (like with Torcs) were > optimized (well maybe not cleanly as it caused a few regressions too). > There still is a lot of cases where the vertex array state is > recomputed needlessly, so it still is an open issue. I did not fully > understand how the entire vbo module works and why so much state > validation was being done there. Even today, drivers have almost no > way to know in draw_prims whether the vertex array state is _really_ > changed, because core Mesa almost always says "yes, it changed of > course! why wouldn't it?" Sadly, performance is usually being put > aside and energy is put into more important stuff like new features. I > was profiling Mesa quite extensively because there was simply nothing > better to do for r300g. I don't expect that's the case with the other > drivers. > > Back on topic. The reason why you don't see a performance regression may > be: 1) The vertex array state management is not the bottleneck. > 2) You already hit the slowest path, that is recomputing the state > completely in every draw call. Well, in general, to me performance *is* a feature. At least for this kind of software like an OpenGL stack. But correctness is not just a feature, correctness is a hard requirement. So I believe I am all with you... Let me explain, the reason why I am starting work on the vertex arrays is that I think this is one of the major bottlenecks in the draw path that we have today. I think that the array object should behave more like a state that could be used to do just the required things to be ready for the draw code path. The first step towards this was to make the array object an array of client arrays. Then start exploiting more of bitmask/ffs driven loops to reduce the overhead of iterating over all client arrays on almost every draw. Being able to accumulate changed arrays in this kind of flag values is something that could be done now. I have a proof of concept implementation sitting around here that updates the traditional client array pointers used in vbo_draw in a lazy way based on an enabled bitmasks and iterating only on the changed values instead of all. Also we could really derive from the generic array object implementation for the old style vbo_draw and an other implementation for a gallium driver path where we are really able to track changes in the array cso thats currently unconditional application to the gallium state could then probably be pulled out of the draw path for the gallium drivers, which I expect a major win for plenty of use cases... So far to what could be done. But at least to me, experience shows that I better do this kind of stuff, which is on the first front to the OpenGL api specs and also used in so different drivers in so different ways, with very small increments. So this current increment is trying to get back to a stable state past the array change. Ok, back to topic, so have I understood right? You have fixed torcs not to use the slow path anymore? Which old version is the one still having this issue? Do you have any test program that could be used to see the impact of this kind of change? Also your comment mentions that the _Tnl program already cares for invalidating the required state. Do you remember where this happend? May be we could utilize this place to trigger state invalidation then? Thanks Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/13] glx: Make __glXSendError available in non-Apple builds
6, 7, and 13 look good to me, but I haven't tested them yet. Reviewed-by: Jeremy Huddleston On Dec 16, 2011, at 11:55 AM, Ian Romanick wrote: > From: Ian Romanick > > Signed-off-by: Ian Romanick > Cc: Jeremy Huddleston > --- > src/glx/Makefile |1 + > src/glx/apple/Makefile|2 +- > src/glx/apple/glx_error.c | 67 - > src/glx/apple/glx_error.h | 33 -- > src/glx/glx_error.c | 67 + > src/glx/glx_error.h | 33 ++ > 6 files changed, 102 insertions(+), 101 deletions(-) > delete mode 100644 src/glx/apple/glx_error.c > delete mode 100644 src/glx/apple/glx_error.h > create mode 100644 src/glx/glx_error.c > create mode 100644 src/glx/glx_error.h > > diff --git a/src/glx/Makefile b/src/glx/Makefile > index dd96973..183ffb1 100644 > --- a/src/glx/Makefile > +++ b/src/glx/Makefile > @@ -15,6 +15,7 @@ SOURCES = \ > glxconfig.c \ > glxcmds.c \ > glxcurrent.c \ > + glx_error.c \ > glxext.c \ > glxextensions.c \ > indirect_glx.c \ > diff --git a/src/glx/apple/Makefile b/src/glx/apple/Makefile > index 6868d28..66e6658 100644 > --- a/src/glx/apple/Makefile > +++ b/src/glx/apple/Makefile > @@ -39,7 +39,7 @@ SOURCES = \ > ../compsize.c \ > ../glxconfig.c \ > glx_empty.c \ > - glx_error.c \ > + ../glx_error.c \ > ../glx_pbuffer.c \ > ../glx_query.c \ > ../glxcmds.c \ > diff --git a/src/glx/apple/glx_error.c b/src/glx/apple/glx_error.c > deleted file mode 100644 > index d44a80c..000 > --- a/src/glx/apple/glx_error.c > +++ /dev/null > @@ -1,67 +0,0 @@ > -/* > - Copyright (c) 2009 Apple Inc. > - > - 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 the rights to use, copy, modify, merge, > - publish, distribute, sublicense, 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 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 > - NONINFRINGEMENT. IN NO EVENT SHALL THE ABOVE LISTED COPYRIGHT > - HOLDER(S) 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. > - > - Except as contained in this notice, the name(s) of the above > - copyright holders shall not be used in advertising or otherwise to > - promote the sale, use or other dealings in this Software without > - prior written authorization. > -*/ > -#include > -#include > -#include > -#include > -#include > -#include "glxclient.h" > -#include "glx_error.h" > - > -void > -__glXSendError(Display * dpy, int errorCode, unsigned long resourceID, > - unsigned long minorCode, bool coreX11error) > -{ > - struct glx_display *glx_dpy = __glXInitialize(dpy); > - struct glx_context *gc = __glXGetCurrentContext(); > - xError error; > - > - assert(glx_dpy); > - assert(gc); > - > - LockDisplay(dpy); > - > - error.type = X_Error; > - > - if (coreX11error) { > - error.errorCode = errorCode; > - } > - else { > - error.errorCode = glx_dpy->codes->first_error + errorCode; > - } > - > - error.sequenceNumber = dpy->request; > - error.resourceID = resourceID; > - error.minorCode = minorCode; > - error.majorCode = gc ? gc->majorOpcode : 0; > - > - _XError(dpy, &error); > - > - UnlockDisplay(dpy); > -} > diff --git a/src/glx/apple/glx_error.h b/src/glx/apple/glx_error.h > deleted file mode 100644 > index 6ba2f85..000 > --- a/src/glx/apple/glx_error.h > +++ /dev/null > @@ -1,33 +0,0 @@ > -/* > - Copyright (c) 2009 Apple Inc. > - > - 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 the rights to use, copy, modify, merge, > - publish, distribute, sublicense, 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 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
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
On 12/19/2011 11:46 PM, Andy Furniss wrote: > Maarten Lankhorst wrote: >> Hey Andy, >> >> On 12/19/2011 10:17 PM, Andy Furniss wrote: >>> Andy Furniss wrote: >>> I compiled with -O0 but the backtraces are different - maybe there is some randomness. >>> >>> Remembered to attach them this time :-) >> Thanks, but nothing seems to be obviously wrong there. I don't suppose you >> could find a small sample file that would trigger the problem? > > I'll try, but I don't think I'll have much luck. > > I think this one may need a disk involved - maybe also libdvdcss (I can > reproduce with different versions of mplayer and softpipe). Well, I found a video that appears to fail in a similar way to one of your failure modes, they could both be the same but showing in different ways. ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] linker: fix strdup memory leak
On Mon, 19 Dec 2011 11:02:31 -0800 Kenneth Graunke wrote: > On 12/19/2011 05:23 AM, Pekka Paalanen wrote: > > On Fri, 16 Dec 2011 10:46:11 -0800 > > Ian Romanick wrote: > > > >> On 12/14/2011 11:26 PM, Pekka Paalanen wrote: > >>> string_to_uint_map::put() already does a strdup() for the key > >>> argument, so we leak the memory allocated by strdup() in > >>> link_uniforms.cpp. > >>> > >>> Remove the extra strdup(), fixes a few Valgrind detected leaks. > >> > >> Have you run piglit on this? I seem to recall adding the extra > >> strdup for a reason. The hash table keeps a copy of the key > >> pointer passed to it, and the underlying object may be deleted > >> before the hash table is deleted. This can happen if the back-end > >> optimizes some uniforms away after the linker has generated the > >> list of "active" uniforms. I'm pretty sure there were one or two > >> test cases that hit this on i965. > > > > Sorry, I didn't. Finally got piglit running, though readPixSanity > > failed on stencil values. Anyway it's running all.tests now for the > > upstream Mesa master, and then I'll run it with my patches. > > For future reference, you probably want to use quick.tests. It skips > valgrind and doesn't iterate over every single visual, so it takes a > fraction of the time but still runs basically all the tests. Thanks, I killed the first run after 17 hours. From the README I gathered that quick.tests was somehow lacking and all.tests would be preferable. Also, I had no idea of possible running times or what "significantly" there meant. - pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev