Re: [Mesa-dev] [PATCH 2/3] st/mesa: Finalize fbo texture attachments
Hello!
I don't know of an existing test or bug report about this issue.
The problem is that a texture is only finalized when bound to a texture unit
for rendering from. The texture generation code (st_TexImage) does not
necessarily create a pipe_resource for the texture (or attach the same pipe
resource to the texture object and all texture images in said texture
object).
For texture complete textures this can happen if gallium's texture generation
code thinks there will be no further mipmap levels when specifying the first
mipmap. Then it will only allocate enough memory for one mipmap and the next
call to st_TexImage will release the pipe resource from the texture object to
create a new one. Now the first mipmap has a different pipe resource than the
texture object.
The attached piglit patch tries to demonstrate this.
For texture incomplete textures this can also happen if one specifies
different texture images that are incompatible to one another for one texture
object. The texture images can't share a pipe resource and so only one of
them can use the same pipe resource as the texture object.
By the way: If one attaches two incompatible texture images from one texture
object gallium will still fail silently. I'll submit a patch to mark these
cases as fbo incomplete.
Fabian
On Tuesday 05 April 2011 02:56:51 Brian Paul wrote:
> On 04/02/2011 11:41 AM, Fabian Bieler wrote:
>
>
> Does this fix a specific bug or do you have a test program that
> demonstrates the issue? The patch looks OK on the surface but I'd
> like to know a bit more about what's going on.
>
> -Brian
From 4d9bea4a8d0065098cee89049dbac5e10b82db66 Mon Sep 17 00:00:00 2001
From: Fabian Bieler
Date: Tue, 5 Apr 2011 08:42:47 +0200
Subject: [PATCH] fbo-clear-formats: Add depth clearing
Also remove setting of texture min filter prior to clearing to confuse gallium's mipmap generation code
---
tests/fbo/fbo-clear-formats.c | 91 +++--
1 files changed, 87 insertions(+), 4 deletions(-)
diff --git a/tests/fbo/fbo-clear-formats.c b/tests/fbo/fbo-clear-formats.c
index 57c9162..84f1201 100644
--- a/tests/fbo/fbo-clear-formats.c
+++ b/tests/fbo/fbo-clear-formats.c
@@ -123,8 +123,67 @@ do_rgba_clear(GLenum format, GLuint tex, int level, int size)
static bool
do_depth_clear(GLenum format, GLuint tex, int level, int size)
{
- /* XXX: FINISHME */
- return false;
+ GLuint fb;
+ GLenum status;
+ int x;
+
+ glGenFramebuffersEXT(1, &fb);
+ glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb);
+
+ glDrawBuffer(GL_NONE);
+ glReadBuffer(GL_NONE);
+
+ glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
+ GL_DEPTH_ATTACHMENT_EXT,
+ GL_TEXTURE_2D,
+ tex,
+ level);
+
+ status = glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT);
+ if (status != GL_FRAMEBUFFER_COMPLETE_EXT) {
+ if (!level)
+ printf(" - FBO incomplete\n");
+ return false;
+ } else {
+ if (!level)
+ printf("\n");
+ }
+
+ glEnable(GL_SCISSOR_TEST);
+
+#if 1
+ for (x = 0; x < size; x++) {
+ float val = (x + 0.5) / (size);
+ glScissor(x, 0, 1, size);
+ glClearDepth(val);
+ glClear(GL_DEPTH_BUFFER_BIT);
+ }
+#else
+ glScissor(0, 0, size / 2, size / 2);
+ glClearDepth(0.0);
+ glClear(GL_DEPTH_BUFFER_BIT);
+
+ glScissor(size / 2, 0, size / 2, size / 2);
+ glClearDepth(0.25);
+ glClear(GL_DEPTH_BUFFER_BIT);
+
+ glScissor(0, size / 2, size / 2, size / 2);
+ glClearDepth(0.5);
+ glClear(GL_DEPTH_BUFFER_BIT);
+
+ glScissor(size / 2, size / 2, size / 2, size / 2);
+ glClearDepth(1.0);
+ glClear(GL_DEPTH_BUFFER_BIT);
+#endif
+
+ glDisable(GL_SCISSOR_TEST);
+
+ glDeleteFramebuffersEXT(1, &fb);
+
+ glDrawBuffer(GL_BACK);
+ glReadBuffer(GL_BACK);
+
+ return true;
}
static bool
@@ -150,8 +209,9 @@ create_tex(GLenum internalformat, GLenum baseformat)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER,
GL_LINEAR);
- glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
- GL_LINEAR_MIPMAP_NEAREST);
+ //confuse gallium's texture generation code
+ //glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
+ //GL_LINEAR_MIPMAP_NEAREST);
for (level = 0, dim = TEX_WIDTH; dim > 0; level++, dim /= 2) {
glTexImage2D(GL_TEXTURE_2D, level, internalformat,
@@ -240,12 +300,35 @@ test_mipmap_drawing(int x, int y, int dim, int level, GLuint internalformat)
GL_TEXTURE_BLUE_SIZE, &b_size);
if (d_size) {
+#if 1
for (x1 = x; x1 < x + dim; x1++) {
float val = (x1 - x + 0.5) / (dim);
float color[3] = {val, val, val};
pass = pass && piglit_probe_rect_rgb(x1, y, 1, dim,
color);
}
+#else
+ r[0] = 0.0;
+ r[1] = 0.0;
+ r[2] = 0.0;
+
+ g[0] = 0.25;
+ g[1] = 0.25;
+ g[2] = 0.25;
+
+ b[0] = 0.5;
+ b[1] = 0.5;
+ b[2] = 0.5;
+
+ w[0] = 1.0;
+ w[1] = 1.0;
+ w[2] = 1.0;
+
+ pass = pass && piglit_probe_rect_rgb(x1, y1, half, half, r);
+ pass = pass && piglit_probe_rect_rgb(x2, y1, half, half, g);
+ pass = pass && piglit_probe_rect_rgb(x1, y2, half, half, b);
+ pass = pass && piglit_probe_rect_rgb(x
[Mesa-dev] [Bug 35802] SIGSEGV in _mesa_AreProgramsResidentNV
https://bugs.freedesktop.org/show_bug.cgi?id=35802 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] prog_optimize: get_src_arg_mask() respect writemask for OPCODE_CMP
On 04/05/2011 12:20 AM, Tom Stellard wrote: --- src/mesa/program/prog_optimize.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/prog_optimize.c index 164297a..f62d890 100644 --- a/src/mesa/program/prog_optimize.c +++ b/src/mesa/program/prog_optimize.c @@ -74,6 +74,7 @@ get_src_arg_mask(const struct prog_instruction *inst, case OPCODE_MAD: case OPCODE_MUL: case OPCODE_SUB: + case OPCODE_CMP: channel_mask = inst->DstReg.WriteMask& dst_mask; break; case OPCODE_RCP: Looks OK to me. But it seems there's probably other opcodes missing from this group, like OPCODE_LRP/SGE/SLT etc. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] prog_optimize: Add simplify CMP optimization pass
On 04/05/2011 12:20 AM, Tom Stellard wrote: This pass removes conditions from conditional assignments when possible. This pass is useful for hardware that requires a lot of lowering passes that generate many CMP instructions. --- src/mesa/program/prog_optimize.c | 87 ++ 1 files changed, 87 insertions(+), 0 deletions(-) Looks OK to me, but Ian should probably take another look. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] st/mesa: Apply LOD bias from correct texture unit
On 03/30/2011 09:41 AM, Fabian Bieler wrote: I've applied patches 1 and 2. Thanks. Looks like there was still discussion about 3 and 4. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] st/mesa: Apply LOD bias from correct texture unit
On 5 April 2011 17:09, Brian Paul wrote: > Looks like there was still discussion about 3 and 4. > Yeah, but note that Fabian has posted a patch for llvmpipe in fd.o 33886, so provided that one is ok those patches could replace 3 and 4 in this series. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa: remove-driver-date GIT branch
On Mon, Apr 4, 2011 at 6:34 PM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/03/2011 02:15 PM, Sedat Dilek wrote: >> WOW! >> Just remembered my approach (witch patches and rants) to remove >> core-date and driver-date from kernel (drm-2.6) and libdrm as the >> version are simply unmaintained. >> Looks like I am not alone :-). > > There is also an e-mail thread[1] about these patches. Review comments > are welcome. > > [1] http://lists.freedesktop.org/archives/mesa-dev/2011-March/006321.html Hi Ian, first of all I am really glad that mesa gets rid of this unmaintained driver-date stuff. It is fooling users and helps to relax maintainers. I offered a patchset for kernel-drm and libdrm in January to remove DRM driver-date and core-date. Maybe, I do a take #2 after your work is accepted in mesa master GIT. I have tested your remove-driver-date GIT branch in mesa with a linux-next kernel (next-20110405 plus drm-fixes) on a Debian/sid i386 host with a radeon RV250 (see glxinfo output below). Libdrm is Debian's 2.4.24 and xserver Debian's 1.10.1-RC1 from experimental branch. $ cat /proc/version Linux version 2.6.39-rc1-next20110405.3-686-small (Debian 2.6.39~rc1-3~next20110405.dileks3) (sedat.di...@gmail.com) (gcc version 4.6.1 20110329 (prerelease) (Debian 4.6.0-2) ) #1 SMP Tue Apr 5 10:52:55 CEST 2011 $ git log --pretty=short -1 commit 00b28b10f4435e64a5fe37acae8c3da773e5bb8a Author: Ian Romanick mesa: Include GIT SHA1 in GL version string glxinfo now says: $ glxinfo | grep -i opengl Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 (RV250 4C66) x86/MMX/SSE2 TCL DRI2 OpenGL version string: 1.3 Mesa 7.11-devel (00b28b1) OpenGL extensions: For the version string: What about "git-$GITHASH" in parantheses? A sole number might say nothing to users? Be user-friendly as possible. Feel free to add a: Tested-by: Sedat Dilek - Sedat - ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] mesa-dev patches listed on ?
Hi, as patches to xorg-devel are already listed in [1], what about doing the same for patches sent to mesa-dev ML? Regards, - Sedat - [1] http://patchwork.freedesktop.org/project/Xorg/list/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GSoC : Video decoding state tracker for Gallium3d
★ Emeric wrote: > Hello again ! > Last call for comments, this is the GSoC proposal that I will submit, > probably tommorow. > > Thank you, > Emeric > > > > GSoC 2011 Proposal > Hardware Accelerated VP8 Video Decoding for Gallium3d > > Abstract === > The goal of this project is to write a Gallium3D state tracker capable > of hardware accelerated VP8 video decoding through the VDPAU API. This > would allow every graphic card with a Gallium3D driver (primary > targets are r300g, r600g and Nouveau drivers) to be able to decode VP8 > videos, and every VDPAU enabled multimedia software to play these > videos. > Hardware acceleration will be built upon graphic card’s shaders units, > able to take care of some heavy computations like motion compensation, > intra-predictions, IDCT, deblocking filter. > Hi, I thought vdpau was for nvidia only. Wouldn't it be more universal using vaapi ? Ce message a A(c)tA(c) analysA(c) par le relais de messagerie Arkoon de la sociA(c)tA(c) Logic'all et ne contient aucun virus connu. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa-dev patches listed on ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/2011 03:21 AM, Sedat Dilek wrote: > as patches to xorg-devel are already listed in [1], what about doing > the same for patches sent to mesa-dev ML? That's not a bad idea. I'm not that familiar with patchwork. Does it have tools for managing patches that are destined for stable releases (that are already in master)? I think that would be especially useful. My current system (combing messages to mesa-commit) doesn't scale very well. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2bXwUACgkQX1gOwKyEAw/kiQCdEJvNiPs4FsNa8RZlkemGXwQU qZgAnA5grh3gJG4Gx2vC09Wj/uyNacLZ =4qTK -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GSoC : Video decoding state tracker for Gallium3d
On Tue, Apr 5, 2011 at 1:25 PM, Emmanuel Andry wrote: > I thought vdpau was for nvidia only. > Wouldn't it be more universal using vaapi ? Sort of depends on your definition. A more important point raised on the Phoronix forums is that VAAPI supports encoding, while VDPAU does not. But I don't know, take it with a grain of salt. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: fix dstRowDiff computation in RGTC texstore functions
Copied from libtxc_dxtn, this fixes NPOT RGTC1 textures with r300g.
I also did the same for RGTC2.
---
src/mesa/main/texcompress_rgtc.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/texcompress_rgtc.c b/src/mesa/main/texcompress_rgtc.c
index c50df19..d9de9be 100644
--- a/src/mesa/main/texcompress_rgtc.c
+++ b/src/mesa/main/texcompress_rgtc.c
@@ -121,7 +121,7 @@ _mesa_texstore_red_rgtc1(TEXSTORE_PARAMS)
texWidth, (GLubyte *) dstAddr);
blkaddr = dst;
- dstRowDiff = dstRowStride >= (srcWidth * 4) ? dstRowStride - (((srcWidth +
3) & ~3) * 4) : 0;
+ dstRowDiff = dstRowStride >= (srcWidth * 2) ? dstRowStride - (((srcWidth +
3) & ~3) * 2) : 0;
for (j = 0; j < srcHeight; j+=4) {
if (srcHeight > j + 3) numypixels = 4;
else numypixels = srcHeight - j;
@@ -176,7 +176,7 @@ _mesa_texstore_signed_red_rgtc1(TEXSTORE_PARAMS)
texWidth, (GLubyte *)
dstAddr);
blkaddr = dst;
- dstRowDiff = dstRowStride >= (srcWidth * 4) ? dstRowStride - (((srcWidth +
3) & ~3) * 4) : 0;
+ dstRowDiff = dstRowStride >= (srcWidth * 2) ? dstRowStride - (((srcWidth +
3) & ~3) * 2) : 0;
for (j = 0; j < srcHeight; j+=4) {
if (srcHeight > j + 3) numypixels = 4;
else numypixels = srcHeight - j;
@@ -232,7 +232,7 @@ _mesa_texstore_rg_rgtc2(TEXSTORE_PARAMS)
texWidth, (GLubyte *) dstAddr);
blkaddr = dst;
- dstRowDiff = dstRowStride >= (srcWidth * 8) ? dstRowStride - (((srcWidth +
7) & ~7) * 8) : 0;
+ dstRowDiff = dstRowStride >= (srcWidth * 4) ? dstRowStride - (((srcWidth +
3) & ~3) * 4) : 0;
for (j = 0; j < srcHeight; j+=4) {
if (srcHeight > j + 3) numypixels = 4;
else numypixels = srcHeight - j;
@@ -294,7 +294,7 @@ _mesa_texstore_signed_rg_rgtc2(TEXSTORE_PARAMS)
texWidth, (GLubyte *)
dstAddr);
blkaddr = dst;
- dstRowDiff = dstRowStride >= (srcWidth * 8) ? dstRowStride - (((srcWidth +
7) & ~7) * 8) : 0;
+ dstRowDiff = dstRowStride >= (srcWidth * 4) ? dstRowStride - (((srcWidth +
3) & ~3) * 4) : 0;
for (j = 0; j < srcHeight; j += 4) {
if (srcHeight > j + 3) numypixels = 4;
else numypixels = srcHeight - j;
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] mesa-7.10.1-libdrm-required.patch
The patch below is needed to prevent building mesa with libdrm < 2.4.24. Regards, Alex diff --git a/configure.ac b/configure.ac index 6662b8a..ad9eb01 100644 --- a/configure.ac +++ b/configure.ac @@ -18,7 +18,7 @@ AC_CONFIG_AUX_DIR([bin]) AC_CANONICAL_HOST dnl Versions for external dependencies -LIBDRM_REQUIRED=2.4.15 +LIBDRM_REQUIRED=2.4.24 LIBDRM_RADEON_REQUIRED=2.4.17 DRI2PROTO_REQUIRED=2.1 GLPROTO_REQUIRED=1.4.11 -- Tactical Nuclear Kittens ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 35852] [bisected pineview] oglc case pxconv-read failed
https://bugs.freedesktop.org/show_bug.cgi?id=35852 Ian Romanick changed: What|Removed |Added Component|Drivers/DRI/i915|Mesa core AssignedTo|i...@freedesktop.org |mesa-dev@lists.freedesktop. ||org CC||i...@freedesktop.org --- Comment #5 from Ian Romanick 2011-04-05 19:11:35 PDT --- I'm changing the component to "Mesa core" because the conversions happen there. I suspect this same bug occurs with swrast. -- 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 35852] [bisected pineview] oglc case pxconv-read failed
https://bugs.freedesktop.org/show_bug.cgi?id=35852 Ian Romanick changed: What|Removed |Added AssignedTo|mesa-dev@lists.freedesktop. |mar...@gmail.com |org | -- 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] Mesa (master): i965: SNB GT1 has only 32k urb and max 128 urb entries.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/02/2011 06:31 PM, Nan hai Zou wrote:
> Module: Mesa
> Branch: master
> Commit: 118ecb1a2226494929a87c36b7802b64451ca004
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=118ecb1a2226494929a87c36b7802b64451ca004
>
> Author: Zou Nan hai
> Date: Thu Mar 3 10:30:06 2011 +0800
>
> i965: SNB GT1 has only 32k urb and max 128 urb entries.
>
> Signed-off-by: Zou Nan hai
>
> ---
>
> src/mesa/drivers/dri/i965/gen6_urb.c | 19 +++
> src/mesa/drivers/dri/intel/intel_chipset.h |4
> 2 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_urb.c
> b/src/mesa/drivers/dri/i965/gen6_urb.c
> index 57be50a..c3819f9 100644
> --- a/src/mesa/drivers/dri/i965/gen6_urb.c
> +++ b/src/mesa/drivers/dri/i965/gen6_urb.c
> @@ -34,15 +34,26 @@
> static void
> prepare_urb( struct brw_context *brw )
> {
> - brw->urb.nr_vs_entries = 256;
> - brw->urb.nr_gs_entries = 256;
> + int urb_size, max_urb_entry;
> + struct intel_context *intel = &brw->intel;
> +
> + if (IS_GT1(intel->intelScreen->deviceID)) {
> + urb_size = 32 * 1024;
> + max_urb_entry = 128;
> + } else {
> + urb_size = 64 * 1024;
> + max_urb_entry = 256;
> + }
> +
> + brw->urb.nr_vs_entries = max_urb_entry;
> + brw->urb.nr_gs_entries = max_urb_entry;
>
> /* CACHE_NEW_VS_PROG */
> brw->urb.vs_size = MAX2(brw->vs.prog_data->urb_entry_size, 1);
>
> - if (256 * brw->urb.vs_size > 64 * 1024)
> + if (2 * brw->urb.vs_size > urb_size)
Shouldn't this be:
if ((2 * brw->urb.vs_size * brw->urb.nr_vs_entries) > urb_size)
> brw->urb.nr_vs_entries = brw->urb.nr_gs_entries =
> - (64 * 1024 ) / brw->urb.vs_size;
> + (urb_size ) / (2 * brw->urb.vs_size);
> }
>
> static void
> diff --git a/src/mesa/drivers/dri/intel/intel_chipset.h
> b/src/mesa/drivers/dri/intel/intel_chipset.h
> index 4fecdbe..4ff9140 100644
> --- a/src/mesa/drivers/dri/intel/intel_chipset.h
> +++ b/src/mesa/drivers/dri/intel/intel_chipset.h
> @@ -133,6 +133,10 @@
>devid == PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS || \
>devid == PCI_CHIP_SANDYBRIDGE_S)
>
> +#define IS_GT1(devid)(devid == PCI_CHIP_SANDYBRIDGE_GT1 || \
> + devid == PCI_CHIP_SANDYBRIDGE_M_GT1 || \
> + devid == PCI_CHIP_SANDYBRIDGE_S)
> +
> #define IS_965(devid)(IS_GEN4(devid) || \
>IS_G4X(devid) || \
>IS_GEN5(devid) || \
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2b2KAACgkQX1gOwKyEAw/IjwCePSJRzTgEqn01U9xCXvd6zYbv
0jQAniOM0tnfCf7EHp3Rw/xBiFx6KbMu
=pBHg
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): i965: SNB GT1 has only 32k urb and max 128 urb entries.
>>-Original Message-
>>From: Ian Romanick [mailto:i...@freedesktop.org]
>>Sent: 2011年4月6日 11:06
>>To: mesa-dev@lists.freedesktop.org
>>Cc: Zou, Nanhai
>>Subject: Re: Mesa (master): i965: SNB GT1 has only 32k urb and max 128 urb
>>entries.
>>
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>On 03/02/2011 06:31 PM, Nan hai Zou wrote:
>>> Module: Mesa
>>> Branch: master
>>> Commit: 118ecb1a2226494929a87c36b7802b64451ca004
>>> URL:
>>http://cgit.freedesktop.org/mesa/mesa/commit/?id=118ecb1a2226494929a87c36b
>>7802b64451ca004
>>>
>>> Author: Zou Nan hai
>>> Date: Thu Mar 3 10:30:06 2011 +0800
>>>
>>> i965: SNB GT1 has only 32k urb and max 128 urb entries.
>>>
>>> Signed-off-by: Zou Nan hai
>>>
>>> ---
>>>
>>> src/mesa/drivers/dri/i965/gen6_urb.c | 19 +++
>>> src/mesa/drivers/dri/intel/intel_chipset.h |4
>>> 2 files changed, 19 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/gen6_urb.c
>>b/src/mesa/drivers/dri/i965/gen6_urb.c
>>> index 57be50a..c3819f9 100644
>>> --- a/src/mesa/drivers/dri/i965/gen6_urb.c
>>> +++ b/src/mesa/drivers/dri/i965/gen6_urb.c
>>> @@ -34,15 +34,26 @@
>>> static void
>>> prepare_urb( struct brw_context *brw )
>>> {
>>> - brw->urb.nr_vs_entries = 256;
>>> - brw->urb.nr_gs_entries = 256;
>>> + int urb_size, max_urb_entry;
>>> + struct intel_context *intel = &brw->intel;
>>> +
>>> + if (IS_GT1(intel->intelScreen->deviceID)) {
>>> + urb_size = 32 * 1024;
>>> + max_urb_entry = 128;
>>> + } else {
>>> + urb_size = 64 * 1024;
>>> + max_urb_entry = 256;
>>> + }
>>> +
>>> + brw->urb.nr_vs_entries = max_urb_entry;
>>> + brw->urb.nr_gs_entries = max_urb_entry;
>>>
>>> /* CACHE_NEW_VS_PROG */
>>> brw->urb.vs_size = MAX2(brw->vs.prog_data->urb_entry_size, 1);
>>>
>>> - if (256 * brw->urb.vs_size > 64 * 1024)
>>> + if (2 * brw->urb.vs_size > urb_size)
>>
>>Shouldn't this be:
>>
>> if ((2 * brw->urb.vs_size * brw->urb.nr_vs_entries) > urb_size)
Yes, it should be.
Thanks
Zou Nanhai
>>
>>>brw->urb.nr_vs_entries = brw->urb.nr_gs_entries =
>>> - (64 * 1024 ) / brw->urb.vs_size;
>>> + (urb_size ) / (2 * brw->urb.vs_size);
>>> }
>>>
>>> static void
>>> diff --git a/src/mesa/drivers/dri/intel/intel_chipset.h
>>b/src/mesa/drivers/dri/intel/intel_chipset.h
>>> index 4fecdbe..4ff9140 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_chipset.h
>>> +++ b/src/mesa/drivers/dri/intel/intel_chipset.h
>>> @@ -133,6 +133,10 @@
>>> devid == PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS || \
>>> devid == PCI_CHIP_SANDYBRIDGE_S)
>>>
>>> +#define IS_GT1(devid) (devid == PCI_CHIP_SANDYBRIDGE_GT1 || \
>>> +devid == PCI_CHIP_SANDYBRIDGE_M_GT1 || \
>>> +devid == PCI_CHIP_SANDYBRIDGE_S)
>>> +
>>> #define IS_965(devid) (IS_GEN4(devid) || \
>>> IS_G4X(devid) || \
>>> IS_GEN5(devid) || \
>>-BEGIN PGP SIGNATURE-
>>Version: GnuPG v1.4.11 (GNU/Linux)
>>Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>>
>>iEYEARECAAYFAk2b2KAACgkQX1gOwKyEAw/IjwCePSJRzTgEqn01U9xCXvd6zYbv
>>0jQAniOM0tnfCf7EHp3Rw/xBiFx6KbMu
>>=pBHg
>>-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa-dev patches listed on ?
On Tue, 05 Apr 2011 11:27:20 -0700, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/05/2011 03:21 AM, Sedat Dilek wrote: > > > as patches to xorg-devel are already listed in [1], what about doing > > the same for patches sent to mesa-dev ML? > > That's not a bad idea. I'm not that familiar with patchwork. Does it > have tools for managing patches that are destined for stable releases > (that are already in master)? I think that would be especially useful. > My current system (combing messages to mesa-commit) doesn't scale very > well. I was unimpressed with the service while using it. It was something I wanted for managing my patch queue (mark patches as accepted/rejected, see what was left), but it was down on a regular basis, and when actually doing review from the interface I was searching for the mail and hitting reply. Now I use notmuch for tracking what things I think I should be committing/reviewing but haven't. pgppBL8ti5qeJ.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] prog_optimize: get_src_arg_mask() respect writemask for more opcodes
--- src/mesa/program/prog_optimize.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/prog_optimize.c index 164297a..acf0f60 100644 --- a/src/mesa/program/prog_optimize.c +++ b/src/mesa/program/prog_optimize.c @@ -74,6 +74,17 @@ get_src_arg_mask(const struct prog_instruction *inst, case OPCODE_MAD: case OPCODE_MUL: case OPCODE_SUB: + case OPCODE_CMP: + case OPCODE_FLR: + case OPCODE_FRC: + case OPCODE_LRP: + case OPCODE_SEQ: + case OPCODE_SGE: + case OPCODE_SGT: + case OPCODE_SLE: + case OPCODE_SLT: + case OPCODE_SNE: + case OPCODE_SSG: channel_mask = inst->DstReg.WriteMask & dst_mask; break; case OPCODE_RCP: -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
