Re: [Mesa-dev] The way r600g handles shaders that use more than available GPRs
On 20.04.2014 03:02, Marek Olšák wrote: It looks like the check is not needed with SB, because SB performs register allocation. What happens if you comment out the conditional which fails? SB takes the machine code generated by the "classic" compiler as input, so the check is still needed. The best solution for this problem would be to integrate Vadim's tgsi-to-sb branch, which goes directly from TGSI to SB's internal representation, without the classic compiler as a middle man. As far as I know, even with SB there is no spilling implemented, but it should only be a problem with really crazy shaders. SB optimizes register usage quite well. Grigori Marek On Sun, Apr 20, 2014 at 1:30 AM, Marcello Maggioni wrote: Hello, I realized while playing Diablo III on my machine that some shaders seem to run out of available GPRs using r600g with my Macbook Pro with a HD6750m. If the driver tries to do something to handle this case, but I couldn't find any part inside the code that has to do with "spilling". There are some register related passes in SB, but none seems to be related to possible spilling (anyway, the failing I get is in r600_shader.c:2148 inside "r600_shader_from_tgsi()" which makes shader compiling failing altogether skipping SB). How does r600g handle out of register situations? If it doesn't there are plans to add this? Cheers, Marcello ___ 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] The way r600g handles shaders that use more than available GPRs
This sounds like a very sensible solution if the direction the driver wants to go is having SB as the only backend Marcello On Sunday, 20 April 2014, Grigori Goronzy wrote: > On 20.04.2014 03:02, Marek Olšák wrote: > >> It looks like the check is not needed with SB, because SB performs >> register allocation. What happens if you comment out the conditional >> which fails? >> >> > SB takes the machine code generated by the "classic" compiler as input, so > the check is still needed. The best solution for this problem would be to > integrate Vadim's tgsi-to-sb branch, which goes directly from TGSI to SB's > internal representation, without the classic compiler as a middle man. > > As far as I know, even with SB there is no spilling implemented, but it > should only be a problem with really crazy shaders. SB optimizes register > usage quite well. > > Grigori > > Marek >> >> On Sun, Apr 20, 2014 at 1:30 AM, Marcello Maggioni >> wrote: >> >>> Hello, >>> >>> I realized while playing Diablo III on my machine that some shaders seem >>> to >>> run out of available GPRs using r600g with my Macbook Pro with a HD6750m. >>> If the driver tries to do something to handle this case, but I couldn't >>> find >>> any part inside the code that has to do with "spilling". >>> >>> There are some register related passes in SB, but none seems to be >>> related >>> to possible spilling (anyway, the failing I get is in r600_shader.c:2148 >>> inside "r600_shader_from_tgsi()" which makes shader compiling failing >>> altogether skipping SB). >>> >>> How does r600g handle out of register situations? If it doesn't there are >>> plans to add this? >>> >>> Cheers, >>> Marcello >>> >>> ___ >>> 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77693] New: Mesa software rasterizers - decompress textures on load to improve performance
https://bugs.freedesktop.org/show_bug.cgi?id=77693 Priority: medium Bug ID: 77693 Assignee: mesa-dev@lists.freedesktop.org Summary: Mesa software rasterizers - decompress textures on load to improve performance Severity: enhancement Classification: Unclassified OS: Linux (All) Reporter: cosinusoida...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa I noticed that a couple of WebGL demos that use texture compression perform poorly when using LLVMpipe. I patched mesa to decompress the textures during load. This yielded about 4 times the performance of using libtxc_dxtn to sample the compressed textures during rasterization. The patch intercepts calls to glCompressedTexImage2D, decompresses the texture and then calls glTexImage2D with the uncompressed data. The patch is hard coded to take GL_COMPRESSED_RGBA_S3TC_DXT5_ANGLE textures and to convert them in to GL_RGBA GL_UNSIGNED_BYTE textures. I've also basically pasted libtxc_dxtn in to src/mesa/main/teximage.c . Obviously this patch isn't production ready but it does illustrate the potential performance win at least in the case of s3tc textures (at the expense of increased memory usage). I used the following set up: * Current mesa from git (ba6dcb3c2b8f516b120f591144bf6c3751f0e3f9) * 64 bit Ubuntu 12.04 * LLVM 3.4 prebuilt binary from from http://llvm.org/releases/ * LLVMpipe built with scons build=release llvmpipe libgl-xlib * Core 2 Duo E8400 I tested on the following two pages in Firefox 28 (libtxc_dxtn vs my patch): Simple cube with a compressed texture http://media.tojicode.com/webgl-samples/dds.html * 40fps 180% CPU without patch * 60fps 80% CPU with patch Mozilla Bananabread Arena demo level on https://developer.cdn.mozilla.net/media/uploads/demos/a/z/azakai/3baf4ad7e600cbda06ec46efec5ec3b8/bananabread_1373485124_demo_package/game.html?setup=low&serve (or https://developer.mozilla.org/en/demos/detail/bananabread) * 6fps without patch * 20 fps with patch -- 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 77693] Mesa software rasterizers - decompress textures on load to improve performance
https://bugs.freedesktop.org/show_bug.cgi?id=77693 --- Comment #1 from Liam Wilson --- Created attachment 97645 --> https://bugs.freedesktop.org/attachment.cgi?id=97645&action=edit Texture decompression patch -- 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 77502] libOpenVG contains no vg Symbols
https://bugs.freedesktop.org/show_bug.cgi?id=77502 --- Comment #3 from farmboy0+freedesk...@googlemail.com --- 144bbb7b78ecac33c62c6dc28df1747a73c4eb39 is the first bad commit commit 144bbb7b78ecac33c62c6dc28df1747a73c4eb39 Author: Matt Turner Date: Sun Nov 10 19:01:58 2013 -0800 glapi/build: Add headers to distribution. Acked-by: Emil Velikov :04 04 ff16728fbfb4be2efd29189bfa01cde90300e2f8 452478ea59b48f9d28300f90fb38e3cb4f1ac66e M src -- 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 00/16] DRI*extension cleanups v3
On 04/04/14 23:41, Ian Romanick wrote: > On 03/16/2014 06:48 AM, Emil Velikov wrote: >> Hi all, >> >> Here is the third iteration of some DRI*extension cleanup patches. >> >> This revision adds some minor updates and squashes the patches into >> a shorter patchset. >> >> The previous revision can be found at >> http://lists.freedesktop.org/archives/mesa-dev/2014-February/054327.html >> >> For people interested in testing/pulling the patches, they can be found >> at https://github.com/evelikov/Mesa dri-extension-cleanup-v3 >> >> Comments and review are grately appreciated. > > The series is > > Reviewed-by: Ian Romanick > Thanks for the review Ian. > However, before these patches get pushed, I'd like to see: > > - At least an Acked-by from Kristian on patch 1. > > - At least an Acked-by from anyone that works on Gallium for patch 4. > > - A Tested-by from Vinson on patch 7. Ideally, we'd get him to try > building the whole series on a few of the odd configurations he has to > deal with. > Kristian, Vinson Gents, can you please spare a couple of minutes to check the above in the upcoming week ? Thanks Emil >> Cheers >> Emil >> ___ >> 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 00/16] DRI*extension cleanups v3
Previous email for Vinson bounced back. Adding alternative email. On 20/04/14 22:40, Emil Velikov wrote: > On 04/04/14 23:41, Ian Romanick wrote: >> On 03/16/2014 06:48 AM, Emil Velikov wrote: >>> Hi all, >>> >>> Here is the third iteration of some DRI*extension cleanup patches. >>> >>> This revision adds some minor updates and squashes the patches into >>> a shorter patchset. >>> >>> The previous revision can be found at >>> http://lists.freedesktop.org/archives/mesa-dev/2014-February/054327.html >>> >>> For people interested in testing/pulling the patches, they can be found >>> at https://github.com/evelikov/Mesa dri-extension-cleanup-v3 >>> >>> Comments and review are grately appreciated. >> >> The series is >> >> Reviewed-by: Ian Romanick >> > Thanks for the review Ian. > >> However, before these patches get pushed, I'd like to see: >> >> - At least an Acked-by from Kristian on patch 1. >> >> - At least an Acked-by from anyone that works on Gallium for patch 4. >> >> - A Tested-by from Vinson on patch 7. Ideally, we'd get him to try >> building the whole series on a few of the odd configurations he has to >> deal with. >> > Kristian, Vinson > > Gents, can you please spare a couple of minutes to check the above in the > upcoming week ? > > Thanks > Emil > >>> Cheers >>> Emil >>> ___ >>> 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 11/19] glsl: Track explicitly set location independent from the actual location
Ian Romanick writes: > On 04/11/2014 04:35 PM, Eric Anholt wrote: >> Ian Romanick writes: >> >>> From: Ian Romanick >>> >>> Almost all of the time the location set by layout(location=...) is the >>> location that will be used for the variable. Vertex shader inputs and >>> fragment shader outputs, for example, are visible to the API. We just >>> use those actual settings. >>> >>> Locations set for varyings, however, are a different story. In those >>> cases, the locations set in the shader are just used to facilitate >>> matching outputs to inputs. We need to track the value so that we can >>> ensure that >>> >>>layout(location=2) out float foo; >>> >>> will be assigned the same resource as >>> >>>layout(location=2) in float bar; >>> >>> but we probably don't want to use 2 as the actual location in the set of >>> varyings. >> >> I assumed that layout(location=2) would be using VARYING_SLOT_VARx -- I >> don't know of any reason to try and pack these, and it sucks to see >> another field in our already-bloated ir_variables. It looks like other >> code in the series would go away if we just mapped things directly to >> VARYING_SLOTs. > > I started off with that approach, and I encountered a couple problems. > Since you can have a mix of varyings with and without explicit > locations, it made the code for resetting the locations during link more > complex. I recall thinking that the changes should have been simple and > obvious, but they weren't. It was a few months ago at this point, so I > don't recall the details. > > The other problem was that the i965 backend makes assumptions about > there not being holes in the set of varyings used. When shaders ended > up using, say, VARYING_SLOT_VAR0 and VARYING_SLOT_VAR1 (but not > VARYING_SLOT_VAR2), I started hitting assertions in the backend. It > seemed easier and less obtrusive to have the frontend continue giving > the backend shaders that matched its assumptions. There shouldn't be anything requiring that varying slots used be contiguous. For example, someone could use gl_TexCoord[0] and gl_TexCoord[2] today, and there should be an open slot between the two. pgpb3nc6larjo.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/6] i965/fs: Recognize nop-MOV instructions early.
Matt Turner writes:
> And avoid rewriting other instructions unnecessarily. Removes a few
> self-moves we weren't able to handle because they were components of a
> large VGRF.
>
> instructions in affected programs: 830 -> 826 (-0.48%)
> ---
> src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> index f6d9b68..8b37ed0 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> @@ -44,6 +44,12 @@
> #include "brw_fs_live_variables.h"
>
> static bool
> +is_nop_mov(const fs_inst *inst)
> +{
> + return inst->dst.equals(inst->src[0]);
> +}
I don't think it would be a nop mov if:
inst->saturate
inst->conditional_mod != BRW_CONDITIONAL_NONE
Agreed on that this function should only return true if it's actually a
MOV.
pgpLJc8slV76T.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] egl: Add GetSyncValuesCHROMIUM extension.
On Fri, Apr 18, 2014 at 5:30 PM, Ian Romanick wrote: > On 04/18/2014 05:07 PM, Jamey Sharp wrote: >> if you're using Xlib, then by default it will be abort()ing your >> client as soon as it pulls the error out of the event queue. > > Unless the client has an error handler, right? Well, sure, the usual horrid Xlib error handling rules apply: Mesa could install an async_handler to filter its errors, and the application could call XSetErrorHandler. But the former seems silly when you already had to check for a null reply pointer, and requiring callers to both set an X error handler and check the return values from their libGL calls seems silly too. Now that you've had a refresher after three years, does this make more sense? :-) Jamey ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] [RFC] include/pipe: all major Linux libc support endian.h
I'd like to ask, if anyone else looked at this really simple patch and/or tested it? Thank you Dne 2014-03-14 19:57, David Heidelberger napsal: --- src/gallium/include/pipe/p_config.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/include/pipe/p_config.h b/src/gallium/include/pipe/p_config.h index d603681..cd6f560 100644 --- a/src/gallium/include/pipe/p_config.h +++ b/src/gallium/include/pipe/p_config.h @@ -130,7 +130,7 @@ * Endian detection. */ -#ifdef __GLIBC__ +#if defined(PIPE_OS_LINUX) || defined(__GLIBC__) #include #if __BYTE_ORDER == __LITTLE_ENDIAN ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/13] r600g: fix MSAA resolve on R6xx when the destination is 1D-tiled
From: Marek Olšák
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeon/r600_texture.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index c410543..55caece 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -289,6 +289,12 @@ void r600_texture_get_fmask_info(struct r600_common_screen
*rscreen,
fmask.nsamples = 1;
fmask.flags |= RADEON_SURF_FMASK;
+ /* Force 2D tiling if it wasn't set. This may occur when creating
+* FMASK for MSAA resolve on R6xx. On R6xx, the single-sample
+* destination buffer must have an FMASK too. */
+ fmask.flags = RADEON_SURF_CLR(fmask.flags, MODE);
+ fmask.flags |= RADEON_SURF_SET(RADEON_SURF_MODE_2D, MODE);
+
if (rscreen->chip_class >= SI) {
fmask.flags |= RADEON_SURF_HAS_TILE_MODE_INDEX;
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/13] radeonsi: implement GL_ARB_vertex_type_10f_11f_11f_rev
From: Marek Olšák
---
docs/GL3.txt| 2 +-
docs/relnotes/10.2.html | 1 +
src/gallium/drivers/radeonsi/si_state.c | 6 ++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 0b663dd..b8557bf 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -188,7 +188,7 @@ GL 4.4:
GL_ARB_query_buffer_object not started
GL_ARB_texture_mirror_clamp_to_edge DONE (i965, nv30, nv50,
nvc0, r300, r600, radeonsi, swrast)
GL_ARB_texture_stencil8 not started
- GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, nv50, nvc0,
r600)
+ GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, nv50, nvc0,
r600, radeonsi)
More info about these features and the work involved can be found at
diff --git a/docs/relnotes/10.2.html b/docs/relnotes/10.2.html
index d7d557b..3eedf89 100644
--- a/docs/relnotes/10.2.html
+++ b/docs/relnotes/10.2.html
@@ -47,6 +47,7 @@ Note: some of the new features are only available with
certain drivers.
GL_ARB_buffer_storage on i965, r300, r600, and radeonsi
GL_ARB_stencil_texturing on i965/gen8+
GL_ARB_texture_view on i965/gen7
+GL_ARB_vertex_type_10f_11f_11f_rev on radeonsi
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index ab9c4cc..5e37e5d 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1328,6 +1328,9 @@ static uint32_t si_translate_buffer_dataformat(struct
pipe_screen *screen,
if (type == UTIL_FORMAT_TYPE_FIXED)
return V_008F0C_BUF_DATA_FORMAT_INVALID;
+ if (desc->format == PIPE_FORMAT_R11G11B10_FLOAT)
+ return V_008F0C_BUF_DATA_FORMAT_10_11_11;
+
if (desc->nr_channels == 4 &&
desc->channel[0].size == 10 &&
desc->channel[1].size == 10 &&
@@ -1393,6 +1396,9 @@ static uint32_t si_translate_buffer_numformat(struct
pipe_screen *screen,
const struct
util_format_description *desc,
int first_non_void)
{
+ if (desc->format == PIPE_FORMAT_R11G11B10_FLOAT)
+ return V_008F0C_BUF_NUM_FORMAT_FLOAT;
+
switch (desc->channel[first_non_void].type) {
case UTIL_FORMAT_TYPE_SIGNED:
if (desc->channel[first_non_void].normalized)
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/13] r300g: don't crash when getting NULL colorbuffers
From: Marek Olšák
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r300/r300_blit.c| 4 +--
src/gallium/drivers/r300/r300_context.h | 14 ++
src/gallium/drivers/r300/r300_emit.c| 25 +++---
src/gallium/drivers/r300/r300_state.c | 46 -
4 files changed, 60 insertions(+), 29 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_blit.c
b/src/gallium/drivers/r300/r300_blit.c
index cc9ea8a..05e55f3 100644
--- a/src/gallium/drivers/r300/r300_blit.c
+++ b/src/gallium/drivers/r300/r300_blit.c
@@ -130,7 +130,7 @@ static boolean r300_cbzb_clear_allowed(struct r300_context
*r300,
(struct pipe_framebuffer_state*)r300->fb_state.state;
/* Only color clear allowed, and only one colorbuffer. */
-if ((clear_buffers & ~PIPE_CLEAR_COLOR) != 0 || fb->nr_cbufs != 1)
+if ((clear_buffers & ~PIPE_CLEAR_COLOR) != 0 || fb->nr_cbufs != 1 ||
!fb->cbufs[0])
return FALSE;
return r300_surface(fb->cbufs[0])->cbzb_allowed;
@@ -313,7 +313,7 @@ static void r300_clear(struct pipe_context* pipe,
/* Use fast color clear for an AA colorbuffer.
* The CMASK is shared between all colorbuffers, so we use it
* if there is only one colorbuffer bound. */
-if ((buffers & PIPE_CLEAR_COLOR) && fb->nr_cbufs == 1 &&
+if ((buffers & PIPE_CLEAR_COLOR) && fb->nr_cbufs == 1 && fb->cbufs[0] &&
r300_resource(fb->cbufs[0]->texture)->tex.cmask_dwords) {
/* Try to obtain the access to the CMASK if we don't have one. */
if (!r300->cmask_access) {
diff --git a/src/gallium/drivers/r300/r300_context.h
b/src/gallium/drivers/r300/r300_context.h
index e6b0181..8736cc7 100644
--- a/src/gallium/drivers/r300/r300_context.h
+++ b/src/gallium/drivers/r300/r300_context.h
@@ -688,6 +688,20 @@ static INLINE void r300_mark_atom_dirty(struct
r300_context *r300,
}
}
+static INLINE struct pipe_surface *
+r300_get_nonnull_cb(struct pipe_framebuffer_state *fb, unsigned i)
+{
+if (fb->cbufs[i])
+return fb->cbufs[i];
+
+/* The i-th framebuffer is NULL, return any non-NULL one. */
+for (i = 0; i < fb->nr_cbufs; i++)
+if (fb->cbufs[i])
+return fb->cbufs[i];
+
+return NULL;
+}
+
struct pipe_context* r300_create_context(struct pipe_screen* screen,
void *priv);
diff --git a/src/gallium/drivers/r300/r300_emit.c
b/src/gallium/drivers/r300/r300_emit.c
index 9f16413..b201334 100644
--- a/src/gallium/drivers/r300/r300_emit.c
+++ b/src/gallium/drivers/r300/r300_emit.c
@@ -42,15 +42,18 @@ void r300_emit_blend_state(struct r300_context* r300,
struct r300_blend_state* blend = (struct r300_blend_state*)state;
struct pipe_framebuffer_state* fb =
(struct pipe_framebuffer_state*)r300->fb_state.state;
+struct pipe_surface *cb;
CS_LOCALS(r300);
-if (fb->nr_cbufs) {
-if (fb->cbufs[0]->format == PIPE_FORMAT_R16G16B16A16_FLOAT) {
+cb = fb->nr_cbufs ? r300_get_nonnull_cb(fb, 0) : NULL;
+
+if (cb) {
+if (cb->format == PIPE_FORMAT_R16G16B16A16_FLOAT) {
WRITE_CS_TABLE(blend->cb_noclamp, size);
-} else if (fb->cbufs[0]->format == PIPE_FORMAT_R16G16B16X16_FLOAT) {
+} else if (cb->format == PIPE_FORMAT_R16G16B16X16_FLOAT) {
WRITE_CS_TABLE(blend->cb_noclamp_noalpha, size);
} else {
-unsigned swz = r300_surface(fb->cbufs[0])->colormask_swizzle;
+unsigned swz = r300_surface(cb)->colormask_swizzle;
WRITE_CS_TABLE(blend->cb_clamp[swz], size);
}
} else {
@@ -88,9 +91,11 @@ void r300_emit_dsa_state(struct r300_context* r300, unsigned
size, void* state)
/* Choose the alpha ref value between 8-bit (FG_ALPHA_FUNC.AM_VAL) and
* 16-bit (FG_ALPHA_VALUE). */
if (is_r500 && (alpha_func & R300_FG_ALPHA_FUNC_ENABLE)) {
-if (fb->nr_cbufs &&
-(fb->cbufs[0]->format == PIPE_FORMAT_R16G16B16A16_FLOAT ||
- fb->cbufs[0]->format == PIPE_FORMAT_R16G16B16X16_FLOAT)) {
+struct pipe_surface *cb = fb->nr_cbufs ? r300_get_nonnull_cb(fb, 0) :
NULL;
+
+if (cb &&
+(cb->format == PIPE_FORMAT_R16G16B16A16_FLOAT ||
+ cb->format == PIPE_FORMAT_R16G16B16X16_FLOAT)) {
alpha_func |= R500_FG_ALPHA_FUNC_FP16_ENABLE;
} else {
alpha_func |= R500_FG_ALPHA_FUNC_8BIT;
@@ -419,7 +424,7 @@ void r300_emit_fb_state(struct r300_context* r300, unsigned
size, void* state)
/* Set up colorbuffers. */
for (i = 0; i < fb->nr_cbufs; i++) {
-surf = r300_surface(fb->cbufs[i]);
+surf = r300_surface(r300_get_nonnull_cb(fb, i));
OUT_CS_REG(R300_RB3D_COLOROFFSET0 + (4 * i), surf->offset);
OUT_CS_RELOC(surf);
@@ -600,7 +605,7 @@ void r300_emit_fb_state_pipelined(struct r300_context *r300,
* (must be written after unpipelined regs) */
OUT_CS_REG_SEQ(R300_US_OUT_FMT_0, 4);
[Mesa-dev] [PATCH 00/13] Radeon - various fixes
I decided to test all graphics cards I own, and I have come up with this set of fixes (except the first patch, which is a new feature). Most importantly, DOTA 2 finally works without glitches on R600 and R700. Some of the fixes are untested, because I don't have the GPUs (RV770, RV740). Marek Olšák (13): radeonsi: implement GL_ARB_vertex_type_10f_11f_11f_rev r300g: fix runtime warning after winsys cleanup r300g: don't crash when getting NULL colorbuffers st/mesa: remove trailing NULL colorbuffers r600g: fix edge flags and layered rendering on R600-R700 r600g: disable async DMA on R700 r600g: fix MSAA resolve on R6xx when the destination is 1D-tiled r600g: fix flushing on RV670, RS780, RS880 again r600g: fix buffer copying on R600-R700 r600g: fix for HTILE on R6xx r600g: fix for broken CULL_FRONT behavior on R6xx r600g: fix for an MSAA hang on RV770 r600g: fix hang on RV740 by using DX_RASTERIZATION_KILL instead of SX_MISC Known serious bugs the series doesn't fix: - Geometry shaders immediately hang on RV670. There is a documented workaround in the open docs. - Geometry shaders are unstable on RV730 (probably other R700 GPUs too), e.g. see the failing texelFetch gs tests. - The SB (shader backend) crashes with a few piglit tests on Cayman, in particular: spec/glsl-1.50/execution/geometry/primitive-id-restart *. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/13] r300g: fix runtime warning after winsys cleanup
From: Marek Olšák Broken by: b2238b3452b0bcf3c1216c20c9918f9f0664b464 winsys/radeon: remove cs_write_reloc, add simpler cs_get_reloc --- src/gallium/drivers/r300/r300_cs.h | 1 - 1 file changed, 1 deletion(-) diff --git a/src/gallium/drivers/r300/r300_cs.h b/src/gallium/drivers/r300/r300_cs.h index 748d6ea..37f9641 100644 --- a/src/gallium/drivers/r300/r300_cs.h +++ b/src/gallium/drivers/r300/r300_cs.h @@ -111,7 +111,6 @@ assert((r)->cs_buf); \ OUT_CS(0xc0001000); /* PKT3_NOP */ \ OUT_CS(cs_winsys->cs_get_reloc(cs_copy, (r)->cs_buf) * 4); \ -CS_USED_DW(2); \ } while (0) -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/13] r600g: fix for an MSAA hang on RV770
From: Marek Olšák
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/evergreen_state.c | 5 -
src/gallium/drivers/r600/r600_state.c | 5 +
src/gallium/drivers/r600/r600d.h | 3 +++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index fc54ae7..6f27790 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1381,7 +1381,10 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
}
log_samples = util_logbase2(rctx->framebuffer.nr_samples);
- if (rctx->b.chip_class == CAYMAN && rctx->db_misc_state.log_samples !=
log_samples) {
+ /* This is for Cayman to program SAMPLE_RATE, and for RV770 to fix a hw
bug. */
+ if ((rctx->b.chip_class == CAYMAN ||
+rctx->b.family == CHIP_RV770) &&
+ rctx->db_misc_state.log_samples != log_samples) {
rctx->db_misc_state.log_samples = log_samples;
rctx->db_misc_state.atom.dirty = true;
}
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index 99cfe6f..ffcceac 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -1615,6 +1615,11 @@ static void r600_emit_db_misc_state(struct r600_context
*rctx, struct r600_atom
db_render_control |= S_028D0C_DEPTH_CLEAR_ENABLE(1);
}
+ /* RV770 workaround for a hang with 8x MSAA. */
+ if (rctx->b.family == CHIP_RV770 && a->log_samples == 3) {
+ db_render_override |= S_028D10_MAX_TILES_IN_DTT(6);
+ }
+
r600_write_context_reg_seq(cs, R_028D0C_DB_RENDER_CONTROL, 2);
radeon_emit(cs, db_render_control); /* R_028D0C_DB_RENDER_CONTROL */
radeon_emit(cs, db_render_override); /* R_028D10_DB_RENDER_OVERRIDE */
diff --git a/src/gallium/drivers/r600/r600d.h b/src/gallium/drivers/r600/r600d.h
index f787803..1684429 100644
--- a/src/gallium/drivers/r600/r600d.h
+++ b/src/gallium/drivers/r600/r600d.h
@@ -818,6 +818,9 @@
#define S_028D10_IGNORE_SC_ZRANGE(x) (((x) & 0x1) << 17)
#define G_028D10_IGNORE_SC_ZRANGE(x) (((x) >> 17) & 0x1)
#define C_028D10_IGNORE_SC_ZRANGE0xFFFD
+#define S_028D10_MAX_TILES_IN_DTT(x) (((x) & 0x1F) << 21)
+#define G_028D10_MAX_TILES_IN_DTT(x) (((x) >> 21) & 0x1F)
+#define C_028D10_MAX_TILES_IN_DTT0xFC1F
#define R_02880C_DB_SHADER_CONTROL0x02880C
#define S_02880C_Z_EXPORT_ENABLE(x) (((x) & 0x1) << 0)
#define G_02880C_Z_EXPORT_ENABLE(x) (((x) >> 0) & 0x1)
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/13] r600g: fix flushing on RV670, RS780, RS880 again
From: Marek Olšák
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/r600_hw_context.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 5ecc73d..0aa7f45 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -210,6 +210,15 @@ void r600_flush_emit(struct r600_context *rctx)
S_0085F0_SMX_ACTION_ENA(1);
}
+ /* Workaround for buggy flushing on some R6xx chipsets. */
+ if (rctx->b.flags & R600_CONTEXT_FLUSH_AND_INV &&
+ (rctx->b.family == CHIP_RV670 ||
+rctx->b.family == CHIP_RS780 ||
+rctx->b.family == CHIP_RS880)) {
+ cp_coher_cntl |= S_0085F0_CB1_DEST_BASE_ENA(1) |
+ S_0085F0_DEST_BASE_0_ENA(1);
+ }
+
if (cp_coher_cntl) {
cs->buf[cs->cdw++] = PKT3(PKT3_SURFACE_SYNC, 3, 0);
cs->buf[cs->cdw++] = cp_coher_cntl; /* CP_COHER_CNTL */
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/13] r600g: fix buffer copying on R600-R700
From: Marek Olšák
This fixes broken rendering in DOTA 2.
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/r600_blit.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index 98c07b5..1a2a911 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -500,6 +500,12 @@ static void r600_copy_buffer(struct pipe_context *ctx,
struct pipe_resource *dst
} else {
util_resource_copy_region(ctx, dst, 0, dstx, 0, 0, src, 0,
src_box);
}
+
+ /* The index buffer (VGT) doesn't seem to see the result of the copying.
+* Can we somehow flush the index buffer cache? Starting a new IB seems
+* to do the trick. */
+ if (rctx->b.chip_class <= R700)
+ rctx->b.rings.gfx.flush(ctx, RADEON_FLUSH_ASYNC, NULL);
}
/**
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/13] st/mesa: remove trailing NULL colorbuffers
From: Marek Olšák
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_framebuffer.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c
b/src/mesa/state_tracker/st_atom_framebuffer.c
index 4c4f839..09e0d85 100644
--- a/src/mesa/state_tracker/st_atom_framebuffer.c
+++ b/src/mesa/state_tracker/st_atom_framebuffer.c
@@ -90,6 +90,12 @@ update_framebuffer_state( struct st_context *st )
pipe_surface_reference(&framebuffer->cbufs[i], NULL);
}
+ /* Remove trailing GL_NONE draw buffers. */
+ while (framebuffer->nr_cbufs &&
+ !framebuffer->cbufs[framebuffer->nr_cbufs-1]) {
+ framebuffer->nr_cbufs--;
+ }
+
/*
* Depth/Stencil renderbuffer/surface.
*/
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/13] r600g: fix edge flags and layered rendering on R600-R700
From: Marek Olšák We forgot to set these bits. Cc: 10.1 mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/r600/r600_state.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/r600/r600_state.c b/src/gallium/drivers/r600/r600_state.c index 8053ff4..99206cf 100644 --- a/src/gallium/drivers/r600/r600_state.c +++ b/src/gallium/drivers/r600/r600_state.c @@ -2568,8 +2568,10 @@ void r600_update_vs_state(struct pipe_context *ctx, struct r600_pipe_shader *sha S_02881C_VS_OUT_CCDIST0_VEC_ENA((rshader->clip_dist_write & 0x0F) != 0) | S_02881C_VS_OUT_CCDIST1_VEC_ENA((rshader->clip_dist_write & 0xF0) != 0) | S_02881C_VS_OUT_MISC_VEC_ENA(rshader->vs_out_misc_write) | - S_02881C_USE_VTX_VIEWPORT_INDX(rshader->vs_out_viewport) | - S_02881C_USE_VTX_POINT_SIZE(rshader->vs_out_point_size); + S_02881C_USE_VTX_POINT_SIZE(rshader->vs_out_point_size) | + S_02881C_USE_VTX_EDGE_FLAG(rshader->vs_out_edgeflag) | + S_02881C_USE_VTX_RENDER_TARGET_INDX(rshader->vs_out_layer) | + S_02881C_USE_VTX_VIEWPORT_INDX(rshader->vs_out_viewport); } static unsigned r600_conv_prim_to_gs_out(unsigned mode) -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/13] r600g: disable async DMA on R700
From: Marek Olšák
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 0eb0c6a..b53beba 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -282,7 +282,8 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws)
/* Check for dma */
ws->info.r600_has_dma = FALSE;
-if (ws->info.chip_class >= R700 && ws->info.drm_minor >= 27) {
+/* DMA is disabled on R700. There is IB corruption and hangs. */
+if (ws->info.chip_class >= EVERGREEN && ws->info.drm_minor >= 27) {
ws->info.r600_has_dma = TRUE;
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/13] r600g: fix for HTILE on R6xx
From: Marek Olšák --- src/gallium/drivers/radeon/r600_texture.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/gallium/drivers/radeon/r600_texture.c b/src/gallium/drivers/radeon/r600_texture.c index 55caece..e30d933 100644 --- a/src/gallium/drivers/radeon/r600_texture.c +++ b/src/gallium/drivers/radeon/r600_texture.c @@ -542,6 +542,12 @@ static unsigned r600_texture_htile_alloc_size(struct r600_common_screen *rscreen return 0; } + /* HW bug on R6xx. */ + if (rscreen->chip_class == R600 && + (rtex->surface.level[0].npix_x > 7680 || +rtex->surface.level[0].npix_y > 7680)) + return 0; + /* this alignment and htile size only apply to linear htile buffer */ sw = align(sw, 16 << 3); sh = align(sh, npipes << 3); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/13] r600g: fix for broken CULL_FRONT behavior on R6xx
From: Marek Olšák
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/evergreen_state.c | 24 -
src/gallium/drivers/r600/r600_pipe.h | 31 -
src/gallium/drivers/r600/r600_state.c| 51
src/gallium/drivers/r600/r600_state_common.c | 19 +++
4 files changed, 64 insertions(+), 61 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 50d959e..fc54ae7 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2987,30 +2987,6 @@ void evergreen_update_es_state(struct pipe_context *ctx,
struct r600_pipe_shader
/* After that, the NOP relocation packet must be emitted (shader->bo,
RADEON_USAGE_READ). */
}
-static unsigned r600_conv_prim_to_gs_out(unsigned mode)
-{
- static const int prim_conv[] = {
- V_028A6C_OUTPRIM_TYPE_POINTLIST,
- V_028A6C_OUTPRIM_TYPE_LINESTRIP,
- V_028A6C_OUTPRIM_TYPE_LINESTRIP,
- V_028A6C_OUTPRIM_TYPE_LINESTRIP,
- V_028A6C_OUTPRIM_TYPE_TRISTRIP,
- V_028A6C_OUTPRIM_TYPE_TRISTRIP,
- V_028A6C_OUTPRIM_TYPE_TRISTRIP,
- V_028A6C_OUTPRIM_TYPE_TRISTRIP,
- V_028A6C_OUTPRIM_TYPE_TRISTRIP,
- V_028A6C_OUTPRIM_TYPE_TRISTRIP,
- V_028A6C_OUTPRIM_TYPE_LINESTRIP,
- V_028A6C_OUTPRIM_TYPE_LINESTRIP,
- V_028A6C_OUTPRIM_TYPE_TRISTRIP,
- V_028A6C_OUTPRIM_TYPE_TRISTRIP,
- V_028A6C_OUTPRIM_TYPE_TRISTRIP
- };
- assert(mode < Elements(prim_conv));
-
- return prim_conv[mode];
-}
-
void evergreen_update_gs_state(struct pipe_context *ctx, struct
r600_pipe_shader *shader)
{
struct r600_context *rctx = (struct r600_context *)ctx;
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index f31fa45a..952b6bd 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -41,7 +41,7 @@
/* the number of CS dwords for flushing and drawing */
#define R600_MAX_FLUSH_CS_DWORDS 16
-#define R600_MAX_DRAW_CS_DWORDS34
+#define R600_MAX_DRAW_CS_DWORDS37
#define R600_TRACE_CS_DWORDS 7
#define R600_MAX_USER_CONST_BUFFERS 13
@@ -234,6 +234,7 @@ struct r600_rasterizer_state {
unsignedclip_plane_enable;
unsignedpa_sc_line_stipple;
unsignedpa_cl_clip_cntl;
+ unsignedpa_su_sc_mode_cntl;
float offset_units;
float offset_scale;
booloffset_enable;
@@ -852,4 +853,32 @@ static INLINE bool r600_can_read_depth(struct r600_texture
*rtex)
rtex->resource.b.b.format == PIPE_FORMAT_Z32_FLOAT);
}
+#define V_028A6C_OUTPRIM_TYPE_POINTLIST0
+#define V_028A6C_OUTPRIM_TYPE_LINESTRIP1
+#define V_028A6C_OUTPRIM_TYPE_TRISTRIP 2
+
+static INLINE unsigned r600_conv_prim_to_gs_out(unsigned mode)
+{
+ static const int prim_conv[] = {
+ V_028A6C_OUTPRIM_TYPE_POINTLIST,
+ V_028A6C_OUTPRIM_TYPE_LINESTRIP,
+ V_028A6C_OUTPRIM_TYPE_LINESTRIP,
+ V_028A6C_OUTPRIM_TYPE_LINESTRIP,
+ V_028A6C_OUTPRIM_TYPE_TRISTRIP,
+ V_028A6C_OUTPRIM_TYPE_TRISTRIP,
+ V_028A6C_OUTPRIM_TYPE_TRISTRIP,
+ V_028A6C_OUTPRIM_TYPE_TRISTRIP,
+ V_028A6C_OUTPRIM_TYPE_TRISTRIP,
+ V_028A6C_OUTPRIM_TYPE_TRISTRIP,
+ V_028A6C_OUTPRIM_TYPE_LINESTRIP,
+ V_028A6C_OUTPRIM_TYPE_LINESTRIP,
+ V_028A6C_OUTPRIM_TYPE_TRISTRIP,
+ V_028A6C_OUTPRIM_TYPE_TRISTRIP,
+ V_028A6C_OUTPRIM_TYPE_TRISTRIP
+ };
+ assert(mode < Elements(prim_conv));
+
+ return prim_conv[mode];
+}
+
#endif
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index 99206cf..99cfe6f 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -517,18 +517,21 @@ static void *r600_create_rs_state(struct pipe_context
*ctx,
S_028C08_PIX_CENTER_HALF(state->half_pixel_center) |
S_028C08_QUANT_MODE(V_028C08_X_1_256TH));
r600_store_context_reg(&rs->buffer, R_028DFC_PA_SU_POLY_OFFSET_CLAMP,
fui(state->offset_clamp));
- r600_store_context_reg(&rs->buffer, R_028814_PA_SU_SC_MODE_CNTL,
-
S_028814_PROVOKING_VTX_LAST(!state->flatshade_first) |
- S_028814_CULL_FRONT(state->cull_face &
PIPE_FACE_FRONT ? 1 : 0) |
- S_028
[Mesa-dev] [PATCH 13/13] r600g: fix hang on RV740 by using DX_RASTERIZATION_KILL instead of SX_MISC
From: Marek Olšák
Changing SX_MISC hangs RV740. When we're at it, let's use DX_RASTERIZATION_KILL
on all R700 and later chipsets.
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/evergreen_state.c | 12
src/gallium/drivers/r600/evergreend.h | 3 +++
src/gallium/drivers/r600/r600_hw_context.c | 4 ++--
src/gallium/drivers/r600/r600_state.c | 12 +++-
src/gallium/drivers/r600/r600d.h | 3 +++
5 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 6f27790..f7a63a8 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -474,7 +474,8 @@ static void *evergreen_create_rs_state(struct pipe_context
*ctx,
S_028810_PS_UCP_MODE(3) |
S_028810_ZCLIP_NEAR_DISABLE(!state->depth_clip) |
S_028810_ZCLIP_FAR_DISABLE(!state->depth_clip) |
- S_028810_DX_LINEAR_ATTR_CLIP_ENA(1);
+ S_028810_DX_LINEAR_ATTR_CLIP_ENA(1) |
+ S_028810_DX_RASTERIZATION_KILL(state->rasterizer_discard);
rs->multisample_enable = state->multisample;
/* offset */
@@ -543,7 +544,6 @@ static void *evergreen_create_rs_state(struct pipe_context
*ctx,
state->fill_back !=
PIPE_POLYGON_MODE_FILL) |
S_028814_POLYMODE_FRONT_PTYPE(r600_translate_fill(state->fill_front)) |
S_028814_POLYMODE_BACK_PTYPE(r600_translate_fill(state->fill_back)));
- r600_store_context_reg(&rs->buffer, R_028350_SX_MISC,
S_028350_MULTIPASS(state->rasterizer_discard));
return rs;
}
@@ -2195,7 +2195,9 @@ void cayman_init_common_regs(struct r600_command_buffer
*cb,
r600_store_context_reg(cb, R_028A4C_PA_SC_MODE_CNTL_1, 0);
- r600_store_context_reg(cb, R_028354_SX_SURFACE_SYNC,
S_028354_SURFACE_SYNC_MASK(0xf));
+ r600_store_context_reg_seq(cb, R_028350_SX_MISC, 2);
+ r600_store_value(cb, 0);
+ r600_store_value(cb, S_028354_SURFACE_SYNC_MASK(0xf));
r600_store_context_reg(cb, R_028800_DB_DEPTH_CONTROL, 0);
}
@@ -2472,7 +2474,9 @@ void evergreen_init_common_regs(struct
r600_command_buffer *cb,
/* The cs checker requires this register to be set. */
r600_store_context_reg(cb, R_028800_DB_DEPTH_CONTROL, 0);
- r600_store_context_reg(cb, R_028354_SX_SURFACE_SYNC,
S_028354_SURFACE_SYNC_MASK(0xf));
+ r600_store_context_reg_seq(cb, R_028350_SX_MISC, 2);
+ r600_store_value(cb, 0);
+ r600_store_value(cb, S_028354_SURFACE_SYNC_MASK(0xf));
return;
}
diff --git a/src/gallium/drivers/r600/evergreend.h
b/src/gallium/drivers/r600/evergreend.h
index 9fde184..a17aff3 100644
--- a/src/gallium/drivers/r600/evergreend.h
+++ b/src/gallium/drivers/r600/evergreend.h
@@ -582,6 +582,9 @@
#define S_028810_VTX_KILL_OR(x) (((x) & 0x1) << 21)
#define G_028810_VTX_KILL_OR(x) (((x) >> 21) & 0x1)
#define C_028810_VTX_KILL_OR 0xFFDF
+#define S_028810_DX_RASTERIZATION_KILL(x)(((x) & 0x1) << 22)
+#define G_028810_DX_RASTERIZATION_KILL(x)(((x) >> 22) & 0x1)
+#define C_028810_DX_RASTERIZATION_KILL 0xFFBF
#define S_028810_DX_LINEAR_ATTR_CLIP_ENA(x) (((x) & 0x1) << 24)
#define G_028810_DX_LINEAR_ATTR_CLIP_ENA(x) (((x) >> 24) & 0x1)
#define C_028810_DX_LINEAR_ATTR_CLIP_ENA 0xFEFF
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 0aa7f45..de6bcd7 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -81,7 +81,7 @@ void r600_need_cs_space(struct r600_context *ctx, unsigned
num_dw,
}
/* SX_MISC */
- if (ctx->b.chip_class <= R700) {
+ if (ctx->b.chip_class == R600) {
num_dw += 3;
}
@@ -264,7 +264,7 @@ void r600_context_gfx_flush(void *context, unsigned flags,
r600_flush_emit(ctx);
/* old kernels and userspace don't set SX_MISC, so we must reset it to
0 here */
- if (ctx->b.chip_class <= R700) {
+ if (ctx->b.chip_class == R600) {
r600_write_context_reg(cs, R_028350_SX_MISC, 0);
}
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index ffcceac..a0ba131 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -460,6 +460,10 @@ static void *r600_create_rs_state(struct pipe_context *ctx,
S_028810_ZCLIP_NEAR_DISABLE(!state->depth_clip) |
S_028810_ZCLIP_FAR_DISABLE(!state->depth_clip) |
S_028810_DX_LINEAR_ATTR_CLIP_ENA(1);
+ if (rctx->b.chip_class == R700) {
Re: [Mesa-dev] [PATCH 01/13] radeonsi: implement GL_ARB_vertex_type_10f_11f_11f_rev
On 21.04.2014 10:59, Marek Olšák wrote: > From: Marek Olšák Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix invalid pointer use in st_texture_get_sampler_view()
On 19.04.2014 03:35, Brian Paul wrote:
> The '**used' pointer was pointing into the stObj->sampler_views array.
> If 'free' was null, we'd realloc that array, thus making the 'used'
> pointer invalid. This soon led to memory errors.
>
> Just change the pointer to be '*used' so it points directly at the
> pipe_sampler_view.
> ---
> src/mesa/state_tracker/st_texture.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_texture.c
> b/src/mesa/state_tracker/st_texture.c
> index f664ef5..92035e8 100644
> --- a/src/mesa/state_tracker/st_texture.c
> +++ b/src/mesa/state_tracker/st_texture.c
> @@ -443,7 +443,7 @@ struct pipe_sampler_view **
> st_texture_get_sampler_view(struct st_context *st,
> struct st_texture_object *stObj)
> {
> - struct pipe_sampler_view **used = NULL, **free = NULL;
> + struct pipe_sampler_view *used = NULL, **free = NULL;
> GLuint i;
>
> for (i = 0; i < stObj->num_sampler_views; ++i) {
> @@ -455,7 +455,7 @@ st_texture_get_sampler_view(struct st_context *st,
> return sv;
>
> /* Wasn't the right one, but remember it as template */
> - used = sv;
> + used = *sv;
>} else {
> /* Found a free slot, remember that */
> free = sv;
> @@ -475,7 +475,7 @@ st_texture_get_sampler_view(struct st_context *st,
>
> /* Add just any sampler view to be used as a template */
> if (used)
> - pipe_sampler_view_reference(free, *used);
> + pipe_sampler_view_reference(free, used);
>
> return free;
> }
>
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Only allow `invariant` on shader in/out between stages.
Previously this was special-cased for VS and FS; it never got updated
when geometry shaders came along. Generalize using is_varying_var() so
this won't be broken again with tessellation.
Note that there are two copies of the logic for `invariant`: It can be
present as part of a new declaration, and also as a redeclaration of an
existing variable or block member.
Fixes the four new piglits:
specc/glsl-1.50/compiler/invariant-qualifier-*.geom
Signed-off-by: Chris Forbes
---
src/glsl/ast_to_hir.cpp | 34 +++---
1 file changed, 11 insertions(+), 23 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 35d58e9..e4f3f77 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3065,16 +3065,10 @@ ast_declarator_list::hir(exec_list *instructions,
_mesa_glsl_error(& loc, state,
"undeclared variable `%s' cannot be marked "
"invariant", decl->identifier);
- } else if ((state->stage == MESA_SHADER_VERTEX)
-&& (earlier->data.mode != ir_var_shader_out)) {
-_mesa_glsl_error(& loc, state,
- "`%s' cannot be marked invariant, vertex shader "
- "outputs only", decl->identifier);
- } else if ((state->stage == MESA_SHADER_FRAGMENT)
-&& (earlier->data.mode != ir_var_shader_in)) {
-_mesa_glsl_error(& loc, state,
- "`%s' cannot be marked invariant, fragment shader
"
- "inputs only", decl->identifier);
+ } else if (!is_varying_var(earlier, state->stage)) {
+_mesa_glsl_error(&loc, state,
+ "`%s' cannot be marked invariant; interfaces
between "
+ "shader stages only.", decl->identifier);
} else if (earlier->data.used) {
_mesa_glsl_error(& loc, state,
"variable `%s' may not be redeclared "
@@ -3250,19 +3244,13 @@ ast_declarator_list::hir(exec_list *instructions,
& loc, false);
if (this->type->qualifier.flags.q.invariant) {
- if ((state->stage == MESA_SHADER_VERTEX) &&
- var->data.mode != ir_var_shader_out) {
-_mesa_glsl_error(& loc, state,
- "`%s' cannot be marked invariant, vertex shader "
- "outputs only", var->name);
- } else if ((state->stage == MESA_SHADER_FRAGMENT) &&
-var->data.mode != ir_var_shader_in) {
-/* FINISHME: Note that this doesn't work for invariant on
- * a function signature inval
- */
-_mesa_glsl_error(& loc, state,
- "`%s' cannot be marked invariant, fragment shader
"
- "inputs only", var->name);
+ /* FINISHME: Note that this doesn't work for invariant on
+ * a function signature inval
+ */
+ if (!is_varying_var(var, state->stage)) {
+_mesa_glsl_error(&loc, state,
+ "`%s' cannot be marked invariant; interfaces
between "
+ "shader stages only", var->name);
}
}
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
