Re: [Mesa-dev] [PATCH 03/23] swrast: remove MAX_WIDTH arrays in s_zoom.c
Shouldn't malloc be passed zoomedWidth instead of width?
Jose
- Original Message -
> From: Brian Paul
>
> ---
> src/mesa/swrast/s_zoom.c | 16 ++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/swrast/s_zoom.c b/src/mesa/swrast/s_zoom.c
> index 73bff48..ede8f90 100644
> --- a/src/mesa/swrast/s_zoom.c
> +++ b/src/mesa/swrast/s_zoom.c
> @@ -362,7 +362,7 @@ _swrast_write_zoomed_stencil_span(struct
> gl_context *ctx, GLint imgX, GLint imgY
>GLint width, GLint spanX, GLint
>spanY,
>const GLubyte stencil[])
> {
> - GLubyte zoomedVals[MAX_WIDTH];
> + GLubyte *zoomedVals;
> GLint x0, x1, y0, y1, y;
> GLint i, zoomedWidth;
>
> @@ -375,6 +375,10 @@ _swrast_write_zoomed_stencil_span(struct
> gl_context *ctx, GLint imgX, GLint imgY
> ASSERT(zoomedWidth > 0);
> ASSERT(zoomedWidth <= MAX_WIDTH);
>
> + zoomedVals = (GLubyte *) malloc(width * sizeof(GLubyte));
> + if (!zoomedVals)
> + return;
> +
> /* zoom the span horizontally */
> for (i = 0; i < zoomedWidth; i++) {
>GLint j = unzoom_x(ctx->Pixel.ZoomX, imgX, x0 + i) - spanX;
> @@ -387,6 +391,8 @@ _swrast_write_zoomed_stencil_span(struct
> gl_context *ctx, GLint imgX, GLint imgY
> for (y = y0; y < y1; y++) {
>_swrast_write_stencil_span(ctx, zoomedWidth, x0, y,
>zoomedVals);
> }
> +
> + free(zoomedVals);
> }
>
>
> @@ -401,7 +407,7 @@ _swrast_write_zoomed_z_span(struct gl_context
> *ctx, GLint imgX, GLint imgY,
> {
> struct gl_renderbuffer *rb =
>ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer;
> - GLuint zoomedVals[MAX_WIDTH];
> + GLuint *zoomedVals;
> GLint x0, x1, y0, y1, y;
> GLint i, zoomedWidth;
>
> @@ -414,6 +420,10 @@ _swrast_write_zoomed_z_span(struct gl_context
> *ctx, GLint imgX, GLint imgY,
> ASSERT(zoomedWidth > 0);
> ASSERT(zoomedWidth <= MAX_WIDTH);
>
> + zoomedVals = (GLuint *) malloc(width * sizeof(GLuint));
> + if (!zoomedVals)
> + return;
> +
> /* zoom the span horizontally */
> for (i = 0; i < zoomedWidth; i++) {
>GLint j = unzoom_x(ctx->Pixel.ZoomX, imgX, x0 + i) - spanX;
> @@ -427,4 +437,6 @@ _swrast_write_zoomed_z_span(struct gl_context
> *ctx, GLint imgX, GLint imgY,
>GLubyte *dst = _swrast_pixel_address(rb, x0, y);
>_mesa_pack_uint_z_row(rb->Format, zoomedWidth, zoomedVals,
>dst);
> }
> +
> + free(zoomedVals);
> }
> --
> 1.7.3.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 46376] New: display window will be black when run mesa demo gloss
https://bugs.freedesktop.org/show_bug.cgi?id=46376 Bug #: 46376 Summary: display window will be black when run mesa demo gloss Classification: Unclassified Product: Mesa Version: 8.0 Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: bo.c...@intel.com System Environment: -- Libdrm:(master)2.4.31 Mesa: (8.0)fe77fd3983ba3da16ec53c58a790c381b07387ce Xserver:(server-1.11-branch)xorg-server-1.11.4 Xf86_video_intel:(master)2.17.0-655-g95391b7312147760d8da01fce68b8398aa8e4e2f Cairo:(master)01ea2d31cbbc12dafbe7831ef8c08a1bc78046a7 Libva:(master)bdbc9675fb2529b276bc3e8f720709e75beeae10 Kernel: 3.2.6 + IVB hang-fix patche Bug detailed description: - Display window will be black when start X and run some mesa demos such as gloss, drawpix, readpix, which is caused by mesa. But it is good if started gnome. This bug also exists with the latest master mesa. By the way, 11.11 release has no this bug. Such is a good mesa commit: (7.11)4464ee1a9aa3745109cee23531e3fb2323234d07 Reproduce steps: - 1.xinit& 2../gloss -- 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 20/23] mesa: remove last of MAX_WIDTH, MAX_HEIGHT
Your series is a huge step forward already. But I wonder if we could go just a
bit further and not add MAX_VIEWPORT_WIDTH/HEIGHT and MAX_RENDERBUFFER_SIZE
defines.
Would it be possible to derive these limits from the maximum texture size?
Either the driver reported max texture size, or just define them in terms of
MAX_TEXTURE_LEVELS so that there are less places to change next time we need to
bump them.
Alternatively, we could set them to zero, and later assert that the driver fill
them correctly. I'm actually surprised that no driver actually sets them.
Granted, viewport can be bigger than the maximum texture size, but there is no
guarantee is there that old hardware drivers won't get broken next time we need
to bump this to suite a new hardware.
Jose
- Original Message -
> From: Brian Paul
>
> Define new MAX_VIEWPORT_WIDTH/HEIGHT and MAX_RENDERBUFFER_SIZE values
> instead.
> ---
> src/mesa/drivers/dri/i915/intel_decode.c |1 -
> src/mesa/main/config.h | 13 -
> src/mesa/main/context.c |6 +++---
> 3 files changed, 7 insertions(+), 13 deletions(-)
> delete mode 12 src/mesa/drivers/dri/i915/intel_decode.c
>
> diff --git a/src/mesa/drivers/dri/i915/intel_decode.c
> b/src/mesa/drivers/dri/i915/intel_decode.c
> deleted file mode 12
> index f671b6c..000
> --- a/src/mesa/drivers/dri/i915/intel_decode.c
> +++ /dev/null
> @@ -1 +0,0 @@
> -../intel/intel_decode.c
> \ No newline at end of file
> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
> index 6286fe0..c70cc18 100644
> --- a/src/mesa/main/config.h
> +++ b/src/mesa/main/config.h
> @@ -136,15 +136,9 @@
> #define MAX_TEXTURE_UNITS ((MAX_TEXTURE_COORD_UNITS >
> MAX_TEXTURE_IMAGE_UNITS) ? MAX_TEXTURE_COORD_UNITS :
> MAX_TEXTURE_IMAGE_UNITS)
>
>
> -/**
> - * Maximum viewport/image size. Must accomodate all texture sizes
> too.
> - */
> -#ifndef MAX_WIDTH
> -# define MAX_WIDTH 16384
> -#endif
> -#ifndef MAX_HEIGHT
> -# define MAX_HEIGHT 16384
> -#endif
> +/** Maximum viewport size */
> +#define MAX_VIEWPORT_WIDTH 16384
> +#define MAX_VIEWPORT_HEIGHT 16384
>
> /** Maxmimum size for CVA. May be overridden by the drivers. */
> #define MAX_ARRAY_LOCK_SIZE 3000
> @@ -248,6 +242,7 @@
> /** For GL_EXT_framebuffer_object */
> /*@{*/
> #define MAX_COLOR_ATTACHMENTS 8
> +#define MAX_RENDERBUFFER_SIZE 16384
> /*@}*/
>
> /** For GL_ATI_envmap_bump - support bump mapping on first 8 units
> */
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index b9defdb..754d313 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -586,8 +586,8 @@ _mesa_init_constants(struct gl_context *ctx)
> ctx->Const.MaxLights = MAX_LIGHTS;
> ctx->Const.MaxShininess = 128.0;
> ctx->Const.MaxSpotExponent = 128.0;
> - ctx->Const.MaxViewportWidth = MAX_WIDTH;
> - ctx->Const.MaxViewportHeight = MAX_HEIGHT;
> + ctx->Const.MaxViewportWidth = MAX_VIEWPORT_WIDTH;
> + ctx->Const.MaxViewportHeight = MAX_VIEWPORT_HEIGHT;
> #if FEATURE_ARB_vertex_program
> init_program_limits(GL_VERTEX_PROGRAM_ARB,
> &ctx->Const.VertexProgram);
> #endif
> @@ -608,7 +608,7 @@ _mesa_init_constants(struct gl_context *ctx)
>
> #if FEATURE_EXT_framebuffer_object
> ctx->Const.MaxColorAttachments = MAX_COLOR_ATTACHMENTS;
> - ctx->Const.MaxRenderbufferSize = MAX_WIDTH;
> + ctx->Const.MaxRenderbufferSize = MAX_RENDERBUFFER_SIZE;
> #endif
>
> #if FEATURE_ARB_vertex_shader
> --
> 1.7.3.4
>
> ___
> 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 23/23] mesa: move more swrast-related #defines out of core Mesa
BTW, besides the remarks I made, the series looks great. Quite a nice cleanup.
Jose
- Original Message -
> From: Brian Paul
>
> ---
> src/mesa/main/config.h | 40
>
> src/mesa/swrast/s_chan.h |8
> src/mesa/swrast/swrast.h | 20
> 3 files changed, 28 insertions(+), 40 deletions(-)
>
> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
> index c70cc18..8bf741f 100644
> --- a/src/mesa/main/config.h
> +++ b/src/mesa/main/config.h
> @@ -262,46 +262,6 @@
> /*@}*/
>
>
> -/**
> - * \name Mesa-specific parameters
> - */
> -/*@{*/
> -
> -
> -/**
> - * If non-zero use GLdouble for walking triangle edges, for better
> accuracy.
> - */
> -#define TRIANGLE_WALK_DOUBLE 0
> -
> -
> -/**
> - * Bits per depth buffer value (max is 32).
> - */
> -#ifndef DEFAULT_SOFTWARE_DEPTH_BITS
> -#define DEFAULT_SOFTWARE_DEPTH_BITS 16
> -#endif
> -/** Depth buffer data type */
> -#if DEFAULT_SOFTWARE_DEPTH_BITS <= 16
> -#define DEFAULT_SOFTWARE_DEPTH_TYPE GLushort
> -#else
> -#define DEFAULT_SOFTWARE_DEPTH_TYPE GLuint
> -#endif
> -
> -
> -/**
> - * Bits per stencil value: 8
> - */
> -#define STENCIL_BITS 8
> -
> -
> -/**
> - * For swrast, bits per color channel: 8, 16 or 32
> - */
> -#ifndef CHAN_BITS
> -#define CHAN_BITS 8
> -#endif
> -
> -
> /*
> * Color channel component order
> *
> diff --git a/src/mesa/swrast/s_chan.h b/src/mesa/swrast/s_chan.h
> index 94ac8b6..1db7fae 100644
> --- a/src/mesa/swrast/s_chan.h
> +++ b/src/mesa/swrast/s_chan.h
> @@ -36,6 +36,14 @@
>
>
> /**
> + * Default bits per color channel: 8, 16 or 32
> + */
> +#ifndef CHAN_BITS
> +#define CHAN_BITS 8
> +#endif
> +
> +
> +/**
> * Color channel data type.
> */
> #if CHAN_BITS == 8
> diff --git a/src/mesa/swrast/swrast.h b/src/mesa/swrast/swrast.h
> index f6ccf56..f3029d8 100644
> --- a/src/mesa/swrast/swrast.h
> +++ b/src/mesa/swrast/swrast.h
> @@ -37,6 +37,26 @@
>
>
> /**
> + * If non-zero use GLdouble for walking triangle edges, for better
> accuracy.
> + */
> +#define TRIANGLE_WALK_DOUBLE 0
> +
> +
> +/**
> + * Bits per depth buffer value (max is 32).
> + */
> +#ifndef DEFAULT_SOFTWARE_DEPTH_BITS
> +#define DEFAULT_SOFTWARE_DEPTH_BITS 16
> +#endif
> +/** Depth buffer data type */
> +#if DEFAULT_SOFTWARE_DEPTH_BITS <= 16
> +#define DEFAULT_SOFTWARE_DEPTH_TYPE GLushort
> +#else
> +#define DEFAULT_SOFTWARE_DEPTH_TYPE GLuint
> +#endif
> +
> +
> +/**
> * Max image/surface/texture size.
> */
> #define SWRAST_MAX_WIDTH 16384
> --
> 1.7.3.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] vl: rework winsys interface
Throw out all the old and now unneeded stuff.
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/decode.c |2 +-
src/gallium/state_trackers/vdpau/device.c | 10 +-
src/gallium/state_trackers/vdpau/mixer.c |8 +-
src/gallium/state_trackers/vdpau/output.c |6 +-
src/gallium/state_trackers/vdpau/presentation.c| 41 ---
src/gallium/state_trackers/vdpau/surface.c |4 +-
src/gallium/state_trackers/vdpau/vdpau_private.h |2 +-
src/gallium/state_trackers/xorg/xvmc/context.c | 28 ++---
src/gallium/state_trackers/xorg/xvmc/subpicture.c |8 +-
src/gallium/state_trackers/xorg/xvmc/surface.c | 24 ++--
.../state_trackers/xorg/xvmc/xvmc_private.h|5 +-
src/gallium/winsys/g3dvl/dri/dri_winsys.c | 137 ++--
src/gallium/winsys/g3dvl/vl_winsys.h | 17 +--
src/gallium/winsys/g3dvl/xlib/xsp_winsys.c | 85 ++--
14 files changed, 126 insertions(+), 251 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/decode.c
b/src/gallium/state_trackers/vdpau/decode.c
index c45abb8..64349a8 100644
--- a/src/gallium/state_trackers/vdpau/decode.c
+++ b/src/gallium/state_trackers/vdpau/decode.c
@@ -65,7 +65,7 @@ vlVdpDecoderCreate(VdpDevice device,
if (!dev)
return VDP_STATUS_INVALID_HANDLE;
- pipe = dev->context->pipe;
+ pipe = dev->context;
screen = dev->vscreen->pscreen;
supported = screen->get_video_param
(
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index 7b23863..f4a3dc0 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -41,8 +41,9 @@ PUBLIC VdpStatus
vdp_imp_device_create_x11(Display *display, int screen, VdpDevice *device,
VdpGetProcAddress **get_proc_address)
{
- VdpStatus ret;
+ struct pipe_screen *pscreen;
vlVdpDevice *dev = NULL;
+ VdpStatus ret;
if (!(display && device && get_proc_address))
return VDP_STATUS_INVALID_POINTER;
@@ -64,7 +65,8 @@ vdp_imp_device_create_x11(Display *display, int screen,
VdpDevice *device,
goto no_vscreen;
}
- dev->context = vl_video_create(dev->vscreen);
+ pscreen = dev->vscreen->pscreen;
+ dev->context = pscreen->context_create(pscreen, dev->vscreen);
if (!dev->context) {
ret = VDP_STATUS_RESOURCES;
goto no_context;
@@ -76,7 +78,7 @@ vdp_imp_device_create_x11(Display *display, int screen,
VdpDevice *device,
goto no_handle;
}
- vl_compositor_init(&dev->compositor, dev->context->pipe);
+ vl_compositor_init(&dev->compositor, dev->context);
*get_proc_address = &vlVdpGetProcAddress;
@@ -160,7 +162,7 @@ vlVdpDeviceDestroy(VdpDevice device)
return VDP_STATUS_INVALID_HANDLE;
vl_compositor_cleanup(&dev->compositor);
- vl_video_destroy(dev->context);
+ dev->context->destroy(dev->context);
vl_screen_destroy(dev->vscreen);
FREE(dev);
diff --git a/src/gallium/state_trackers/vdpau/mixer.c
b/src/gallium/state_trackers/vdpau/mixer.c
index df6750d..0828608 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -62,7 +62,7 @@ vlVdpVideoMixerCreate(VdpDevice device,
return VDP_STATUS_RESOURCES;
vmixer->device = dev;
- vl_compositor_init(&vmixer->compositor, dev->context->pipe);
+ vl_compositor_init(&vmixer->compositor, dev->context);
vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_BT_601, NULL, true, vmixer->csc);
if (!debug_get_bool_option("G3DVL_NO_CSC", FALSE))
@@ -300,8 +300,7 @@ vlVdpVideoMixerUpdateNoiseReductionFilter(vlVdpVideoMixer
*vmixer)
/* and create a new filter as needed */
if (vmixer->noise_reduction. enabled && vmixer->noise_reduction.level > 0) {
vmixer->noise_reduction.filter = MALLOC(sizeof(struct vl_median_filter));
- vl_median_filter_init(vmixer->noise_reduction.filter,
-vmixer->device->context->pipe,
+ vl_median_filter_init(vmixer->noise_reduction.filter,
vmixer->device->context,
vmixer->video_width, vmixer->video_height,
vmixer->noise_reduction.level + 1,
VL_MEDIAN_FILTER_CROSS);
@@ -347,8 +346,7 @@ vlVdpVideoMixerUpdateSharpnessFilter(vlVdpVideoMixer
*vmixer)
}
vmixer->sharpness.filter = MALLOC(sizeof(struct vl_matrix_filter));
- vl_matrix_filter_init(vmixer->sharpness.filter,
-vmixer->device->context->pipe,
+ vl_matrix_filter_init(vmixer->sharpness.filter, vmixer->device->context,
vmixer->video_width, vmixer->video_height,
3, 3, matrix);
}
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index 17ce037..5ccb153 100644
--- a/src/gallium/state_trac
[Mesa-dev] [Bug 45292] Compilation failure on d3d1x state tracker: ‘ID3D10Include’ has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=45292
--- Comment #5 from Sven Eden 2012-02-21 03:42:29 PST ---
Created attachment 57383
--> https://bugs.freedesktop.org/attachment.cgi?id=57383
Re-insert neccessary typedef for ID3D10Include
Hi!
I have been able to get past this error with the attached patch.
System: Gentoo x64, kernel 3.2.5, wine 1.3.37
But it does not mean it works, I run into the next error.
Build snippet:
---
In file included from ../w32api/windows.h:66:0,
from ../w32api/rpc.h:29,
from ../d3dapi/d3d11shader.h:7,
from src/dxbc_parse.cpp:29:
../w32api/winsock.h:447:16: error: redefinition of 'struct timeval'
/usr/include/bits/time.h:31:8: error: previous definition of 'struct timeval'
../w32api/winsock.h:451:10: error: invalid type in declaration before ',' token
---
As "w32api" is just a link to /usr/include/wine/windows, it is a wine thing.
But: When timeval is defined from /usr/include/bits/time.h, the macro
"_STRUCT_TIMEVAL" is defined. Unfortunately I can't seem to find a point where
to patch any idl file to check that.
There are two possibilities.
A) windows.h does not include winsock.h if WINE_NOWINSOCK is defined
65 #ifndef WINE_NOWINSOCK
66 #include
67 #endif /* WINE_NOWINSOCK */
B) define _TIMEVAL_DEFINED if _STRUCT_TIMEVAL is defined, because winsock.h
checks that:
#ifndef _TIMEVAL_DEFINED
#define _TIMEVAL_DEFINED
typedef struct WS(timeval)
{
LONGtv_sec;/* seconds */
LONGtv_usec; /* and microseconds */
} TIMEVAL, *PTIMEVAL, *LPTIMEVAL;
#endif
-
I'd prefer the latter, but I have no idea where to put that, yet.
--
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 45292] Compilation failure on d3d1x state tracker: ‘ID3D10Include’ has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=45292 Sven Eden changed: What|Removed |Added CC||yamakuz...@gmx.net -- 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 03/23] swrast: remove MAX_WIDTH arrays in s_zoom.c
On 02/21/2012 01:30 AM, Jose Fonseca wrote: Shouldn't malloc be passed zoomedWidth instead of width? Oops, yes. I'll fix that patch. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 20/23] mesa: remove last of MAX_WIDTH, MAX_HEIGHT
On 02/21/2012 02:22 AM, Jose Fonseca wrote: Your series is a huge step forward already. But I wonder if we could go just a bit further and not add MAX_VIEWPORT_WIDTH/HEIGHT and MAX_RENDERBUFFER_SIZE defines. Would it be possible to derive these limits from the maximum texture size? Either the driver reported max texture size, or just define them in terms of MAX_TEXTURE_LEVELS so that there are less places to change next time we need to bump them. Alternatively, we could set them to zero, and later assert that the driver fill them correctly. I'm actually surprised that no driver actually sets them. Granted, viewport can be bigger than the maximum texture size, but there is no guarantee is there that old hardware drivers won't get broken next time we need to bump this to suite a new hardware. I considered defining the max viewport size and renderbuffer size in terms of the max texture size but I wan't sure if that's typically true for most hardware. As you said, the max viewport size could be larger than max texture/surface size, for example. I guess I'd like to just leave it as-is for now so I can wrap up this series. It'd be easy to change later. I noticed that the gallium state tracker isn't setting the max viewport or renderbuffer size values in st_extensions.c. We could set those to the max texture size for the time being... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 20/23] mesa: remove last of MAX_WIDTH, MAX_HEIGHT
- Original Message - > On 02/21/2012 02:22 AM, Jose Fonseca wrote: > > Your series is a huge step forward already. But I wonder if we > > could go just a bit further and not add MAX_VIEWPORT_WIDTH/HEIGHT > > and MAX_RENDERBUFFER_SIZE defines. > > > > Would it be possible to derive these limits from the maximum > > texture size? Either the driver reported max texture size, or just > > define them in terms of MAX_TEXTURE_LEVELS so that there are less > > places to change next time we need to bump them. > > > > Alternatively, we could set them to zero, and later assert that the > > driver fill them correctly. I'm actually surprised that no driver > > actually sets them. Granted, viewport can be bigger than the > > maximum texture size, but there is no guarantee is there that old > > hardware drivers won't get broken next time we need to bump this > > to suite a new hardware. > > I considered defining the max viewport size and renderbuffer size in > terms of the max texture size but I wan't sure if that's typically > true for most hardware. As you said, the max viewport size could be > larger than max texture/surface size, for example. > > I guess I'd like to just leave it as-is for now so I can wrap up this > series. It'd be easy to change later. Sure. > I noticed that the gallium state tracker isn't setting the max > viewport or renderbuffer size values in st_extensions.c. We could > set > those to the max texture size for the time being... Sounds good. FWIW, wglinfo on nvidia reports that maximum viewport and texture size match. And I'd expect that maximum renderbuffer and texture sizes to match too. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i915: fallback to swrast when gl_PointSize met
This patch(the way to fix this issue) is a little weird, as we already
fallbacked to swrast when handling gl_PointSize(in vertex shader).
Sounds that we didn't fallback enough;) This patch servers as fixing the
gl_PointSize issue on Pineview platform.
Since the patch is a little weird, I thought a while for another fix:
get the point size at intelRenderStart() (or somewhere else before
vtbl.emit_state()) by reading the vertex program output. This is so
tricky that I droped this fix.
Any better thoughts(or even fixes) are welcome and appreciate.
This patch would fix piglit glsl-vs-point-size on Pineview.
Signed-off-by: Yuanhan Liu
---
src/mesa/drivers/dri/i915/i915_context.h |1 +
src/mesa/drivers/dri/i915/i915_fragprog.c |9 +
src/mesa/drivers/dri/i915/intel_tris.c|1 +
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_context.h
b/src/mesa/drivers/dri/i915/i915_context.h
index 8167137..400e3a4 100644
--- a/src/mesa/drivers/dri/i915/i915_context.h
+++ b/src/mesa/drivers/dri/i915/i915_context.h
@@ -40,6 +40,7 @@
#define I915_FALLBACK_POINT_SMOOTH 0x8
#define I915_FALLBACK_POINT_SPRITE_COORD_ORIGIN 0x10
#define I915_FALLBACK_DRAW_OFFSET 0x20
+#define I915_FALLBACK_VERTEX_PROGRAM_POINT_SIZE 0x40
#define I915_UPLOAD_CTX 0x1
#define I915_UPLOAD_BUFFERS 0x2
diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index 4f016a3..0e3cda1 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -1324,6 +1324,15 @@ i915_update_program(struct gl_context *ctx)
translate_program(fp);
FALLBACK(&i915->intel, I915_FALLBACK_PROGRAM, fp->error);
+
+ /*
+* fallback to swrast for handling gl_PointSize builtin variable.
+*
+* FIXME: it's a little weird that put the handling of vertex program
+* relative stuff here.
+*/
+ FALLBACK(intel, I915_FALLBACK_VERTEX_PROGRAM_POINT_SIZE,
+ctx->VertexProgram.PointSizeEnabled);
}
void
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c
b/src/mesa/drivers/dri/i915/intel_tris.c
index a36011a..922f6ce 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -1198,6 +1198,7 @@ static char *fallbackStrings[] = {
[19] = "Smooth point",
[20] = "point sprite coord origin",
[21] = "depth/color drawing offset",
+ [22] = "gl_PointSize",
};
--
1.7.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i915: fallback to swrast when gl_PointSize met
This patch(the way to fix this issue) is a little weird, as we already
fallbacked to swrast when handling gl_PointSize(in vertex shader).
Sounds that we didn't fallback enough;) This patch servers as fixing the
gl_PointSize issue on Pineview platform.
Since the patch is a little weird, I thought a while for another fix:
get the point size at intelRenderStart() (or somewhere else before
vtbl.emit_state()) by reading the vertex program output. This is so
tricky that I droped this fix.
Any better thoughts(or even fixes) are welcome and appreciate.
This patch would fix piglit glsl-vs-point-size on Pineview(when the GL
version 2.0 requirement is removed).
Signed-off-by: Yuanhan Liu
---
src/mesa/drivers/dri/i915/i915_context.h |1 +
src/mesa/drivers/dri/i915/i915_fragprog.c |9 +
src/mesa/drivers/dri/i915/intel_tris.c|1 +
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_context.h
b/src/mesa/drivers/dri/i915/i915_context.h
index 8167137..400e3a4 100644
--- a/src/mesa/drivers/dri/i915/i915_context.h
+++ b/src/mesa/drivers/dri/i915/i915_context.h
@@ -40,6 +40,7 @@
#define I915_FALLBACK_POINT_SMOOTH 0x8
#define I915_FALLBACK_POINT_SPRITE_COORD_ORIGIN 0x10
#define I915_FALLBACK_DRAW_OFFSET 0x20
+#define I915_FALLBACK_VERTEX_PROGRAM_POINT_SIZE 0x40
#define I915_UPLOAD_CTX 0x1
#define I915_UPLOAD_BUFFERS 0x2
diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index 4f016a3..0e3cda1 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -1324,6 +1324,15 @@ i915_update_program(struct gl_context *ctx)
translate_program(fp);
FALLBACK(&i915->intel, I915_FALLBACK_PROGRAM, fp->error);
+
+ /*
+* fallback to swrast for handling gl_PointSize builtin variable.
+*
+* FIXME: it's a little weird that put the handling of vertex program
+* relative stuff here.
+*/
+ FALLBACK(intel, I915_FALLBACK_VERTEX_PROGRAM_POINT_SIZE,
+ctx->VertexProgram.PointSizeEnabled);
}
void
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c
b/src/mesa/drivers/dri/i915/intel_tris.c
index a36011a..922f6ce 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -1198,6 +1198,7 @@ static char *fallbackStrings[] = {
[19] = "Smooth point",
[20] = "point sprite coord origin",
[21] = "depth/color drawing offset",
+ [22] = "gl_PointSize",
};
--
1.7.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i915: fallback to swrast when gl_PointSize met
Sorry that I send the patch twice, the network connection here was
terrifying bad just now.
On 2/21/12, Liu Aleaxander wrote:
> This patch(the way to fix this issue) is a little weird, as we already
> fallbacked to swrast when handling gl_PointSize(in vertex shader).
> Sounds that we didn't fallback enough;) This patch servers as fixing the
> gl_PointSize issue on Pineview platform.
>
> Since the patch is a little weird, I thought a while for another fix:
> get the point size at intelRenderStart() (or somewhere else before
> vtbl.emit_state()) by reading the vertex program output. This is so
> tricky that I droped this fix.
>
> Any better thoughts(or even fixes) are welcome and appreciate.
>
> This patch would fix piglit glsl-vs-point-size on Pineview(when the GL
> version 2.0 requirement is removed).
>
> Signed-off-by: Yuanhan Liu
> ---
> src/mesa/drivers/dri/i915/i915_context.h |1 +
> src/mesa/drivers/dri/i915/i915_fragprog.c |9 +
> src/mesa/drivers/dri/i915/intel_tris.c|1 +
> 3 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i915/i915_context.h
> b/src/mesa/drivers/dri/i915/i915_context.h
> index 8167137..400e3a4 100644
> --- a/src/mesa/drivers/dri/i915/i915_context.h
> +++ b/src/mesa/drivers/dri/i915/i915_context.h
> @@ -40,6 +40,7 @@
> #define I915_FALLBACK_POINT_SMOOTH0x8
> #define I915_FALLBACK_POINT_SPRITE_COORD_ORIGIN 0x10
> #define I915_FALLBACK_DRAW_OFFSET 0x20
> +#define I915_FALLBACK_VERTEX_PROGRAM_POINT_SIZE 0x40
>
> #define I915_UPLOAD_CTX 0x1
> #define I915_UPLOAD_BUFFERS 0x2
> diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c
> b/src/mesa/drivers/dri/i915/i915_fragprog.c
> index 4f016a3..0e3cda1 100644
> --- a/src/mesa/drivers/dri/i915/i915_fragprog.c
> +++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
> @@ -1324,6 +1324,15 @@ i915_update_program(struct gl_context *ctx)
>translate_program(fp);
>
> FALLBACK(&i915->intel, I915_FALLBACK_PROGRAM, fp->error);
> +
> + /*
> +* fallback to swrast for handling gl_PointSize builtin variable.
> +*
> +* FIXME: it's a little weird that put the handling of vertex program
> +* relative stuff here.
> +*/
> + FALLBACK(intel, I915_FALLBACK_VERTEX_PROGRAM_POINT_SIZE,
> +ctx->VertexProgram.PointSizeEnabled);
> }
>
> void
> diff --git a/src/mesa/drivers/dri/i915/intel_tris.c
> b/src/mesa/drivers/dri/i915/intel_tris.c
> index a36011a..922f6ce 100644
> --- a/src/mesa/drivers/dri/i915/intel_tris.c
> +++ b/src/mesa/drivers/dri/i915/intel_tris.c
> @@ -1198,6 +1198,7 @@ static char *fallbackStrings[] = {
> [19] = "Smooth point",
> [20] = "point sprite coord origin",
> [21] = "depth/color drawing offset",
> + [22] = "gl_PointSize",
> };
>
>
> --
> 1.7.3.1
>
--
regards
Liu Aleaxander
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 20/23] mesa: remove last of MAX_WIDTH, MAX_HEIGHT
Am 21.02.2012 16:08, schrieb Jose Fonseca: > - Original Message - >> On 02/21/2012 02:22 AM, Jose Fonseca wrote: >>> Your series is a huge step forward already. But I wonder if we >>> could go just a bit further and not add >>> MAX_VIEWPORT_WIDTH/HEIGHT and MAX_RENDERBUFFER_SIZE defines. >>> >>> Would it be possible to derive these limits from the maximum >>> texture size? Either the driver reported max texture size, or >>> just define them in terms of MAX_TEXTURE_LEVELS so that there are >>> less places to change next time we need to bump them. >>> >>> Alternatively, we could set them to zero, and later assert that >>> the driver fill them correctly. I'm actually surprised that no >>> driver actually sets them. Granted, viewport can be bigger than >>> the maximum texture size, but there is no guarantee is there that >>> old hardware drivers won't get broken next time we need to bump >>> this to suite a new hardware. >> >> I considered defining the max viewport size and renderbuffer size >> in terms of the max texture size but I wan't sure if that's >> typically true for most hardware. As you said, the max viewport >> size could be larger than max texture/surface size, for example. >> >> I guess I'd like to just leave it as-is for now so I can wrap up >> this series. It'd be easy to change later. > > Sure. > >> I noticed that the gallium state tracker isn't setting the max >> viewport or renderbuffer size values in st_extensions.c. We could >> set those to the max texture size for the time being... > > Sounds good. FWIW, wglinfo on nvidia reports that maximum viewport > and texture size match. And I'd expect that maximum renderbuffer and > texture sizes to match too. There were r300 radeons which had a max viewport size of 2560 and max texture size of 2048 (or maybe 4096 can't remember). I would definitely expect these values to be the same for newer hardware though. Not sure why the driver didn't set it. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Only set Last Render Target Select on the last FB write.
Fixes GPU hangs in OilRush, which does depth buffer clears with MRT. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_eu_emit.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c b/src/mesa/drivers/dri/i965/brw_eu_emit.c index 839f6c3..179b59a 100644 --- a/src/mesa/drivers/dri/i965/brw_eu_emit.c +++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c @@ -2270,7 +2270,7 @@ void brw_fb_WRITE(struct brw_compile *p, msg_type, msg_length, header_present, - 1, /* last render target write */ + eot, /* last render target write */ response_length, eot, 0 /* send_commit_msg */); -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Only set Last Render Target Select on the last FB write.
On Tue, 21 Feb 2012 10:39:11 -0800, Kenneth Graunke wrote: > Fixes GPU hangs in OilRush, which does depth buffer clears with MRT. Reviewed-by: Eric Anholt pgpmDr7oriDD7.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 2/2] i965: Move VUE map computation to once at VS compile time.
On 02/14/2012 08:46 PM, Eric Anholt wrote:
With this and the previous patch, 640x480 nexuiz is running 0.169118%
+/- 0.0863696% faster (n=121). On a VS state change microbenchmark,
performance is increased 8.28645% +/- 0.460478% (n=52).
---
To those who saw me throwing my hands in the air saying "why does this
patch not show up in the microbenchmark!?" today, it turns out I was
smashing the environment in the test run so I was testing the old mesa
for both configurations.
src/mesa/drivers/dri/i965/brw_clip.c |2 +-
src/mesa/drivers/dri/i965/brw_context.h|5 ++---
src/mesa/drivers/dri/i965/brw_gs.c |2 +-
src/mesa/drivers/dri/i965/brw_sf.c |2 +-
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp|2 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 12 +---
src/mesa/drivers/dri/i965/brw_vs.c | 16 +---
src/mesa/drivers/dri/i965/brw_vs.h |1 -
src/mesa/drivers/dri/i965/brw_vs_emit.c| 20 +---
src/mesa/drivers/dri/i965/gen6_sf_state.c | 10 +-
src/mesa/drivers/dri/i965/gen7_sf_state.c | 10 +-
src/mesa/drivers/dri/i965/gen7_sol_state.c |9 +++--
12 files changed, 42 insertions(+), 49 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index 5b5f551..d411208 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -69,7 +69,7 @@ static void compile_clip_prog( struct brw_context *brw,
c.func.single_program_flow = 1;
c.key = *key;
- brw_compute_vue_map(&c.vue_map, intel, brw->vs.prog_data);
+ c.vue_map = brw->vs.prog_data->vue_map;
/* nr_regs is the number of registers filled by reading data from the VUE.
* This program accesses the entire VUE, so nr_regs needs to be the size of
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index c6860a7..503585c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -381,6 +381,8 @@ struct brw_gs_prog_data {
};
struct brw_vs_prog_data {
+ struct brw_vue_map vue_map;
+
GLuint curb_read_length;
GLuint urb_read_length;
GLuint total_grf;
@@ -1045,9 +1047,6 @@ void brw_upload_cs_urb_state(struct brw_context *brw);
int brw_disasm (FILE *file, struct brw_instruction *inst, int gen);
/* brw_vs.c */
-void brw_compute_vue_map(struct brw_vue_map *vue_map,
- const struct intel_context *intel,
- const struct brw_vs_prog_data *prog_data);
gl_clip_plane *brw_select_clip_planes(struct gl_context *ctx);
/* brw_wm.c */
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
b/src/mesa/drivers/dri/i965/brw_gs.c
index c6132df..bfca169 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -56,7 +56,7 @@ static void compile_gs_prog( struct brw_context *brw,
memset(&c, 0, sizeof(c));
c.key = *key;
- brw_compute_vue_map(&c.vue_map, intel, brw->vs.prog_data);
+ c.vue_map = brw->vs.prog_data->vue_map;
c.nr_regs = (c.vue_map.num_slots + 1)/2;
mem_ctx = NULL;
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
b/src/mesa/drivers/dri/i965/brw_sf.c
index 6c28d77..6e63583 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -63,7 +63,7 @@ static void compile_sf_prog( struct brw_context *brw,
brw_init_compile(brw,&c.func, mem_ctx);
c.key = *key;
- brw_compute_vue_map(&c.vue_map, intel, brw->vs.prog_data);
+ c.vue_map = brw->vs.prog_data->vue_map;
c.urb_entry_read_offset = brw_sf_compute_urb_entry_read_offset(intel);
c.nr_attr_regs = (c.vue_map.num_slots + 1)/2 - c.urb_entry_read_offset;
c.nr_setup_regs = c.nr_attr_regs;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
index 917c927..f9eed61 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
@@ -96,7 +96,7 @@ vec4_visitor::setup_attributes(int payload_reg)
prog_data->urb_read_length = (nr_attributes + 1) / 2;
- unsigned vue_entries = MAX2(nr_attributes, c->vue_map.num_slots);
+ unsigned vue_entries = MAX2(nr_attributes, c->prog_data.vue_map.num_slots);
if (intel->gen == 6)
c->prog_data.urb_entry_size = ALIGN(vue_entries, 8) / 8;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 5dfe1c1..f9a08a0 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2252,8 +2252,6 @@ vec4_visitor::emit_urb_writes()
/* FINISHME: edgeflag */
- brw_compute_vue_map(&c->vue_map, intel,&c->prog_data);
-
/* First mrf is the g0-based message header containing URB handles and
such,
* which is implied
Re: [Mesa-dev] [PATCH 1/2] i965: Make the userclip flag for the VUE map come from VS prog data.
On 02/14/2012 08:46 PM, Eric Anholt wrote: This reduces recomputation of state based on non-clipping-related transform changes, and is a step toward removing VUE map recomputation. This looks fantastic. There's really no point in doing all this computation over and over. Compile time makes far more sense. For all 8 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 2/2] i965: handle gl_PointCoord for Gen4 and Gen5 platform
On Sun, 19 Feb 2012 13:31:33 +0800, Liu Aleaxander wrote: > On Sun, Feb 19, 2012 at 8:54 AM, Eric Anholt wrote: > > On Sat, 18 Feb 2012 23:07:32 +0800, Liu Aleaxander > > wrote: > >> + /* > >> + * gl_PointCoord is a FS instead of VS builtin variable, thus is not > >> + * included in c->nr_setup_regs. But FS need SF do the interpolation, > >> + * so that here padding the interpolation for gl_PointCoord in last. > >> + */ > >> + if (c->key.do_point_coord) > >> + c->nr_setup_regs++; > > > > So you're writing an extra attribute of setup, but you haven't increased > > the size of the URB entry. If the URB full except for pointcoord, you'd > > end up writing over the next URB entry and probably hanging the GPU. If > > you correctly allocate the URB size and that gets reflected in > > urb_read_length, you should be able to read your new attribute. > > That's maybe the place I don't understand quite well so far. Say, you > write attributes into URB from SF thread to FS. I did increase the > urb_read_length in wm_state. Is that the allocation you mean? Should > I, say, allocate size for extra attributes just for FS in SF stage? If > so, would you please tell me how? Since if I understand correctly, the > urb_read_length in SF_STATE is counted from the attributes from VF > stage. Thus at least urb_read_length in SF stage is not the right > place for me to touch, right? urb_entry_size in the SF is the size of what the SF outputs and is what determines how much space is allocated by brw_urb.c pgpWdNMPE6Jeq.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 40059] [SNB] hang in "Amnesia: The Dark Descent" demo
https://bugs.freedesktop.org/show_bug.cgi?id=40059 Kenneth Graunke changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|i...@freedesktop.org |kenn...@whitecape.org CC||i...@freedesktop.org --- Comment #4 from Kenneth Graunke 2012-02-21 12:16:37 PST --- This is fixed by the last render target select patch on the mailing list. Will commit it shortly... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list 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/3] st/mesa: do vertex and fragment color clamping in shaders
Tilman Sauerbeck [2012-02-12 11:31]:
> Marek Olšák [2012-01-23 13:32]:
> > For ARB_color_buffer_float. Most hardware can't do it and st/mesa is
> > the perfect place for a fallback.
>
> This breaks lighting in Heroes of Newerth on my rv730:
> http://files.code-monkey.de/frag_color_clamp_bad.png (after patch)
> http://files.code-monkey.de/frag_color_clamp_good.png (before patch)
> I can provide a trace file that shows the problem (3.5GB, so will take
> a while to upload).
The problematic fragment shader looks like this:
void main() {
gl_FragColor = vec4(0.0);
gl_FragColor += texture2D(...);
gl_FragColor += texture2D(...);
gl_FragColor += texture2D(...);
gl_FragColor += texture2D(...);
gl_FragColor *= 0.25;
gl_FragColor *= v_vColor; // varying vec4
}
Before this patch landed, mesa would generate the following TGSI for
that shader:
0: MOV TEMP[0].x, -CONST[1].
1: MOV TEMP[0].y, -CONST[1].
2: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
3: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
4: MOV OUT[0], TEMP[0]
5: MOV TEMP[0].x, -CONST[1].
6: MOV TEMP[0].y, CONST[1].
7: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
8: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
9: ADD OUT[0], OUT[0], TEMP[0]
10: ADD TEMP[0].xy, IN[0].xyyy, CONST[1].
11: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
12: ADD OUT[0], OUT[0], TEMP[0]
13: MOV TEMP[0].x, CONST[1].
14: MOV TEMP[0].y, -CONST[1].
15: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
16: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
17: ADD TEMP[0], OUT[0], TEMP[0]
18: MUL TEMP[0], TEMP[0], IMM[0].
19: MUL OUT[0], TEMP[0], IN[1]
20: END
With this patch, instructions 4, 9, 12 and 19 are replaced by their
_SAT variants.
If I hack the code to only use saturate in the final instruction
(MUL -> MUL_SAT), the game looks okay.
I'm wondering whether the current behaviour is correct in that it uses
saturate ops for the intermediate results as well.
Issue 24 of the ARB_color_buffer_float says:
> 24. Does this extension interact with the ARB_fragment_program or
> ARB_fragment_shader extensions?
>
> RESOLVED: Yes. The only interaction is that the fragment color
> clamp enable determines if the final color(s) produced by the
> fragment program/shader has its components clamped to [0,1].
>
> However, the fragment color clamp enable affects only the final
> result; it does NOT affect any computations performed during
> program execution. Note that the same clamping can be done
> explicitly in a fragment program or shader.
> ARB_fragment_program provides the "_SAT" opcode suffix to clamp
> instruction results to [0,1].
If I'm understanding this language correctly, _and_ it applies to GLSL
too then it seems like Mesa should only use saturation in the final
operation that's writing to gl_FragColor, but not in the earlier ones?
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
pgphG609UQsQT.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 1/3] st/mesa: do vertex and fragment color clamping in shaders
Hi Tilman,
Thanks for the info. I didn't consider outputs to be readable, sorry.
A quick fix would be to move the outputs to temps. There is a GLSL pass
for that and it can be enabled by reporting
PIPE_SHADER_CAP_OUTPUT_READ --> 0 in r600_pipe.c. Can you try that and
see if it helps?
To Vadim: Now that we have a GLSL pass for lowering output reads, are
you okay with removing PIPE_SHADER_CAP_OUTPUT_READ? It makes the
fallback for glClampColorARB really non-trivial.
Marek
On Tue, Feb 21, 2012 at 9:17 PM, Tilman Sauerbeck wrote:
> Tilman Sauerbeck [2012-02-12 11:31]:
>> Marek Olšák [2012-01-23 13:32]:
>> > For ARB_color_buffer_float. Most hardware can't do it and st/mesa is
>> > the perfect place for a fallback.
>>
>> This breaks lighting in Heroes of Newerth on my rv730:
>> http://files.code-monkey.de/frag_color_clamp_bad.png (after patch)
>> http://files.code-monkey.de/frag_color_clamp_good.png (before patch)
>> I can provide a trace file that shows the problem (3.5GB, so will take
>> a while to upload).
>
> The problematic fragment shader looks like this:
>
> void main() {
> gl_FragColor = vec4(0.0);
> gl_FragColor += texture2D(...);
> gl_FragColor += texture2D(...);
> gl_FragColor += texture2D(...);
> gl_FragColor += texture2D(...);
> gl_FragColor *= 0.25;
> gl_FragColor *= v_vColor; // varying vec4
> }
>
> Before this patch landed, mesa would generate the following TGSI for
> that shader:
>
> 0: MOV TEMP[0].x, -CONST[1].
> 1: MOV TEMP[0].y, -CONST[1].
> 2: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
> 3: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> 4: MOV OUT[0], TEMP[0]
> 5: MOV TEMP[0].x, -CONST[1].
> 6: MOV TEMP[0].y, CONST[1].
> 7: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
> 8: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> 9: ADD OUT[0], OUT[0], TEMP[0]
> 10: ADD TEMP[0].xy, IN[0].xyyy, CONST[1].
> 11: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> 12: ADD OUT[0], OUT[0], TEMP[0]
> 13: MOV TEMP[0].x, CONST[1].
> 14: MOV TEMP[0].y, -CONST[1].
> 15: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
> 16: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> 17: ADD TEMP[0], OUT[0], TEMP[0]
> 18: MUL TEMP[0], TEMP[0], IMM[0].
> 19: MUL OUT[0], TEMP[0], IN[1]
> 20: END
>
> With this patch, instructions 4, 9, 12 and 19 are replaced by their
> _SAT variants.
>
> If I hack the code to only use saturate in the final instruction
> (MUL -> MUL_SAT), the game looks okay.
>
> I'm wondering whether the current behaviour is correct in that it uses
> saturate ops for the intermediate results as well.
>
> Issue 24 of the ARB_color_buffer_float says:
>
>> 24. Does this extension interact with the ARB_fragment_program or
>> ARB_fragment_shader extensions?
>>
>> RESOLVED: Yes. The only interaction is that the fragment color
>> clamp enable determines if the final color(s) produced by the
>> fragment program/shader has its components clamped to [0,1].
>>
>> However, the fragment color clamp enable affects only the final
>> result; it does NOT affect any computations performed during
>> program execution. Note that the same clamping can be done
>> explicitly in a fragment program or shader.
>> ARB_fragment_program provides the "_SAT" opcode suffix to clamp
>> instruction results to [0,1].
>
> If I'm understanding this language correctly, _and_ it applies to GLSL
> too then it seems like Mesa should only use saturation in the final
> operation that's writing to gl_FragColor, but not in the earlier ones?
>
> Regards,
> Tilman
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 40059] [SNB] hang in "Amnesia: The Dark Descent" demo
https://bugs.freedesktop.org/show_bug.cgi?id=40059 Kenneth Graunke changed: What|Removed |Added Version|git |8.0 --- Comment #5 from Kenneth Graunke 2012-02-21 12:40:40 PST --- Fixed on master by: commit 172bb92db1a3c317867d9cfec6f15c09c37a0f6c Author: Kenneth Graunke Date: Sat Feb 18 21:29:29 2012 -0800 i965: Only set Last Render Target Select on the last FB write. Fixes GPU hangs in OilRush, Trine, and Amnesia: The Dark Descent, which all use MRT (multiple render targets). NOTE: This is a candidate for release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38720 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40059 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45216 Reviewed-by: Eric Anholt Signed-off-by: Kenneth Graunke Thanks for the trimmed apitrace! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gbm: track buffer format through DRI drivers
GBM needs the buffer format in order to communicate with DRM and clients
for things like scanout.
So track the DRI format requested in the various back ends and use it to
return the DRI format back to GBM when requested. GBM will then map
this into the GBM surface type (which is in turn based on the DRM fb
format list).
Signed-off-by: Jesse Barnes
---
include/GL/internal/dri_interface.h |3 +-
src/gallium/state_trackers/dri/drm/dri2.c |6 +
src/gallium/winsys/sw/wayland/wayland_sw_winsys.h |1 +
src/gbm/backends/dri/gbm_dri.c| 45 -
src/gbm/main/gbm.c| 13 +++
src/gbm/main/gbm.h| 110 -
src/gbm/main/gbmint.h |1 +
src/mesa/drivers/dri/intel/intel_regions.h|1 +
src/mesa/drivers/dri/intel/intel_screen.c |4 +
src/mesa/drivers/dri/radeon/radeon_screen.c |2 +
src/mesa/drivers/dri/radeon/radeon_screen.h |1 +
11 files changed, 181 insertions(+), 6 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 701e83e..da83666 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -894,7 +894,7 @@ struct __DRIdri2ExtensionRec {
* extensions.
*/
#define __DRI_IMAGE "DRI_IMAGE"
-#define __DRI_IMAGE_VERSION 2
+#define __DRI_IMAGE_VERSION 3
/**
* These formats correspond to the similarly named MESA_FORMAT_*
@@ -918,6 +918,7 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_ATTRIB_STRIDE 0x2000
#define __DRI_IMAGE_ATTRIB_HANDLE 0x2001
#define __DRI_IMAGE_ATTRIB_NAME0x2002
+#define __DRI_IMAGE_ATTRIB_FORMAT 0x2003 /* available in versions 3+ */
typedef struct __DRIimageRec __DRIimage;
typedef struct __DRIimageExtensionRec __DRIimageExtension;
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index 4c08a02..32cb077 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -477,6 +477,7 @@ dri2_create_image_from_name(__DRIscreen *_screen,
memset(&whandle, 0, sizeof(whandle));
whandle.handle = name;
whandle.stride = pitch * util_format_get_blocksize(pf);
+ whandle.dri_format = format;
img->texture =
screen->base.screen->resource_from_handle(screen->base.screen,
&templ, &whandle);
@@ -527,6 +528,8 @@ dri2_create_image(__DRIscreen *_screen,
tex_usage |= PIPE_BIND_CURSOR;
}
+ img->dri_format = format;
+
switch (format) {
case __DRI_IMAGE_FORMAT_RGB565:
pf = PIPE_FORMAT_B5G6R5_UNORM;
@@ -598,6 +601,9 @@ dri2_query_image(__DRIimage *image, int attrib, int *value)
image->texture, &whandle);
*value = whandle.handle;
return GL_TRUE;
+ case __DRI_IMAGE_ATTRIB_FORMAT:
+ *value = image->dri_format;
+ return GL_TRUE;
default:
return GL_FALSE;
}
diff --git a/src/gallium/winsys/sw/wayland/wayland_sw_winsys.h
b/src/gallium/winsys/sw/wayland/wayland_sw_winsys.h
index bedd240..8e6f329 100644
--- a/src/gallium/winsys/sw/wayland/wayland_sw_winsys.h
+++ b/src/gallium/winsys/sw/wayland/wayland_sw_winsys.h
@@ -32,6 +32,7 @@ struct wl_display;
struct winsys_handle {
int fd;
unsigned stride;
+ uint32_t dri_format;
};
struct sw_winsys *
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index ddd153a..34f07de 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -216,13 +216,15 @@ free_screen:
static int
gbm_dri_is_format_supported(struct gbm_device *gbm,
-enum gbm_bo_format format,
+uint32_t format,
uint32_t usage)
{
switch (format) {
case GBM_BO_FORMAT_XRGB:
+ case GBM_FORMAT_XRGB:
break;
case GBM_BO_FORMAT_ARGB:
+ case GBM_FORMAT_ARGB:
if (usage & GBM_BO_USE_SCANOUT)
return 0;
break;
@@ -247,6 +249,32 @@ gbm_dri_bo_destroy(struct gbm_bo *_bo)
free(bo);
}
+static uint32_t
+gbm_dri_to_gbm_format(uint32_t dri_format)
+{
+ uint32_t ret = 0;
+
+ switch (dri_format) {
+ case __DRI_IMAGE_FORMAT_RGB565:
+ ret = GBM_FORMAT_RGB565;
+ break;
+ case __DRI_IMAGE_FORMAT_XRGB:
+ ret = GBM_FORMAT_XRGB;
+ break;
+ case __DRI_IMAGE_FORMAT_ARGB:
+ ret = GBM_FORMAT_ARGB;
+ break;
+ case __DRI_IMAGE_FORMAT_ABGR:
+ ret = GBM_FORMAT_ABGR;
+ break;
+ default:
+ ret = 0;
+ break;
+ }
+
+ return ret;
+}
+
static struct gbm_bo *
gbm_dri_bo_create_from_egl_image(struct gbm_device *gbm,
void *egl_dpy, void *egl_img,
@@ -255,6 +283,7 @@ gbm_dri_bo_create_from_egl_image(struct gbm_device *gbm,
{
struct gbm_dri_device *dri = gbm_dri_devic
Re: [Mesa-dev] [PATCH 1/3] st/mesa: do vertex and fragment color clamping in shaders
Marek Olšák [2012-02-21 21:36]:
> Hi Tilman,
>
> Thanks for the info. I didn't consider outputs to be readable, sorry.
> A quick fix would be to move the outputs to temps. There is a GLSL pass
> for that and it can be enabled by reporting
> PIPE_SHADER_CAP_OUTPUT_READ --> 0 in r600_pipe.c. Can you try that and
> see if it helps?
Confirmed; disabling PIPE_SHADER_CAP_OUTPUT_READ fixes the problem.
Thanks,
Tilman
> On Tue, Feb 21, 2012 at 9:17 PM, Tilman Sauerbeck
> wrote:
> > Tilman Sauerbeck [2012-02-12 11:31]:
> >> Marek Olšák [2012-01-23 13:32]:
> >> > For ARB_color_buffer_float. Most hardware can't do it and st/mesa is
> >> > the perfect place for a fallback.
> >>
> >> This breaks lighting in Heroes of Newerth on my rv730:
> >> http://files.code-monkey.de/frag_color_clamp_bad.png (after patch)
> >> http://files.code-monkey.de/frag_color_clamp_good.png (before patch)
> >> I can provide a trace file that shows the problem (3.5GB, so will take
> >> a while to upload).
> >
> > The problematic fragment shader looks like this:
> >
> > void main() {
> > gl_FragColor = vec4(0.0);
> > gl_FragColor += texture2D(...);
> > gl_FragColor += texture2D(...);
> > gl_FragColor += texture2D(...);
> > gl_FragColor += texture2D(...);
> > gl_FragColor *= 0.25;
> > gl_FragColor *= v_vColor; // varying vec4
> > }
> >
> > Before this patch landed, mesa would generate the following TGSI for
> > that shader:
> >
> > 0: MOV TEMP[0].x, -CONST[1].
> > 1: MOV TEMP[0].y, -CONST[1].
> > 2: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
> > 3: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> > 4: MOV OUT[0], TEMP[0]
> > 5: MOV TEMP[0].x, -CONST[1].
> > 6: MOV TEMP[0].y, CONST[1].
> > 7: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
> > 8: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> > 9: ADD OUT[0], OUT[0], TEMP[0]
> > 10: ADD TEMP[0].xy, IN[0].xyyy, CONST[1].
> > 11: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> > 12: ADD OUT[0], OUT[0], TEMP[0]
> > 13: MOV TEMP[0].x, CONST[1].
> > 14: MOV TEMP[0].y, -CONST[1].
> > 15: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
> > 16: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> > 17: ADD TEMP[0], OUT[0], TEMP[0]
> > 18: MUL TEMP[0], TEMP[0], IMM[0].
> > 19: MUL OUT[0], TEMP[0], IN[1]
> > 20: END
> >
> > With this patch, instructions 4, 9, 12 and 19 are replaced by their
> > _SAT variants.
> >
> > If I hack the code to only use saturate in the final instruction
> > (MUL -> MUL_SAT), the game looks okay.
> >
> > I'm wondering whether the current behaviour is correct in that it uses
> > saturate ops for the intermediate results as well.
> >
> > Issue 24 of the ARB_color_buffer_float says:
> >
> >> 24. Does this extension interact with the ARB_fragment_program or
> >> ARB_fragment_shader extensions?
> >>
> >> RESOLVED: Yes. The only interaction is that the fragment color
> >> clamp enable determines if the final color(s) produced by the
> >> fragment program/shader has its components clamped to [0,1].
> >>
> >> However, the fragment color clamp enable affects only the final
> >> result; it does NOT affect any computations performed during
> >> program execution. Note that the same clamping can be done
> >> explicitly in a fragment program or shader.
> >> ARB_fragment_program provides the "_SAT" opcode suffix to clamp
> >> instruction results to [0,1].
> >
> > If I'm understanding this language correctly, _and_ it applies to GLSL
> > too then it seems like Mesa should only use saturation in the final
> > operation that's writing to gl_FragColor, but not in the earlier ones?
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
pgp9IQ729ayfN.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] ralloc: Make rewrite_tail increase "start" by the new text's length.
Both callers of rewrite_tail immediately compute the new total string
length by adding the (known) length of the existing string plus the
length of the newly appended text. Unfortunately, callers generally
won't know the length of the new text, as it's printf-formatted.
Since ralloc already computes this length, it makes sense to add it in
and save the caller the effort. This simplifies both existing callers,
but more importantly, will allow for cheap-appending in the next commit.
Signed-off-by: Kenneth Graunke
---
src/glsl/link_uniforms.cpp | 14 +-
src/glsl/linker.h |2 +-
src/glsl/ralloc.c | 11 ++-
src/glsl/ralloc.h |6 --
4 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index d51850c..aca6dc0 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -67,7 +67,7 @@ uniform_field_visitor::process(ir_variable *var)
void
uniform_field_visitor::recursion(const glsl_type *t, char **name,
-unsigned name_length)
+size_t name_length)
{
/* Records need to have each field processed individually.
*
@@ -80,20 +80,16 @@ uniform_field_visitor::recursion(const glsl_type *t, char
**name,
const char *field = t->fields.structure[i].name;
/* Append '.field' to the current uniform name. */
-ralloc_asprintf_rewrite_tail(name, name_length, ".%s", field);
+ralloc_asprintf_rewrite_tail(name, &name_length, ".%s", field);
-recursion(t->fields.structure[i].type, name,
- name_length + 1 + strlen(field));
+recursion(t->fields.structure[i].type, name, name_length);
}
} else if (t->is_array() && t->fields.array->is_record()) {
for (unsigned i = 0; i < t->length; i++) {
-char subscript[13];
-
/* Append the subscript to the current uniform name */
-const unsigned subscript_length = snprintf(subscript, 13, "[%u]", i);
-ralloc_asprintf_rewrite_tail(name, name_length, "%s", subscript);
+ralloc_asprintf_rewrite_tail(name, &name_length, "[%u]", i);
-recursion(t->fields.array, name, name_length + subscript_length);
+recursion(t->fields.array, name, name_length);
}
} else {
this->visit_field(t, *name);
diff --git a/src/glsl/linker.h b/src/glsl/linker.h
index 433c63b..0b4c001 100644
--- a/src/glsl/linker.h
+++ b/src/glsl/linker.h
@@ -76,7 +76,7 @@ private:
* \param name_length Length of the current name \b not including the
* terminating \c NUL character.
*/
- void recursion(const glsl_type *t, char **name, unsigned name_length);
+ void recursion(const glsl_type *t, char **name, size_t name_length);
};
#endif /* GLSL_LINKER_H */
diff --git a/src/glsl/ralloc.c b/src/glsl/ralloc.c
index 91e4bab..2f93dcd 100644
--- a/src/glsl/ralloc.c
+++ b/src/glsl/ralloc.c
@@ -448,11 +448,11 @@ ralloc_vasprintf_append(char **str, const char *fmt,
va_list args)
size_t existing_length;
assert(str != NULL);
existing_length = *str ? strlen(*str) : 0;
- return ralloc_vasprintf_rewrite_tail(str, existing_length, fmt, args);
+ return ralloc_vasprintf_rewrite_tail(str, &existing_length, fmt, args);
}
bool
-ralloc_asprintf_rewrite_tail(char **str, size_t start, const char *fmt, ...)
+ralloc_asprintf_rewrite_tail(char **str, size_t *start, const char *fmt, ...)
{
bool success;
va_list args;
@@ -463,7 +463,7 @@ ralloc_asprintf_rewrite_tail(char **str, size_t start,
const char *fmt, ...)
}
bool
-ralloc_vasprintf_rewrite_tail(char **str, size_t start, const char *fmt,
+ralloc_vasprintf_rewrite_tail(char **str, size_t *start, const char *fmt,
va_list args)
{
size_t new_length;
@@ -479,11 +479,12 @@ ralloc_vasprintf_rewrite_tail(char **str, size_t start,
const char *fmt,
new_length = printf_length(fmt, args);
- ptr = resize(*str, start + new_length + 1);
+ ptr = resize(*str, *start + new_length + 1);
if (unlikely(ptr == NULL))
return false;
- vsnprintf(ptr + start, new_length + 1, fmt, args);
+ vsnprintf(ptr + *start, new_length + 1, fmt, args);
*str = ptr;
+ *start += new_length;
return true;
}
diff --git a/src/glsl/ralloc.h b/src/glsl/ralloc.h
index 1324f34..86306b1 100644
--- a/src/glsl/ralloc.h
+++ b/src/glsl/ralloc.h
@@ -329,10 +329,11 @@ char *ralloc_vasprintf(const void *ctx, const char *fmt,
va_list args);
* \param fmt A printf-style formatting string
*
* \p str will be updated to the new pointer unless allocation fails.
+ * \p start will be increased by the length of the newly formatted text.
*
* \return True unless allocation failed.
*/
-bool ralloc_asprintf_rewrite_tail(char **str, size_t start,
+bool ralloc_asprintf_rewrite_tail(char **str, size_t *start,
const char
[Mesa-dev] [PATCH 2/2] glcpp: Don't strlen() the output for every token being printed.
The ralloc string appending functions were originally intended for
simple, non-hot-path uses like printing to an info log.
Cuts Unigine Tropics load time by around 20% (6 seconds).
Signed-off-by: Kenneth Graunke
---
src/glsl/glcpp/glcpp-parse.y | 48 ++---
src/glsl/glcpp/glcpp.h |2 +
2 files changed, 28 insertions(+), 22 deletions(-)
It would be far nicer if we had a string class that stored the length and
had asprintf_append-style methods. Like csString in Crystal Space. But
that's a more invasive change, I think. STL has the ostringstream class
for this exact purpose, but that would require rewriting everything to use
C++ style IO, and I'm loathe to do that (mostly because we don't use it
anywhere else).
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index efcc205..137e97b 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -185,10 +185,12 @@ input:
line:
control_line {
ralloc_strcat (&parser->output, "\n");
+ ++parser->output_length;
}
| text_line {
_glcpp_parser_print_expanded_token_list (parser, $1);
ralloc_strcat (&parser->output, "\n");
+ ++parser->output_length;
ralloc_free ($1);
}
| expanded_line
@@ -320,7 +322,7 @@ control_line:
if ($2 >= 130 || $2 == 100)
add_builtin_define (parser,
"GL_FRAGMENT_PRECISION_HIGH", 1);
- ralloc_asprintf_append (&parser->output, "#version %" PRIiMAX,
$2);
+ ralloc_asprintf_rewrite_tail (&parser->output,
&parser->output_length, "#version %" PRIiMAX, $2);
}
| HASH NEWLINE
;
@@ -903,54 +905,54 @@ _token_list_equal_ignoring_space (token_list_t *a,
token_list_t *b)
}
static void
-_token_print (char **out, token_t *token)
+_token_print (char **out, size_t *len, token_t *token)
{
if (token->type < 256) {
- ralloc_asprintf_append (out, "%c", token->type);
+ ralloc_asprintf_rewrite_tail (out, len, "%c", token->type);
return;
}
switch (token->type) {
case INTEGER:
- ralloc_asprintf_append (out, "%" PRIiMAX, token->value.ival);
+ ralloc_asprintf_rewrite_tail (out, len, "%" PRIiMAX,
token->value.ival);
break;
case IDENTIFIER:
case INTEGER_STRING:
case OTHER:
- ralloc_strcat (out, token->value.str);
+ ralloc_asprintf_rewrite_tail (out, len, "%s", token->value.str);
break;
case SPACE:
- ralloc_strcat (out, " ");
+ ralloc_asprintf_rewrite_tail (out, len, " ");
break;
case LEFT_SHIFT:
- ralloc_strcat (out, "<<");
+ ralloc_asprintf_rewrite_tail (out, len, "<<");
break;
case RIGHT_SHIFT:
- ralloc_strcat (out, ">>");
+ ralloc_asprintf_rewrite_tail (out, len, ">>");
break;
case LESS_OR_EQUAL:
- ralloc_strcat (out, "<=");
+ ralloc_asprintf_rewrite_tail (out, len, "<=");
break;
case GREATER_OR_EQUAL:
- ralloc_strcat (out, ">=");
+ ralloc_asprintf_rewrite_tail (out, len, ">=");
break;
case EQUAL:
- ralloc_strcat (out, "==");
+ ralloc_asprintf_rewrite_tail (out, len, "==");
break;
case NOT_EQUAL:
- ralloc_strcat (out, "!=");
+ ralloc_asprintf_rewrite_tail (out, len, "!=");
break;
case AND:
- ralloc_strcat (out, "&&");
+ ralloc_asprintf_rewrite_tail (out, len, "&&");
break;
case OR:
- ralloc_strcat (out, "||");
+ ralloc_asprintf_rewrite_tail (out, len, "||");
break;
case PASTE:
- ralloc_strcat (out, "##");
+ ralloc_asprintf_rewrite_tail (out, len, "##");
break;
case COMMA_FINAL:
- ralloc_strcat (out, ",");
+ ralloc_asprintf_rewrite_tail (out, len, ",");
break;
case PLACEHOLDER:
/* Nothing to print. */
@@ -1040,11 +1042,11 @@ _token_paste (glcpp_parser_t *parser, token_t *token,
token_t *other)
}
glcpp_error (&token->location, parser, "");
- ralloc_strcat (&parser->info_log, "Pasting \"");
- _token_print (&parser->info_log, token);
- ralloc_strcat (&parser->info_log, "\" and \"");
- _token_print (&parser->info_log, other);
- ralloc_strcat (&parser->info_log, "\" does not give a valid
preprocessing token.\n");
+ ralloc_asprintf_rewrite_tail (&parser->info_log,
&parser->info_log_length, "Pasting \"");
+ _token_print (&parser->info_
[Mesa-dev] [PATCH 00/12] R600g: cleanups and rework of queries
Hi everyone, Besides the cleanups, there are fixes for create_context fail paths and rework of queries. The rework is the most important, because it eliminates buffer_map calls (and therefore buffer_wait) in begin_query. There are no piglit regressions on Evergreen. Please review. Marek Olšák (12): r600g: define GROUP_FORCE_NEW_BLOCK in common header r600g: consolidate common context init code r600g: fix possible crashes in destroy_context when failing in create_context gallium/u_slab: fix possible crash in util_slab_destroy r600g: simplify fail paths in create_context r600g: fixup name of evergreen-specific function r600g: remove duplicated function r600_state_sampler_init r600g: remove duplicated set_xx_resource functions r600g: remove duplicated evergreen_context_pipe_state_set_sampler r600g: remove duplicated evergreen_context_ps_partial_flush r600g: cleanup magic numbers in set_xx_sampler r600g: rework queries src/gallium/auxiliary/util/u_slab.c |8 +- src/gallium/drivers/r600/evergreen_hw_context.c | 115 +- src/gallium/drivers/r600/evergreen_state.c | 16 +- src/gallium/drivers/r600/r600.h | 38 ++-- src/gallium/drivers/r600/r600_hw_context.c | 286 --- src/gallium/drivers/r600/r600_hw_context_priv.h |5 + src/gallium/drivers/r600/r600_pipe.c| 68 -- src/gallium/drivers/r600/r600_query.c | 38 +++- src/gallium/drivers/r600/r600_state_common.c| 21 +-- 9 files changed, 273 insertions(+), 322 deletions(-) Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/12] r600g: define GROUP_FORCE_NEW_BLOCK in common header
---
src/gallium/drivers/r600/evergreen_hw_context.c |2 --
src/gallium/drivers/r600/r600_hw_context.c |2 --
src/gallium/drivers/r600/r600_hw_context_priv.h |2 ++
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index 71edc26..308224b 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -30,8 +30,6 @@
#include "util/u_memory.h"
#include
-#define GROUP_FORCE_NEW_BLOCK 0
-
static const struct r600_reg evergreen_config_reg_list[] = {
{R_008958_VGT_PRIMITIVE_TYPE, 0},
};
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 56a83ae..40a8519 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -29,8 +29,6 @@
#include "util/u_memory.h"
#include
-#define GROUP_FORCE_NEW_BLOCK 0
-
/* Get backends mask */
void r600_get_backend_mask(struct r600_context *ctx)
{
diff --git a/src/gallium/drivers/r600/r600_hw_context_priv.h
b/src/gallium/drivers/r600/r600_hw_context_priv.h
index 61009af..c32fc63 100644
--- a/src/gallium/drivers/r600/r600_hw_context_priv.h
+++ b/src/gallium/drivers/r600/r600_hw_context_priv.h
@@ -44,6 +44,8 @@
#define BLOCK_FLAG_RESOURCE 32
#define REG_FLAG_FLUSH_CHANGE 64
+#define GROUP_FORCE_NEW_BLOCK 0
+
struct r600_reg {
unsignedoffset;
unsignedflags;
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/12] r600g: consolidate common context init code
---
src/gallium/drivers/r600/evergreen_hw_context.c | 16
src/gallium/drivers/r600/r600_hw_context.c | 18 --
src/gallium/drivers/r600/r600_pipe.c| 16
3 files changed, 16 insertions(+), 34 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index 308224b..75fca22 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -713,19 +713,6 @@ int evergreen_context_init(struct r600_context *ctx)
{
int r;
- LIST_INITHEAD(&ctx->active_query_list);
-
- /* init dirty list */
- LIST_INITHEAD(&ctx->dirty);
- LIST_INITHEAD(&ctx->resource_dirty);
- LIST_INITHEAD(&ctx->enable_list);
-
- ctx->range = calloc(NUM_RANGES, sizeof(struct r600_range));
- if (!ctx->range) {
- r = -ENOMEM;
- goto out_err;
- }
-
/* add blocks */
if (ctx->family == CHIP_CAYMAN)
r = r600_context_add_block(ctx, cayman_config_reg_list,
@@ -796,9 +783,6 @@ int evergreen_context_init(struct r600_context *ctx)
if (r)
goto out_err;
- ctx->cs = ctx->ws->cs_create(ctx->ws);
- r600_emit_atom(ctx, &ctx->atom_start_cs.atom);
-
ctx->max_db = 8;
return 0;
out_err:
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 40a8519..5738b48 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -664,9 +664,7 @@ void r600_context_fini(struct r600_context *ctx)
r600_free_resource_range(ctx, &ctx->ps_resources,
ctx->num_ps_resources);
r600_free_resource_range(ctx, &ctx->vs_resources,
ctx->num_vs_resources);
r600_free_resource_range(ctx, &ctx->fs_resources,
ctx->num_fs_resources);
- free(ctx->range);
free(ctx->blocks);
- ctx->ws->cs_destroy(ctx->cs);
}
static void r600_add_resource_block(struct r600_context *ctx, struct
r600_range *range, int num_blocks, int *index)
@@ -720,19 +718,6 @@ int r600_context_init(struct r600_context *ctx)
{
int r;
- LIST_INITHEAD(&ctx->active_query_list);
-
- /* init dirty list */
- LIST_INITHEAD(&ctx->dirty);
- LIST_INITHEAD(&ctx->resource_dirty);
- LIST_INITHEAD(&ctx->enable_list);
-
- ctx->range = calloc(NUM_RANGES, sizeof(struct r600_range));
- if (!ctx->range) {
- r = -ENOMEM;
- goto out_err;
- }
-
/* add blocks */
r = r600_context_add_block(ctx, r600_config_reg_list,
Elements(r600_config_reg_list),
PKT3_SET_CONFIG_REG, R600_CONFIG_REG_OFFSET);
@@ -795,9 +780,6 @@ int r600_context_init(struct r600_context *ctx)
if (r)
goto out_err;
- ctx->cs = ctx->ws->cs_create(ctx->ws);
- r600_emit_atom(ctx, &ctx->atom_start_cs.atom);
-
ctx->max_db = 4;
return 0;
out_err:
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 3d35ed2..e7ba971 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -208,6 +208,10 @@ static void r600_destroy_context(struct pipe_context
*context)
r600_update_num_contexts(rctx->screen, -1);
r600_release_command_buffer(&rctx->atom_start_cs);
+
+ rctx->ws->cs_destroy(rctx->cs);
+
+ FREE(rctx->range);
FREE(rctx);
}
@@ -233,6 +237,16 @@ static struct pipe_context *r600_create_context(struct
pipe_screen *screen, void
rctx->chip_class = rscreen->chip_class;
LIST_INITHEAD(&rctx->dirty_states);
+ LIST_INITHEAD(&rctx->active_query_list);
+ LIST_INITHEAD(&rctx->dirty);
+ LIST_INITHEAD(&rctx->resource_dirty);
+ LIST_INITHEAD(&rctx->enable_list);
+
+ rctx->range = CALLOC(NUM_RANGES, sizeof(struct r600_range));
+ if (!rctx->range) {
+ FREE(rctx);
+ return NULL;
+ }
r600_init_blit_functions(rctx);
r600_init_query_functions(rctx);
@@ -272,7 +286,9 @@ static struct pipe_context *r600_create_context(struct
pipe_screen *screen, void
return NULL;
}
+ rctx->cs = rctx->ws->cs_create(rctx->ws);
rctx->ws->cs_set_flush_callback(rctx->cs, r600_flush_from_winsys, rctx);
+ r600_emit_atom(rctx, &rctx->atom_start_cs.atom);
util_slab_create(&rctx->pool_transfers,
sizeof(struct pipe_transfer), 64,
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/12] r600g: fix possible crashes in destroy_context when failing in create_context
---
src/gallium/drivers/r600/r600_hw_context.c | 36 ---
src/gallium/drivers/r600/r600_pipe.c | 27 +---
2 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 5738b48..fb0923d 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -625,6 +625,11 @@ static void r600_free_resource_range(struct r600_context
*ctx, struct r600_range
{
struct r600_block *block;
int i;
+
+ if (!range->blocks) {
+ return; /* nothing to do */
+ }
+
for (i = 0; i < nblocks; i++) {
block = range->blocks[i];
if (block) {
@@ -634,7 +639,6 @@ static void r600_free_resource_range(struct r600_context
*ctx, struct r600_range
}
}
free(range->blocks);
-
}
/* initialize */
@@ -643,23 +647,25 @@ void r600_context_fini(struct r600_context *ctx)
struct r600_block *block;
struct r600_range *range;
- for (int i = 0; i < NUM_RANGES; i++) {
- if (!ctx->range[i].blocks)
- continue;
- for (int j = 0; j < (1 << HASH_SHIFT); j++) {
- block = ctx->range[i].blocks[j];
- if (block) {
- for (int k = 0, offset = block->start_offset; k
< block->nreg; k++, offset += 4) {
- range =
&ctx->range[CTX_RANGE_ID(offset)];
- range->blocks[CTX_BLOCK_ID(offset)] =
NULL;
- }
- for (int k = 1; k <= block->nbo; k++) {
- pipe_resource_reference((struct
pipe_resource**)&block->reloc[k].bo, NULL);
+ if (ctx->range) {
+ for (int i = 0; i < NUM_RANGES; i++) {
+ if (!ctx->range[i].blocks)
+ continue;
+ for (int j = 0; j < (1 << HASH_SHIFT); j++) {
+ block = ctx->range[i].blocks[j];
+ if (block) {
+ for (int k = 0, offset =
block->start_offset; k < block->nreg; k++, offset += 4) {
+ range =
&ctx->range[CTX_RANGE_ID(offset)];
+
range->blocks[CTX_BLOCK_ID(offset)] = NULL;
+ }
+ for (int k = 1; k <= block->nbo; k++) {
+ pipe_resource_reference((struct
pipe_resource**)&block->reloc[k].bo, NULL);
+ }
+ free(block);
}
- free(block);
}
+ free(ctx->range[i].blocks);
}
- free(ctx->range[i].blocks);
}
r600_free_resource_range(ctx, &ctx->ps_resources,
ctx->num_ps_resources);
r600_free_resource_range(ctx, &ctx->vs_resources,
ctx->num_vs_resources);
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index e7ba971..b2b79cd 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -191,25 +191,32 @@ static void r600_destroy_context(struct pipe_context
*context)
{
struct r600_context *rctx = (struct r600_context *)context;
- rctx->context.delete_depth_stencil_alpha_state(&rctx->context,
rctx->custom_dsa_flush);
+ if (rctx->custom_dsa_flush) {
+ rctx->context.delete_depth_stencil_alpha_state(&rctx->context,
rctx->custom_dsa_flush);
+ }
util_unreference_framebuffer_state(&rctx->framebuffer);
r600_context_fini(rctx);
- util_blitter_destroy(rctx->blitter);
-
+ if (rctx->blitter) {
+ util_blitter_destroy(rctx->blitter);
+ }
for (int i = 0; i < R600_PIPE_NSTATES; i++) {
free(rctx->states[i]);
}
- u_vbuf_destroy(rctx->vbuf_mgr);
+ if (rctx->vbuf_mgr) {
+ u_vbuf_destroy(rctx->vbuf_mgr);
+ }
util_slab_destroy(&rctx->pool_transfers);
r600_update_num_contexts(rctx->screen, -1);
r600_release_command_buffer(&rctx->atom_start_cs);
- rctx->ws->cs_destroy(rctx->cs);
+ if (rctx->cs) {
+ rctx->ws->cs_destroy(rctx->cs);
+ }
FREE(rctx->range);
FREE(rctx);
@@ -223,6 +230,10 @@ static struct pipe_context *r600_create_context(struct
pipe_screen *screen, void
if (rctx == NULL)
return NULL;
+ util_slab_create(&rctx->pool_transfers,
+sizeof(struct pipe_transfer), 64,
+
[Mesa-dev] [PATCH 04/12] gallium/u_slab: fix possible crash in util_slab_destroy
It may happen if util_slab_create has not been called.
---
src/gallium/auxiliary/util/u_slab.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_slab.c
b/src/gallium/auxiliary/util/u_slab.c
index 21bf2d7..f9f5ef6 100644
--- a/src/gallium/auxiliary/util/u_slab.c
+++ b/src/gallium/auxiliary/util/u_slab.c
@@ -160,9 +160,11 @@ void util_slab_destroy(struct util_slab_mempool *pool)
{
struct util_slab_page *page, *temp;
- foreach_s(page, temp, &pool->list) {
- remove_from_list(page);
- FREE(page);
+ if (pool->list.next) {
+ foreach_s(page, temp, &pool->list) {
+ remove_from_list(page);
+ FREE(page);
+ }
}
pipe_mutex_destroy(pool->mutex);
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/12] r600g: simplify fail paths in create_context
---
src/gallium/drivers/r600/r600_pipe.c | 37 +
1 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index b2b79cd..53f9bd6 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -254,10 +254,8 @@ static struct pipe_context *r600_create_context(struct
pipe_screen *screen, void
LIST_INITHEAD(&rctx->enable_list);
rctx->range = CALLOC(NUM_RANGES, sizeof(struct r600_range));
- if (!rctx->range) {
- r600_destroy_context(&rctx->context);
- return NULL;
- }
+ if (!rctx->range)
+ goto fail;
r600_init_blit_functions(rctx);
r600_init_query_functions(rctx);
@@ -275,26 +273,21 @@ static struct pipe_context *r600_create_context(struct
pipe_screen *screen, void
case R700:
r600_init_state_functions(rctx);
r600_init_atom_start_cs(rctx);
- if (r600_context_init(rctx)) {
- r600_destroy_context(&rctx->context);
- return NULL;
- }
+ if (r600_context_init(rctx))
+ goto fail;
rctx->custom_dsa_flush = r600_create_db_flush_dsa(rctx);
break;
case EVERGREEN:
case CAYMAN:
evergreen_init_state_functions(rctx);
evergreen_init_atom_start_cs(rctx);
- if (evergreen_context_init(rctx)) {
- r600_destroy_context(&rctx->context);
- return NULL;
- }
+ if (evergreen_context_init(rctx))
+ goto fail;
rctx->custom_dsa_flush = evergreen_create_db_flush_dsa(rctx);
break;
default:
R600_ERR("Unsupported chip class %d.\n", rctx->chip_class);
- r600_destroy_context(&rctx->context);
- return NULL;
+ goto fail;
}
rctx->cs = rctx->ws->cs_create(rctx->ws);
@@ -306,21 +299,21 @@ static struct pipe_context *r600_create_context(struct
pipe_screen *screen, void
PIPE_BIND_INDEX_BUFFER |
PIPE_BIND_CONSTANT_BUFFER,
U_VERTEX_FETCH_DWORD_ALIGNED);
- if (!rctx->vbuf_mgr) {
- r600_destroy_context(&rctx->context);
- return NULL;
- }
+ if (!rctx->vbuf_mgr)
+ goto fail;
rctx->vbuf_mgr->caps.format_fixed32 = 0;
rctx->blitter = util_blitter_create(&rctx->context);
- if (rctx->blitter == NULL) {
- r600_destroy_context(&rctx->context);
- return NULL;
- }
+ if (rctx->blitter == NULL)
+ goto fail;
r600_get_backend_mask(rctx); /* this emits commands and must be last */
return &rctx->context;
+
+fail:
+ r600_destroy_context(&rctx->context);
+ return NULL;
}
/*
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/12] r600g: fixup name of evergreen-specific function
---
src/gallium/drivers/r600/evergreen_hw_context.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index 75fca22..a58570e 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -630,8 +630,8 @@ static const struct r600_reg cayman_context_reg_list[] = {
{R_028EAC_CB_COLOR11_DIM, 0, 0},
};
-/* SHADER RESOURCE R600/R700 */
-static int r600_resource_range_init(struct r600_context *ctx, struct
r600_range *range, unsigned offset, unsigned nblocks, unsigned stride)
+/* SHADER RESOURCE EG/CM */
+static int evergreen_resource_range_init(struct r600_context *ctx, struct
r600_range *range, unsigned offset, unsigned nblocks, unsigned stride)
{
struct r600_reg r600_shader_resource[] = {
{R_03_RESOURCE0_WORD0, REG_FLAG_NEED_BO, 0},
@@ -764,13 +764,13 @@ int evergreen_context_init(struct r600_context *ctx)
ctx->num_ps_resources = 176;
ctx->num_vs_resources = 160;
ctx->num_fs_resources = 16;
- r = r600_resource_range_init(ctx, &ctx->ps_resources, 0, 176, 0x20);
+ r = evergreen_resource_range_init(ctx, &ctx->ps_resources, 0, 176,
0x20);
if (r)
goto out_err;
- r = r600_resource_range_init(ctx, &ctx->vs_resources, 0x1600, 160,
0x20);
+ r = evergreen_resource_range_init(ctx, &ctx->vs_resources, 0x1600, 160,
0x20);
if (r)
goto out_err;
- r = r600_resource_range_init(ctx, &ctx->fs_resources, 0x7C00, 16, 0x20);
+ r = evergreen_resource_range_init(ctx, &ctx->fs_resources, 0x7C00, 16,
0x20);
if (r)
goto out_err;
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/12] r600g: remove duplicated function r600_state_sampler_init
---
src/gallium/drivers/r600/evergreen_hw_context.c | 16
src/gallium/drivers/r600/r600_hw_context.c |4 ++--
src/gallium/drivers/r600/r600_hw_context_priv.h |1 +
3 files changed, 3 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index a58570e..bf6f422 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -648,22 +648,6 @@ static int evergreen_resource_range_init(struct
r600_context *ctx, struct r600_r
return r600_resource_init(ctx, range, offset, nblocks, stride,
r600_shader_resource, nreg, EVERGREEN_RESOURCE_OFFSET);
}
-/* SHADER SAMPLER R600/R700 */
-static int r600_state_sampler_init(struct r600_context *ctx, uint32_t offset)
-{
- struct r600_reg r600_shader_sampler[] = {
- {R_03C000_SQ_TEX_SAMPLER_WORD0_0, 0, 0},
- {R_03C004_SQ_TEX_SAMPLER_WORD1_0, 0, 0},
- {R_03C008_SQ_TEX_SAMPLER_WORD2_0, 0, 0},
- };
- unsigned nreg = Elements(r600_shader_sampler);
-
- for (int i = 0; i < nreg; i++) {
- r600_shader_sampler[i].offset += offset;
- }
- return r600_context_add_block(ctx, r600_shader_sampler, nreg,
PKT3_SET_SAMPLER, EVERGREEN_SAMPLER_OFFSET);
-}
-
/* SHADER SAMPLER BORDER EG/CM */
static int evergreen_state_sampler_border_init(struct r600_context *ctx,
uint32_t offset, unsigned id)
{
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index fb0923d..e73b609 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -574,8 +574,8 @@ static int r600_resource_range_init(struct r600_context
*ctx, struct r600_range
return r600_resource_init(ctx, range, offset, nblocks, stride,
r600_shader_resource, nreg, R600_RESOURCE_OFFSET);
}
-/* SHADER SAMPLER R600/R700 */
-static int r600_state_sampler_init(struct r600_context *ctx, uint32_t offset)
+/* SHADER SAMPLER R600/R700/EG/CM */
+int r600_state_sampler_init(struct r600_context *ctx, uint32_t offset)
{
struct r600_reg r600_shader_sampler[] = {
{R_03C000_SQ_TEX_SAMPLER_WORD0_0, 0, 0},
diff --git a/src/gallium/drivers/r600/r600_hw_context_priv.h
b/src/gallium/drivers/r600/r600_hw_context_priv.h
index c32fc63..7001890 100644
--- a/src/gallium/drivers/r600/r600_hw_context_priv.h
+++ b/src/gallium/drivers/r600/r600_hw_context_priv.h
@@ -63,6 +63,7 @@ void r600_context_dirty_block(struct r600_context *ctx,
struct r600_block *block
int dirty, int index);
int r600_setup_block_table(struct r600_context *ctx);
int r600_resource_init(struct r600_context *ctx, struct r600_range *range,
unsigned offset, unsigned nblocks, unsigned stride, struct r600_reg *reg, int
nreg, unsigned offset_base);
+int r600_state_sampler_init(struct r600_context *ctx, uint32_t offset);
/*
* evergreen_hw_context.c
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/12] r600g: remove duplicated set_xx_resource functions
---
src/gallium/drivers/r600/evergreen_hw_context.c | 21 -
src/gallium/drivers/r600/evergreen_state.c | 16
src/gallium/drivers/r600/r600.h |3 ---
src/gallium/drivers/r600/r600_state_common.c| 21 +
4 files changed, 13 insertions(+), 48 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index bf6f422..a547475 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -774,27 +774,6 @@ out_err:
return r;
}
-void evergreen_context_pipe_state_set_ps_resource(struct r600_context *ctx,
struct r600_pipe_resource_state *state, unsigned rid)
-{
- struct r600_block *block = ctx->ps_resources.blocks[rid];
-
- r600_context_pipe_state_set_resource(ctx, state, block);
-}
-
-void evergreen_context_pipe_state_set_vs_resource(struct r600_context *ctx,
struct r600_pipe_resource_state *state, unsigned rid)
-{
- struct r600_block *block = ctx->vs_resources.blocks[rid];
-
- r600_context_pipe_state_set_resource(ctx, state, block);
-}
-
-void evergreen_context_pipe_state_set_fs_resource(struct r600_context *ctx,
struct r600_pipe_resource_state *state, unsigned rid)
-{
- struct r600_block *block = ctx->fs_resources.blocks[rid];
-
- r600_context_pipe_state_set_resource(ctx, state, block);
-}
-
static inline void evergreen_context_pipe_state_set_sampler(struct
r600_context *ctx, struct r600_pipe_state *state, unsigned offset)
{
struct r600_range *range;
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index c4da360..4eca42c 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1061,8 +1061,8 @@ static void evergreen_set_vs_sampler_view(struct
pipe_context *ctx, unsigned cou
for (int i = 0; i < count; i++) {
if (resource[i]) {
- evergreen_context_pipe_state_set_vs_resource(rctx,
&resource[i]->state,
-i +
R600_MAX_CONST_BUFFERS);
+ r600_context_pipe_state_set_vs_resource(rctx,
&resource[i]->state,
+ i +
R600_MAX_CONST_BUFFERS);
}
}
}
@@ -1080,11 +1080,11 @@ static void evergreen_set_ps_sampler_view(struct
pipe_context *ctx, unsigned cou
if (resource[i]) {
if (((struct r600_resource_texture
*)resource[i]->base.texture)->depth)
has_depth = 1;
-
evergreen_context_pipe_state_set_ps_resource(rctx, &resource[i]->state,
-i
+ R600_MAX_CONST_BUFFERS);
+ r600_context_pipe_state_set_ps_resource(rctx,
&resource[i]->state,
+ i +
R600_MAX_CONST_BUFFERS);
} else
-
evergreen_context_pipe_state_set_ps_resource(rctx, NULL,
-i
+ R600_MAX_CONST_BUFFERS);
+ r600_context_pipe_state_set_ps_resource(rctx,
NULL,
+ i +
R600_MAX_CONST_BUFFERS);
pipe_sampler_view_reference(
(struct pipe_sampler_view
**)&rctx->ps_samplers.views[i],
@@ -1098,8 +1098,8 @@ static void evergreen_set_ps_sampler_view(struct
pipe_context *ctx, unsigned cou
}
for (i = count; i < NUM_TEX_UNITS; i++) {
if (rctx->ps_samplers.views[i]) {
- evergreen_context_pipe_state_set_ps_resource(rctx, NULL,
-i +
R600_MAX_CONST_BUFFERS);
+ r600_context_pipe_state_set_ps_resource(rctx, NULL,
+ i +
R600_MAX_CONST_BUFFERS);
pipe_sampler_view_reference((struct pipe_sampler_view
**)&rctx->ps_samplers.views[i], NULL);
}
}
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index a792e94..deba53f 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -235,9 +235,6 @@ void r600_context_block_emit_dirty(struct r600_context
*ctx, struct r600_block *
void r600_context_block_resource_emit_dirty(struct r600_context *ctx, struct
r600_block *block);
int evergreen_context_init(struct r600_context *ctx);
-void evergreen_context_pipe_state_set_ps_resource(struct r600_context *ctx,
struct r600_pipe_
[Mesa-dev] [PATCH 09/12] r600g: remove duplicated evergreen_context_pipe_state_set_sampler
---
src/gallium/drivers/r600/evergreen_hw_context.c | 31 +-
src/gallium/drivers/r600/r600_hw_context.c |4 +-
src/gallium/drivers/r600/r600_hw_context_priv.h |1 +
3 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index a547475..b0620a2 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -774,33 +774,6 @@ out_err:
return r;
}
-static inline void evergreen_context_pipe_state_set_sampler(struct
r600_context *ctx, struct r600_pipe_state *state, unsigned offset)
-{
- struct r600_range *range;
- struct r600_block *block;
- int i;
- int dirty;
-
- range = &ctx->range[CTX_RANGE_ID(offset)];
- block = range->blocks[CTX_BLOCK_ID(offset)];
- if (state == NULL) {
- block->status &= ~(R600_BLOCK_STATUS_ENABLED |
R600_BLOCK_STATUS_DIRTY);
- LIST_DELINIT(&block->list);
- LIST_DELINIT(&block->enable_list);
- return;
- }
- dirty = block->status & R600_BLOCK_STATUS_DIRTY;
-
- for (i = 0; i < 3; i++) {
- if (block->reg[i] != state->regs[i].value) {
- dirty |= R600_BLOCK_STATUS_DIRTY;
- block->reg[i] = state->regs[i].value;
- }
- }
- if (dirty)
- r600_context_dirty_block(ctx, block, dirty, 2);
-}
-
static inline void evergreen_context_ps_partial_flush(struct r600_context *ctx)
{
struct radeon_winsys_cs *cs = ctx->cs;
@@ -861,7 +834,7 @@ void evergreen_context_pipe_state_set_ps_sampler(struct
r600_context *ctx, struc
unsigned offset;
offset = 0x0003C000 + id * 0xc;
- evergreen_context_pipe_state_set_sampler(ctx, state, offset);
+ r600_context_pipe_state_set_sampler(ctx, state, offset);
evergreen_context_pipe_state_set_sampler_border(ctx, state,
R_00A400_TD_PS_SAMPLER0_BORDER_INDEX, id);
}
@@ -870,7 +843,7 @@ void evergreen_context_pipe_state_set_vs_sampler(struct
r600_context *ctx, struc
unsigned offset;
offset = 0x0003C0D8 + id * 0xc;
- evergreen_context_pipe_state_set_sampler(ctx, state, offset);
+ r600_context_pipe_state_set_sampler(ctx, state, offset);
evergreen_context_pipe_state_set_sampler_border(ctx, state,
R_00A414_TD_VS_SAMPLER0_BORDER_INDEX, id);
}
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index e73b609..b0a0f30 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -992,7 +992,7 @@ void r600_context_pipe_state_set_fs_resource(struct
r600_context *ctx, struct r6
r600_context_pipe_state_set_resource(ctx, state, block);
}
-static inline void r600_context_pipe_state_set_sampler(struct r600_context
*ctx, struct r600_pipe_state *state, unsigned offset)
+void r600_context_pipe_state_set_sampler(struct r600_context *ctx, struct
r600_pipe_state *state, unsigned offset)
{
struct r600_range *range;
struct r600_block *block;
@@ -1008,6 +1008,7 @@ static inline void
r600_context_pipe_state_set_sampler(struct r600_context *ctx,
return;
}
dirty = block->status & R600_BLOCK_STATUS_DIRTY;
+
for (i = 0; i < 3; i++) {
if (block->reg[i] != state->regs[i].value) {
block->reg[i] = state->regs[i].value;
@@ -1019,7 +1020,6 @@ static inline void
r600_context_pipe_state_set_sampler(struct r600_context *ctx,
r600_context_dirty_block(ctx, block, dirty, 2);
}
-
static inline void r600_context_pipe_state_set_sampler_border(struct
r600_context *ctx, struct r600_pipe_state *state, unsigned offset)
{
struct r600_range *range;
diff --git a/src/gallium/drivers/r600/r600_hw_context_priv.h
b/src/gallium/drivers/r600/r600_hw_context_priv.h
index 7001890..5894320 100644
--- a/src/gallium/drivers/r600/r600_hw_context_priv.h
+++ b/src/gallium/drivers/r600/r600_hw_context_priv.h
@@ -64,6 +64,7 @@ void r600_context_dirty_block(struct r600_context *ctx,
struct r600_block *block
int r600_setup_block_table(struct r600_context *ctx);
int r600_resource_init(struct r600_context *ctx, struct r600_range *range,
unsigned offset, unsigned nblocks, unsigned stride, struct r600_reg *reg, int
nreg, unsigned offset_base);
int r600_state_sampler_init(struct r600_context *ctx, uint32_t offset);
+void r600_context_pipe_state_set_sampler(struct r600_context *ctx, struct
r600_pipe_state *state, unsigned offset);
/*
* evergreen_hw_context.c
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/12] r600g: remove duplicated evergreen_context_ps_partial_flush
---
src/gallium/drivers/r600/evergreen_hw_context.c | 15 +--
src/gallium/drivers/r600/r600_hw_context.c |2 +-
src/gallium/drivers/r600/r600_hw_context_priv.h |1 +
3 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index b0620a2..989473b 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -774,19 +774,6 @@ out_err:
return r;
}
-static inline void evergreen_context_ps_partial_flush(struct r600_context *ctx)
-{
- struct radeon_winsys_cs *cs = ctx->cs;
-
- if (!(ctx->flags & R600_CONTEXT_DRAW_PENDING))
- return;
-
- cs->buf[cs->cdw++] = PKT3(PKT3_EVENT_WRITE, 0, 0);
- cs->buf[cs->cdw++] = EVENT_TYPE(EVENT_TYPE_PS_PARTIAL_FLUSH) |
EVENT_INDEX(4);
-
- ctx->flags &= ~R600_CONTEXT_DRAW_PENDING;
-}
-
static inline void evergreen_context_pipe_state_set_sampler_border(struct
r600_context *ctx, struct r600_pipe_state *state, unsigned offset, unsigned id)
{
unsigned fake_offset = (offset - R_00A400_TD_PS_SAMPLER0_BORDER_INDEX)
* 0x100 + 0x4 + id * 0x1C;
@@ -824,7 +811,7 @@ static inline void
evergreen_context_pipe_state_set_sampler_border(struct r600_c
* registers, or previous draw commands that haven't completed yet
* will end up using the new border color. */
if (dirty & R600_BLOCK_STATUS_DIRTY)
- evergreen_context_ps_partial_flush(ctx);
+ r600_context_ps_partial_flush(ctx);
if (dirty)
r600_context_dirty_block(ctx, block, dirty, 4);
}
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index b0a0f30..526b02a 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -112,7 +112,7 @@ err:
return;
}
-static inline void r600_context_ps_partial_flush(struct r600_context *ctx)
+void r600_context_ps_partial_flush(struct r600_context *ctx)
{
struct radeon_winsys_cs *cs = ctx->cs;
diff --git a/src/gallium/drivers/r600/r600_hw_context_priv.h
b/src/gallium/drivers/r600/r600_hw_context_priv.h
index 5894320..ac5b4cb 100644
--- a/src/gallium/drivers/r600/r600_hw_context_priv.h
+++ b/src/gallium/drivers/r600/r600_hw_context_priv.h
@@ -65,6 +65,7 @@ int r600_setup_block_table(struct r600_context *ctx);
int r600_resource_init(struct r600_context *ctx, struct r600_range *range,
unsigned offset, unsigned nblocks, unsigned stride, struct r600_reg *reg, int
nreg, unsigned offset_base);
int r600_state_sampler_init(struct r600_context *ctx, uint32_t offset);
void r600_context_pipe_state_set_sampler(struct r600_context *ctx, struct
r600_pipe_state *state, unsigned offset);
+void r600_context_ps_partial_flush(struct r600_context *ctx);
/*
* evergreen_hw_context.c
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/12] r600g: cleanup magic numbers in set_xx_sampler
---
src/gallium/drivers/r600/evergreen_hw_context.c |4 ++--
src/gallium/drivers/r600/r600_hw_context.c |8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index 989473b..0bc2863 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -820,7 +820,7 @@ void evergreen_context_pipe_state_set_ps_sampler(struct
r600_context *ctx, struc
{
unsigned offset;
- offset = 0x0003C000 + id * 0xc;
+ offset = R_03C000_SQ_TEX_SAMPLER_WORD0_0 + 12*id;
r600_context_pipe_state_set_sampler(ctx, state, offset);
evergreen_context_pipe_state_set_sampler_border(ctx, state,
R_00A400_TD_PS_SAMPLER0_BORDER_INDEX, id);
}
@@ -829,7 +829,7 @@ void evergreen_context_pipe_state_set_vs_sampler(struct
r600_context *ctx, struc
{
unsigned offset;
- offset = 0x0003C0D8 + id * 0xc;
+ offset = R_03C000_SQ_TEX_SAMPLER_WORD0_0 + 12*(id + 18);
r600_context_pipe_state_set_sampler(ctx, state, offset);
evergreen_context_pipe_state_set_sampler_border(ctx, state,
R_00A414_TD_VS_SAMPLER0_BORDER_INDEX, id);
}
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 526b02a..c1fa9db 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -1059,9 +1059,9 @@ void r600_context_pipe_state_set_ps_sampler(struct
r600_context *ctx, struct r60
{
unsigned offset;
- offset = 0x0003C000 + id * 0xc;
+ offset = R_03C000_SQ_TEX_SAMPLER_WORD0_0 + 12*id;
r600_context_pipe_state_set_sampler(ctx, state, offset);
- offset = 0xA400 + id * 0x10;
+ offset = R_00A400_TD_PS_SAMPLER0_BORDER_RED + 16*id;
r600_context_pipe_state_set_sampler_border(ctx, state, offset);
}
@@ -1069,9 +1069,9 @@ void r600_context_pipe_state_set_vs_sampler(struct
r600_context *ctx, struct r60
{
unsigned offset;
- offset = 0x0003C0D8 + id * 0xc;
+ offset = R_03C000_SQ_TEX_SAMPLER_WORD0_0 + 12*(id + 18);
r600_context_pipe_state_set_sampler(ctx, state, offset);
- offset = 0xA600 + id * 0x10;
+ offset = R_00A600_TD_VS_SAMPLER0_BORDER_RED + 16*id;
r600_context_pipe_state_set_sampler_border(ctx, state, offset);
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/12] r600g: rework queries
We always mapped the query buffer in begin_query, causing stalls
if the buffer was busy.
This commit reworks it such that the query buffer is only mapped
in get_query_result as it's supposed to be.
The query buffer is no longer treated as a ring buffer. Instead, the results
are just appended and when the buffer is full, we create a new one. One query
can have more than one query buffer, though that's a very rare case.
Begin_query releases all query buffers.
---
src/gallium/drivers/r600/r600.h| 35 +++--
src/gallium/drivers/r600/r600_hw_context.c | 212
src/gallium/drivers/r600/r600_query.c | 38 --
3 files changed, 168 insertions(+), 117 deletions(-)
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index deba53f..1db9b28 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -157,25 +157,31 @@ struct r600_range {
struct r600_block **blocks;
};
-struct r600_query {
- union {
- uint64_tu64;
- boolean b;
- struct pipe_query_data_so_statistics so;
- } result;
- /* The kind of query */
- unsignedtype;
- /* Offset of the first result for current query */
- unsignedresults_start;
+struct r600_query_buffer {
+ /* The buffer where query results are stored. */
+ struct r600_resource*buf;
/* Offset of the next free result after current query data */
unsignedresults_end;
+ /* If a query buffer is full, a new buffer is created and the old one
+* is put in here. When we calculate the result, we sum up the samples
+* from all buffers. */
+ struct r600_query_buffer*previous;
+};
+
+union r600_query_result {
+ uint64_tu64;
+ boolean b;
+ struct pipe_query_data_so_statistics so;
+};
+
+struct r600_query {
+ /* The query buffer and how many results are in it. */
+ struct r600_query_bufferbuffer;
+ /* The type of query */
+ unsignedtype;
/* Size of the result in memory for both begin_query and end_query,
* this can be one or two numbers, or it could even be a size of a
structure. */
unsignedresult_size;
- /* The buffer where query results are stored. It's used as a ring,
-* data blocks for current query are stored sequentially from
-* results_start to results_end, with wrapping on the buffer end */
- struct r600_resource*buffer;
/* The number of dwords for begin_query or end_query. */
unsignednum_cs_dw;
/* linked list of queries */
@@ -214,6 +220,7 @@ void r600_context_query_destroy(struct r600_context *ctx,
struct r600_query *que
boolean r600_context_query_result(struct r600_context *ctx,
struct r600_query *query,
boolean wait, void *vresult);
+struct r600_resource *r600_new_query_buffer(struct r600_context *ctx, unsigned
type);
void r600_query_begin(struct r600_context *ctx, struct r600_query *query);
void r600_query_end(struct r600_context *ctx, struct r600_query *query);
void r600_context_queries_suspend(struct r600_context *ctx);
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index c1fa9db..8c2e183 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -1349,12 +1349,16 @@ static unsigned r600_query_read_result(char *map,
unsigned start_index, unsigned
return 0;
}
-static boolean r600_query_result(struct r600_context *ctx, struct r600_query
*query, boolean wait)
+static boolean r600_query_buffer_result(struct r600_context *ctx,
+ struct r600_query *query,
+ struct r600_query_buffer *qbuf,
+ boolean wait,
+ union r600_query_result *result)
{
- unsigned results_base = query->results_start;
+ unsigned results_base = 0;
char *map;
- map = ctx->ws->buffer_map(query->buffer->buf, ctx->cs,
+ map = ctx->ws->buffer_map(qbuf->buf->buf, ctx->cs,
PIPE_TRANSFER_READ |
(wait ? 0 : PIPE_TRANSFER_DONTBLOCK));
if (!map)
@@ -1363,24 +1367,24 @@ static boolean r600_query_result(struct r600_context
*ctx, struct r600_query *qu
/* count all results across all data blocks */
switch (query->type) {
case PIPE_QUERY_OCCLUSION_COUNTER:
-
[Mesa-dev] [Bug 46376] display window will be black when run mesa demo gloss
https://bugs.freedesktop.org/show_bug.cgi?id=46376 --- Comment #1 from libo 2012-02-21 19:20:05 UTC --- The bug also exists when run the case with LIBGL_ALWAYS_SOFTWARE=1. Some mesa xdemos and EGL cases such as opengles2/es2_info also has this 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 1/3] st/mesa: do vertex and fragment color clamping in shaders
Draw module (aaline, aapoint, and pstipple stages) will also be broken with
PIPE_SHADER_CAP_OUTPUT_READ=1.
llvmpipe too, has analysis which rely on outputs not being read.
Nothing of the above matters to r600, of course.
Nevertheless, I can't help thinking that PIPE_SHADER_CAP_OUTPUT_READ is a
mistake from a semantic point of view, as it really hinders our ability to do
simple manipulations of the TGSI, as in this case. And to squeeze maximum
performance a pipe driver will need an optimizing compiler regardless, so the
benefits are minimal from what I can see.
I think it would be better to remove PIPE_SHADER_CAP_OUTPUT_READ, and strictly
enforce that outpus can't be read, same way as inputs can't be written.
Jose
- Original Message -
> Hi Tilman,
>
> Thanks for the info. I didn't consider outputs to be readable, sorry.
> A quick fix would be to move the outputs to temps. There is a GLSL
> pass
> for that and it can be enabled by reporting
> PIPE_SHADER_CAP_OUTPUT_READ --> 0 in r600_pipe.c. Can you try that
> and
> see if it helps?
>
> To Vadim: Now that we have a GLSL pass for lowering output reads, are
> you okay with removing PIPE_SHADER_CAP_OUTPUT_READ? It makes the
> fallback for glClampColorARB really non-trivial.
>
> Marek
>
> On Tue, Feb 21, 2012 at 9:17 PM, Tilman Sauerbeck
> wrote:
> > Tilman Sauerbeck [2012-02-12 11:31]:
> >> Marek Olšák [2012-01-23 13:32]:
> >> > For ARB_color_buffer_float. Most hardware can't do it and
> >> > st/mesa is
> >> > the perfect place for a fallback.
> >>
> >> This breaks lighting in Heroes of Newerth on my rv730:
> >> http://files.code-monkey.de/frag_color_clamp_bad.png (after
> >> patch)
> >> http://files.code-monkey.de/frag_color_clamp_good.png (before
> >> patch)
> >> I can provide a trace file that shows the problem (3.5GB, so will
> >> take
> >> a while to upload).
> >
> > The problematic fragment shader looks like this:
> >
> > void main() {
> > gl_FragColor = vec4(0.0);
> > gl_FragColor += texture2D(...);
> > gl_FragColor += texture2D(...);
> > gl_FragColor += texture2D(...);
> > gl_FragColor += texture2D(...);
> > gl_FragColor *= 0.25;
> > gl_FragColor *= v_vColor; // varying vec4
> > }
> >
> > Before this patch landed, mesa would generate the following TGSI
> > for
> > that shader:
> >
> > 0: MOV TEMP[0].x, -CONST[1].
> > 1: MOV TEMP[0].y, -CONST[1].
> > 2: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
> > 3: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> > 4: MOV OUT[0], TEMP[0]
> > 5: MOV TEMP[0].x, -CONST[1].
> > 6: MOV TEMP[0].y, CONST[1].
> > 7: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
> > 8: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> > 9: ADD OUT[0], OUT[0], TEMP[0]
> > 10: ADD TEMP[0].xy, IN[0].xyyy, CONST[1].
> > 11: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> > 12: ADD OUT[0], OUT[0], TEMP[0]
> > 13: MOV TEMP[0].x, CONST[1].
> > 14: MOV TEMP[0].y, -CONST[1].
> > 15: ADD TEMP[0].xy, IN[0].xyyy, TEMP[0].xyyy
> > 16: TEX TEMP[0], TEMP[0].xyyy, SAMP[0], 2D
> > 17: ADD TEMP[0], OUT[0], TEMP[0]
> > 18: MUL TEMP[0], TEMP[0], IMM[0].
> > 19: MUL OUT[0], TEMP[0], IN[1]
> > 20: END
> >
> > With this patch, instructions 4, 9, 12 and 19 are replaced by their
> > _SAT variants.
> >
> > If I hack the code to only use saturate in the final instruction
> > (MUL -> MUL_SAT), the game looks okay.
> >
> > I'm wondering whether the current behaviour is correct in that it
> > uses
> > saturate ops for the intermediate results as well.
> >
> > Issue 24 of the ARB_color_buffer_float says:
> >
> >> 24. Does this extension interact with the ARB_fragment_program or
> >> ARB_fragment_shader extensions?
> >>
> >> RESOLVED: Yes. The only interaction is that the fragment
> >> color
> >> clamp enable determines if the final color(s) produced by the
> >> fragment program/shader has its components clamped to [0,1].
> >>
> >> However, the fragment color clamp enable affects only the
> >> final
> >> result; it does NOT affect any computations performed during
> >> program execution. Note that the same clamping can be done
> >> explicitly in a fragment program or shader.
> >> ARB_fragment_program provides the "_SAT" opcode suffix to
> >> clamp
> >> instruction results to [0,1].
> >
> > If I'm understanding this language correctly, _and_ it applies to
> > GLSL
> > too then it seems like Mesa should only use saturation in the final
> > operation that's writing to gl_FragColor, but not in the earlier
> > ones?
> >
> > Regards,
> > Tilman
> >
> > --
> > A: Because it messes up the order in which people normally read
> > text.
> > Q: Why is top-posting such a bad thing?
> > A: Top-posting.
> > Q: What is the most annoying thing on usenet and in e-mail?
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_
[Mesa-dev] [ANNOUNCE] New mailing list for VDPAU discussion
For those interested in VDPAU, I've created a new mailing list, vd...@lists.freedesktop.org. http://lists.freedesktop.org/mailman/listinfo/vdpau -- Aaron ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
