Re: [Mesa-dev] [PATCH] nouveau: Add support for hardware video decoding
On Fri, Sep 02, 2011 at 06:15:00PM +0200, Maarten Lankhorst wrote:
> Try to use the PMPEG where available
>
> Signed-off-by: Maarten Lankhorst
>
> ---
> diff --git a/src/gallium/drivers/nouveau/nouveau_video.c
> b/src/gallium/drivers/nouveau/nouveau_video.c
> index 620c030..2b90056 100644
> --- a/src/gallium/drivers/nouveau/nouveau_video.c
> +++ b/src/gallium/drivers/nouveau/nouveau_video.c
(...)
> +
> +static unsigned
> +nouveau_decoder_surface_index(struct nouveau_decoder *dec,
> + struct pipe_video_buffer *buffer)
> +{
> + struct nouveau_video_buffer *buf = (struct nouveau_video_buffer *)buffer;
> + struct nouveau_channel *chan = dec->screen->channel;
> + struct nouveau_bo *bo_y, *bo_c;
> + unsigned i;
> +
> + if (!buf)
> + return 8;
> + for (i = 0; i < dec->num_surfaces; ++i) {
> + if (dec->surfaces[i] == buf)
> + return i;
> + }
> + assert(i < 8);
> + dec->surfaces[i] = buf;
> + dec->num_surfaces++;
> +
> + if (dec->screen->device->chipset < 0x50) {
> + bo_y = ((struct nvfx_resource *)buf->resources[0])->bo;
> + bo_c = ((struct nvfx_resource *)buf->resources[1])->bo;
> + } else {
> + bo_y = ((struct nv04_resource *)buf->resources[0])->bo;
> + bo_c = ((struct nv04_resource *)buf->resources[1])->bo;
> + }
This is not going to work for nv6x's - they are nv40-class cards (IGPs IIRC)
and are handled by nvfx driver
> + MARK_RING(chan, 3, 2);
> + BEGIN_RING(chan, dec->mpeg, NV31_MPEG_IMAGE_Y_OFFSET(i), 2);
> + OUT_RELOCl(chan, bo_y, 0, NOUVEAU_BO_RDWR);
> + OUT_RELOCl(chan, bo_c, 0, NOUVEAU_BO_RDWR);
> + return i;
> +}
> +
(...)
> +
> +static struct pipe_video_decoder *
> +nouveau_create_decoder(struct pipe_context *context,
> + struct nouveau_screen *screen,
> + enum pipe_video_profile profile,
> + enum pipe_video_entrypoint entrypoint,
> + enum pipe_video_chroma_format chroma_format,
> + unsigned width, unsigned height)
> +{
> + struct nouveau_channel *chan = screen->channel;
> + struct nouveau_grobj *mpeg = NULL;
> + struct nouveau_decoder *dec;
> + int ret;
> +
> + debug_printf("Acceleration level: %s\n", entrypoint <=
> PIPE_VIDEO_ENTRYPOINT_BITSTREAM ? "bit":
> +entrypoint ==
> PIPE_VIDEO_ENTRYPOINT_IDCT ? "IDCT" : "MC");
> +
> + if (getenv("XVMC_VL"))
> + goto vl;
> + if (u_reduce_video_profile(profile) != PIPE_VIDEO_CODEC_MPEG12)
> + goto vl;
> + if (screen->device->chipset >= 0x98 && screen->device->chipset != 0xa0)
> + goto vl;
> +
> + width = align(width, 64);
> + height = align(height, 64);
> +
> + if (screen->device->chipset > 0x50)
> + ret = nouveau_grobj_alloc(chan, 0xbeef8274, 0x8274, &mpeg);
> + else
> + ret = nouveau_grobj_alloc(chan, 0xbeef8274, 0x3174, &mpeg);
As above. You want to check for > 0x80.
> + if (ret < 0) {
> + debug_printf("Creation failed: %s (%i)\n", strerror(-ret), ret);
> + return NULL;
> + }
> +
> + dec = CALLOC_STRUCT(nouveau_decoder);
> + if (!dec) {
> + nouveau_grobj_free(&mpeg);
> + goto fail;
> + }
> + dec->mpeg = mpeg;
> + dec->base.context = context;
> + dec->base.profile = profile;
> + dec->base.entrypoint = entrypoint;
> + dec->base.chroma_format = chroma_format;
> + dec->base.width = width;
> + dec->base.height = height;
> + dec->base.destroy = nouveau_decoder_destroy;
> + dec->base.begin_frame = nouveau_decoder_begin_frame;
> + dec->base.end_frame = nouveau_decoder_end_frame;
> + dec->base.set_decode_target = nouveau_decoder_set_decode_target;
> + dec->base.set_picture_parameters = nouveau_decoder_set_picture_parameters;
> + dec->base.set_reference_frames = nouveau_decoder_set_reference_frames;
> + dec->base.decode_macroblock = nouveau_decoder_decode_macroblock;
> + dec->base.flush = nouveau_decoder_flush;
> + dec->screen = screen;
> +
> + ret = nouveau_bo_new(dec->screen->device, NOUVEAU_BO_GART, 0, 1024 *
> 1024, &dec->cmd_bo);
> + if (ret)
> + goto fail;
> +
> + ret = nouveau_bo_new(dec->screen->device, NOUVEAU_BO_GART, 0, width *
> height * 6, &dec->data_bo);
> + if (ret)
> + goto fail;
> +
> + ret = nouveau_bo_new(dec->screen->device, NOUVEAU_BO_GART|NOUVEAU_BO_MAP,
> 0, 4096,
> +&dec->fence_bo);
> + if (ret)
> + goto fail;
> + nouveau_bo_map(dec->fence_bo, NOUVEAU_BO_RDWR);
> + dec->fence_map = dec->fence_bo->map;
> + nouveau_bo_unmap(dec->fence_bo);
> + dec->fence_map[0] = 0;
> +
> + if (dec->screen->device->chipset > 0x50)
> + MARK_RING(chan, 25, 3);
> + else
> + MARK_RING(chan, 20, 2);
> +
Again s/0x50/0x80.
> + BEGIN_RING(chan, mpeg, NV31_MPEG_DMA_CMD, 1);
> + OUT_RING(chan, chan->vram->handle);
> +
> + BEGIN_RING(chan, mpeg, NV31_MPEG_DMA_DATA, 1);
> + OUT_RING(chan, chan->vram->handle);
Re: [Mesa-dev] [PATCH v2] nouveau: Add support for XvMC acceleration
On Sat, Sep 10, 2011 at 06:59:39PM +0200, Maarten Lankhorst wrote: > Hey ★, > > On 09/10/2011 06:28 PM, ★ Emeric wrote: > > Hi Maarten, > > I tried the v2 patch with my good old geforce 8600M GS, and it worked well. > > The CPU usage seems a little higher than usual, I'd said 60% instead of 40% > > for a 720p video, but I'll try with a higher bitrate video and without > > building with debug parameters to see if I can found a performance gain. > > The only problem is that I cannot seek through the video without an segfault > > on that error "X11 error: BadAccess (attempt to access private resource > > denied)", I attached a gdb backtrace. It appears to be related to the > > drawing of the mplayer OSD. > > > That's either a bug in mplayer or in the state tracker. What's oy and ox > set to at the time of the crash? and where does xvimage->data point to :) > This is a bug in xf86-video-nouveau actually, and it leads to memory corruption in mplayer. Patch below fixes it, but OSD still doesn't work. --- From 00f7986291b86db9a09c1651eb4450c69761fe27 Mon Sep 17 00:00:00 2001 From: Marcin Slusarz Date: Sat, 10 Sep 2011 23:14:53 +0200 Subject: [PATCH] xv: support AI44/IA44 --- src/nouveau_xv.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/nouveau_xv.c b/src/nouveau_xv.c index 30753fa..5a5337c 100644 --- a/src/nouveau_xv.c +++ b/src/nouveau_xv.c @@ -1426,7 +1426,15 @@ NVQueryImageAttributes(ScrnInfoPtr pScrn, int id, pitches[0] = size; // 4*width size *= *h; // 4*width*height break; + case FOURCC_AI44: + case FOURCC_IA44: + size = *w; // width + if (pitches) + pitches[0] = size; // width + size *= *h; // width*height + break; default: + xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "Unknown colorspace: %x\n", id); *w = *h = size = 0; break; } -- 1.7.6.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] nouveau: Add support for XvMC acceleration
On Sun, Sep 11, 2011 at 12:54:20AM +0200, Marcin Slusarz wrote: > On Sat, Sep 10, 2011 at 06:59:39PM +0200, Maarten Lankhorst wrote: > > Hey ★, > > > > On 09/10/2011 06:28 PM, ★ Emeric wrote: > > > Hi Maarten, > > > I tried the v2 patch with my good old geforce 8600M GS, and it worked > > > well. > > > The CPU usage seems a little higher than usual, I'd said 60% instead of > > > 40% > > > for a 720p video, but I'll try with a higher bitrate video and without > > > building with debug parameters to see if I can found a performance gain. > > > The only problem is that I cannot seek through the video without an > > > segfault > > > on that error "X11 error: BadAccess (attempt to access private resource > > > denied)", I attached a gdb backtrace. It appears to be related to the > > > drawing of the mplayer OSD. > > > > > That's either a bug in mplayer or in the state tracker. What's oy and ox > > set to at the time of the crash? and where does xvimage->data point to :) > > > This is a bug in xf86-video-nouveau actually, and it leads to memory > corruption > in mplayer. > > Patch below fixes it, but OSD still doesn't work. > With commit f626d99edf17a1d3203b257f6fe6993229ea6866 in mesa OSD in mplayer works (Yeah! ;). I've submitted patch for mplayer to disable OSD instead of crashing. Ben, can you review and push patch in the previous mail? (xv: support AI44/IA44) Thanks. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: move clear paths from rgba to a pointer to a color union
On Thu, Sep 15, 2011 at 02:35:49PM +0100, Dave Airlie wrote:
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index 722db8d..f36994a 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -215,7 +215,7 @@ void st_init_limits(struct st_context *st)
>c->MinProgramTexelOffset = screen->get_param(screen,
> PIPE_CAP_MIN_TEXEL_OFFSET);
>c->MaxProgramTexelOffset = screen->get_param(screen,
> PIPE_CAP_MAX_TEXEL_OFFSET);
>
> - c->GLSLVersion = 120;
> + c->GLSLVersion = 130;
>c->UniformBooleanTrue = ~0;
> }
> }
> @@ -678,4 +678,6 @@ void st_init_extensions(struct st_context *st)
> PIPE_BIND_SAMPLER_VIEW)) {
>ctx->Extensions.ARB_depth_buffer_float = GL_TRUE;
> }
> + ctx->Extensions.EXT_texture_integer = GL_TRUE;
> + ctx->Extensions.EXT_gpu_shader4 = GL_TRUE;
> }
> --
really?
;)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/13] linker: Use gl_shader_program::AttributeBindings for attrib locations
On Thu, Oct 06, 2011 at 06:54:38PM -0700, Stéphane Marchesin wrote: > Hi Ian, > > This regresses Chrome GPU acceleration for all GPUs (I tested i915g, > llvmpipe, i965). > FYI, I bisected black screen in OilRush (glretrace of OilRush trace actually) to this commit too. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] Elminate redudnant Mesa IR references
On Tue, Oct 04, 2011 at 01:44:03PM -0700, Ian Romanick wrote: > This is the next in my series of internal shader API cleaning. The > primary purpose of this series is to remove the extra tracking of Mesa > IR shaders. The gl_shader_program has a reference to the Mesa IR > shader for each stage, and the entry in gl_shader_program::_LinkedShaders > has a reference to the same Mesa IR. > > The first three patches eliminate the extra references, and the > remaining six implement some refactors and clean-ups enabled by the > first three. > > src/glsl/ir.cpp|8 --- > src/glsl/ir.h |8 --- > src/mesa/drivers/dri/i965/brw_fs.cpp |8 ++- > src/mesa/drivers/dri/i965/brw_fs.h |3 +- > src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |3 +- > src/mesa/drivers/dri/i965/brw_vs.c |8 ++- > src/mesa/drivers/dri/i965/brw_wm.c |2 +- > src/mesa/main/context.c|8 +-- > src/mesa/main/ff_fragment_shader.cpp | 10 ++-- > src/mesa/main/mtypes.h |3 - > src/mesa/main/shaderapi.c | 32 +-- > src/mesa/main/shaderobj.c |4 - > src/mesa/main/state.c | 18 -- > src/mesa/main/texstate.c | 18 +++--- > src/mesa/main/uniforms.c | 42 +- > src/mesa/program/ir_to_mesa.cpp| 37 > src/mesa/program/prog_uniform.c| 74 > > src/mesa/program/prog_uniform.h|4 - > src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 44 --- > src/mesa/state_tracker/st_program.c|9 +-- > 20 files changed, 111 insertions(+), 232 deletions(-) > Commits 1-5 are unbuildable and one of them introduces crashes in many piglit tests on nv50, e.g. glx-shader-sharing, glsl-bindattriblocation. glx-shader-sharing: Program received signal SIGSEGV, Segmentation fault. 0x737b1dac in destroy_shader_program_variants_cb (userData=, data=, key=) at state_tracker/st_program.c:1157 warning: Source file is more recent than executable. 1157 shProg->_LinkedShaders[MESA_SHADER_VERTEX]->Program); (gdb) bt #0 0x737b1dac in destroy_shader_program_variants_cb (userData=, data=, key=) at state_tracker/st_program.c:1157 #1 destroy_shader_program_variants_cb (key=, data=0x8e9ca0, userData=0x759320) at state_tracker/st_program.c:1141 #2 0x73735732 in _mesa_HashWalk (table=0x72fd70, callback=0x737b1d10 , userData=0x759320) at main/hash.c:334 #3 0x737ac84a in st_destroy_context (st=0x759320) at state_tracker/st_context.c:256 #4 0x73643f2d in dri_destroy_context (cPriv=) at dri_context.c:130 #5 0x7363fab0 in driDestroyContext (pcp=0x6b7330) at ../common/dri_util.c:589 #6 0x77bc1575 in dri2_destroy_context () from /usr/lib64/opengl/xorg-x11/lib/libGL.so.1 #7 0x77b9b9dc in glXMakeCurrentReadSGI () from /usr/lib64/opengl/xorg-x11/lib/libGL.so.1 #8 0x0042c1c8 in draw (dpy=0x66e010) at /data1/gfx/piglit/tests/glx/glx-shader-sharing.c:136 #9 0x0042fbe0 in piglit_glx_event_loop (dpy=0x66e010, draw=0x42bec9 ) at /data1/gfx/piglit/tests/util/piglit-glx-util.c:159 #10 0x0042c468 in main (argc=2, argv=0x7fffd6d8) at /data1/gfx/piglit/tests/glx/glx-shader-sharing.c:192 glsl-bindattriblocation: Program received signal SIGSEGV, Segmentation fault. 0x737b1dac in destroy_shader_program_variants_cb (userData=, data=, key=) at state_tracker/st_program.c:1157 warning: Source file is more recent than executable. 1157 shProg->_LinkedShaders[MESA_SHADER_VERTEX]->Program); (gdb) bt #0 0x737b1dac in destroy_shader_program_variants_cb (userData=, data=, key=) at state_tracker/st_program.c:1157 #1 destroy_shader_program_variants_cb (key=, data=0x765db0, userData=0x75a6f0) at state_tracker/st_program.c:1141 #2 0x73735732 in _mesa_HashWalk (table=0x7312f0, callback=0x737b1d10 , userData=0x75a6f0) at main/hash.c:334 #3 0x737ac84a in st_destroy_context (st=0x75a6f0) at state_tracker/st_context.c:256 #4 0x73643f2d in dri_destroy_context (cPriv=) at dri_context.c:130 #5 0x7363fab0 in driDestroyContext (pcp=0x67e8c0) at ../common/dri_util.c:589 #6 0x77bc1575 in dri2_destroy_context () from /usr/lib64/opengl/xorg-x11/lib/libGL.so.1 #7 0x776e95cb in __glutDestroyWindow (window=0x67bd80, initialWindow=0x67bd80) at glut_win.c:831 #8 0x776e979c in glutDestroyWindow (win=) at glut_win.c:882 #9 0x0042d6aa in display () at /data1/gfx/piglit/tests/util/piglit-framework.c:51 #10 0x776de92b in processWindowWorkList (window=0x67bd80) at glut_event.c:1307 #11 0x
Re: [Mesa-dev] [PATCH 0/9] Elminate redudnant Mesa IR references
On Sun, Oct 09, 2011 at 04:41:43PM +0200, Marcin Slusarz wrote: > On Tue, Oct 04, 2011 at 01:44:03PM -0700, Ian Romanick wrote: > > This is the next in my series of internal shader API cleaning. The > > primary purpose of this series is to remove the extra tracking of Mesa > > IR shaders. The gl_shader_program has a reference to the Mesa IR > > shader for each stage, and the entry in gl_shader_program::_LinkedShaders > > has a reference to the same Mesa IR. > > > > The first three patches eliminate the extra references, and the > > remaining six implement some refactors and clean-ups enabled by the > > first three. > > > > src/glsl/ir.cpp|8 --- > > src/glsl/ir.h |8 --- > > src/mesa/drivers/dri/i965/brw_fs.cpp |8 ++- > > src/mesa/drivers/dri/i965/brw_fs.h |3 +- > > src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |3 +- > > src/mesa/drivers/dri/i965/brw_vs.c |8 ++- > > src/mesa/drivers/dri/i965/brw_wm.c |2 +- > > src/mesa/main/context.c|8 +-- > > src/mesa/main/ff_fragment_shader.cpp | 10 ++-- > > src/mesa/main/mtypes.h |3 - > > src/mesa/main/shaderapi.c | 32 +-- > > src/mesa/main/shaderobj.c |4 - > > src/mesa/main/state.c | 18 -- > > src/mesa/main/texstate.c | 18 +++--- > > src/mesa/main/uniforms.c | 42 +- > > src/mesa/program/ir_to_mesa.cpp| 37 > > src/mesa/program/prog_uniform.c| 74 > > > > src/mesa/program/prog_uniform.h|4 - > > src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 44 --- > > src/mesa/state_tracker/st_program.c|9 +-- > > 20 files changed, 111 insertions(+), 232 deletions(-) > > > > Commits 1-5 are unbuildable and one of them introduces crashes in many > piglit tests on nv50, e.g. glx-shader-sharing, glsl-bindattriblocation. Commits 1-5 are unbuildable, but first bad commit is 6th, so there are 6 commits to look at. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] Elminate redudnant Mesa IR references
On Mon, Oct 10, 2011 at 10:18:26AM -0700, Ian Romanick wrote: > On 10/09/2011 07:41 AM, Marcin Slusarz wrote: > > On Tue, Oct 04, 2011 at 01:44:03PM -0700, Ian Romanick wrote: > >> This is the next in my series of internal shader API cleaning. The > >> primary purpose of this series is to remove the extra tracking of Mesa > >> IR shaders. The gl_shader_program has a reference to the Mesa IR > >> shader for each stage, and the entry in gl_shader_program::_LinkedShaders > >> has a reference to the same Mesa IR. > >> > >> The first three patches eliminate the extra references, and the > >> remaining six implement some refactors and clean-ups enabled by the > >> first three. > >> > >> src/glsl/ir.cpp|8 --- > >> src/glsl/ir.h |8 --- > >> src/mesa/drivers/dri/i965/brw_fs.cpp |8 ++- > >> src/mesa/drivers/dri/i965/brw_fs.h |3 +- > >> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |3 +- > >> src/mesa/drivers/dri/i965/brw_vs.c |8 ++- > >> src/mesa/drivers/dri/i965/brw_wm.c |2 +- > >> src/mesa/main/context.c|8 +-- > >> src/mesa/main/ff_fragment_shader.cpp | 10 ++-- > >> src/mesa/main/mtypes.h |3 - > >> src/mesa/main/shaderapi.c | 32 +-- > >> src/mesa/main/shaderobj.c |4 - > >> src/mesa/main/state.c | 18 -- > >> src/mesa/main/texstate.c | 18 +++--- > >> src/mesa/main/uniforms.c | 42 +- > >> src/mesa/program/ir_to_mesa.cpp| 37 > >> src/mesa/program/prog_uniform.c| 74 > >> > >> src/mesa/program/prog_uniform.h|4 - > >> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 44 --- > >> src/mesa/state_tracker/st_program.c|9 +-- > >> 20 files changed, 111 insertions(+), 232 deletions(-) > >> > > > > Commits 1-5 are unbuildable and one of them introduces crashes in many > > piglit tests on nv50, e.g. glx-shader-sharing, glsl-bindattriblocation. > > > > glx-shader-sharing: > > Program received signal SIGSEGV, Segmentation fault. > > 0x737b1dac in destroy_shader_program_variants_cb > > (userData=, data=, key=) at > > state_tracker/st_program.c:1157 > > warning: Source file is more recent than executable. > > 1157 > > shProg->_LinkedShaders[MESA_SHADER_VERTEX]->Program); > > Does Stephane's patch from the weekend > (http://marc.info/?l=mesa3d-dev&m=131820561425054&w=2) fix this issue? > If it does, you should send him a Tested-by. Yes, this patch fixes it. Thanks. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/13] linker: Use gl_shader_program::AttributeBindings for attrib locations
On Sun, Oct 09, 2011 at 04:36:19PM +0200, Marcin Slusarz wrote: > On Thu, Oct 06, 2011 at 06:54:38PM -0700, Stéphane Marchesin wrote: > > Hi Ian, > > > > This regresses Chrome GPU acceleration for all GPUs (I tested i915g, > > llvmpipe, i965). > > > > FYI, I bisected black screen in OilRush (glretrace of OilRush trace > actually) to this commit too. This is fixed by "hash_table: Make string_to_uint_map make a copy of the name" Thanks. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): st/xorg: fix build without LLVM
On Thu, Oct 13, 2011 at 07:54:32PM +0200, Michel Dänzer wrote: > On Don, 2011-10-13 at 10:03 -0700, Marcin XXlusarz wrote: > > Module: Mesa > > Branch: master > > Commit: 349e4db99e938f8ee8826b0d27e490c66a1e8356 > > URL: > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=349e4db99e938f8ee8826b0d27e490c66a1e8356 > > > > Author: Marcin Slusarz > > Date: Thu Oct 13 18:44:40 2011 +0200 > > > > st/xorg: fix build without LLVM > > > > --- > > > > src/gallium/targets/Makefile.xorg |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/src/gallium/targets/Makefile.xorg > > b/src/gallium/targets/Makefile.xorg > > index 9269375..c96eded 100644 > > --- a/src/gallium/targets/Makefile.xorg > > +++ b/src/gallium/targets/Makefile.xorg > > @@ -33,6 +33,8 @@ LD = $(CXX) > > LDFLAGS += $(LLVM_LDFLAGS) > > USE_CXX=1 > > DRIVER_LINKS += $(LLVM_LIBS) -lm -ldl > > +else > > +LDFLAGS += -lstdc++ > > endif > > This is wrong. Use g++ for linking libstdc++, gcc [...] -lstdc++ doesn't > work everywhere. It wasn't my invention - I mimicked other targets (with partial exception of dri). Why gcc -lstdc++ doesn't work everywhere? --- From: Marcin Slusarz Subject: [PATCH] gallium/targets: use g++ for linking As pointed by Michel Dänzer, gcc -lstdc++ "doesn't work everywhere", because ... Use g++ for linking and remove redundant LDFLAGS += -lstdc++. --- src/gallium/targets/Makefile.dri |2 -- src/gallium/targets/Makefile.va|4 +--- src/gallium/targets/Makefile.vdpau |4 +--- src/gallium/targets/Makefile.xorg |5 + src/gallium/targets/Makefile.xvmc |4 +--- 5 files changed, 4 insertions(+), 15 deletions(-) diff --git a/src/gallium/targets/Makefile.dri b/src/gallium/targets/Makefile.dri index 857ebfe..a26b3ee 100644 --- a/src/gallium/targets/Makefile.dri +++ b/src/gallium/targets/Makefile.dri @@ -4,8 +4,6 @@ ifeq ($(MESA_LLVM),1) LDFLAGS += $(LLVM_LDFLAGS) DRIVER_EXTRAS = $(LLVM_LIBS) -else -LDFLAGS += -lstdc++ endif MESA_MODULES = \ diff --git a/src/gallium/targets/Makefile.va b/src/gallium/targets/Makefile.va index 7ced430..b6ee595 100644 --- a/src/gallium/targets/Makefile.va +++ b/src/gallium/targets/Makefile.va @@ -17,8 +17,6 @@ STATE_TRACKER_LIB = $(TOP)/src/gallium/state_trackers/va/libvatracker.a ifeq ($(MESA_LLVM),1) LDFLAGS += $(LLVM_LDFLAGS) DRIVER_EXTRAS = $(LLVM_LIBS) -else -LDFLAGS += -lstdc++ endif # XXX: Hack, VA public funcs aren't exported @@ -39,7 +37,7 @@ OBJECTS = $(C_SOURCES:.c=.o) \ default: depend symlinks $(TOP)/$(LIB_DIR)/gallium/$(LIBNAME) $(TOP)/$(LIB_DIR)/gallium/$(LIBNAME): $(OBJECTS) $(PIPE_DRIVERS) $(STATE_TRACKER_LIB) $(TOP)/$(LIB_DIR)/gallium Makefile - $(MKLIB) -o $(LIBBASENAME) -linker '$(CC)' -ldflags '$(LDFLAGS)' \ + $(MKLIB) -o $(LIBBASENAME) -linker '$(CXX)' -ldflags '$(LDFLAGS)' \ -major $(VA_MAJOR) -minor $(VA_MINOR) $(MKLIB_OPTIONS) \ -install $(TOP)/$(LIB_DIR)/gallium \ $(OBJECTS) $(STATE_TRACKER_LIB) $(PIPE_DRIVERS) $(LIBS) $(DRIVER_EXTRAS) diff --git a/src/gallium/targets/Makefile.vdpau b/src/gallium/targets/Makefile.vdpau index c634915..f6b89ad 100644 --- a/src/gallium/targets/Makefile.vdpau +++ b/src/gallium/targets/Makefile.vdpau @@ -17,8 +17,6 @@ STATE_TRACKER_LIB = $(TOP)/src/gallium/state_trackers/vdpau/libvdpautracker.a ifeq ($(MESA_LLVM),1) LDFLAGS += $(LLVM_LDFLAGS) DRIVER_EXTRAS = $(LLVM_LIBS) -else -LDFLAGS += -lstdc++ endif # XXX: Hack, VDPAU public funcs aren't exported if we link to libvdpautracker.a :( @@ -39,7 +37,7 @@ OBJECTS = $(C_SOURCES:.c=.o) \ default: depend symlinks $(TOP)/$(LIB_DIR)/gallium/$(LIBNAME) $(TOP)/$(LIB_DIR)/gallium/$(LIBNAME): $(OBJECTS) $(PIPE_DRIVERS) $(STATE_TRACKER_LIB) $(TOP)/$(LIB_DIR)/gallium Makefile - $(MKLIB) -o $(LIBBASENAME) -linker '$(CC)' -ldflags '$(LDFLAGS)' \ + $(MKLIB) -o $(LIBBASENAME) -linker '$(CXX)' -ldflags '$(LDFLAGS)' \ -major $(VDPAU_MAJOR) -minor $(VDPAU_MINOR) $(MKLIB_OPTIONS) \ -install $(TOP)/$(LIB_DIR)/gallium \ $(OBJECTS) $(STATE_TRACKER_LIB) $(PIPE_DRIVERS) $(LIBS) $(DRIVER_EXTRAS) diff --git a/src/gallium/targets/Makefile.xorg b/src/gallium/targets/Makefile.xorg index c96eded..0538b2b 100644 --- a/src/gallium/targets/Makefile.xorg +++ b/src/gallium/targets/Makefile.xorg @@ -31,10 +31,7 @@ LIBNAME_STAGING = $(TOP)/$(LIB_DIR)/gallium/$(TARGET) ifeq ($(MESA_LLVM),1) LD = $(CXX) LDFLAGS += $(LLVM_LDFLAGS) -USE_CXX=1 DRIVER_LINKS += $(LLVM_LIBS) -lm -ldl -else -LDFLAGS += -lstdc++ endif @@ -43,7 +40,7 @@ endif default: depend $(TOP)/$(LIB_DIR)/gallium $(LIBNAME) $(LIBNAME_STAGIN
Re: [Mesa-dev] Mesa (master): st/xorg: fix build without LLVM
On Fri, Oct 14, 2011 at 08:22:35AM +0200, Michel Dänzer wrote: > On Don, 2011-10-13 at 15:11 -0500, Patrick Baggett wrote: > > Well, trivial answer is that Win32 uses some C/C++ runtime provided by > > Microsoft, usually something like MSVCR90.DLL (v9.0) etc. Solaris uses > > libC.so, for example. As far as I know, only systems where the GNU C/C > > ++ compiler is main system compiler (and generally therefore the GNU C > > ++ runtime) uses anything named "libstdc++". So I'd expect > > Free/Net/OpenBSD + Linux use that naming and probably not much else. > > On other commercial UNIXes, if it does exist, it is just > > for compatibility with C++ programs compiled using g++. > > gcc -lsdtdc++ doesn't even work on all Linux architectures, as libdstdc > ++ may require other stuff which is only pulled in implicitly by g++. Thanks. > BTW, why does st/xorg need libstdc++ at all without LLVM? Good question. I assumed it's needed by some mesa/gallium core, but I checked it now and it's only needed by (new) nv50/nvc0 driver code. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/targets: use c++ compiler for linking
On Sun, Oct 16, 2011 at 02:03:16PM +0200, Marcin Slusarz wrote: > On Fri, Oct 14, 2011 at 08:22:35AM +0200, Michel Dänzer wrote: > > On Don, 2011-10-13 at 15:11 -0500, Patrick Baggett wrote: > > > Well, trivial answer is that Win32 uses some C/C++ runtime provided by > > > Microsoft, usually something like MSVCR90.DLL (v9.0) etc. Solaris uses > > > libC.so, for example. As far as I know, only systems where the GNU C/C > > > ++ compiler is main system compiler (and generally therefore the GNU C > > > ++ runtime) uses anything named "libstdc++". So I'd expect > > > Free/Net/OpenBSD + Linux use that naming and probably not much else. > > > On other commercial UNIXes, if it does exist, it is just > > > for compatibility with C++ programs compiled using g++. > > > > gcc -lsdtdc++ doesn't even work on all Linux architectures, as libdstdc > > ++ may require other stuff which is only pulled in implicitly by g++. > > Thanks. > > > BTW, why does st/xorg need libstdc++ at all without LLVM? > > Good question. I assumed it's needed by some mesa/gallium core, but > I checked it now and it's only needed by (new) nv50/nvc0 driver code. > I found another cases where -lstdc++ was used with gcc. Updated patch below. -- From: Marcin Slusarz Subject: [PATCH] gallium/targets: use c++ compiler for linking MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As pointed by Michel Dänzer, gcc -lstdc++ doesn't work on all systems because it may require other libs which are only pulled in implicitly by g++. Additionally libstdc++ is GNU-only lib. So use c++ compiler for linking and remove redundant LDFLAGS += -lstdc++. --- configure.ac |2 +- src/gallium/targets/Makefile.dri |2 -- src/gallium/targets/Makefile.va|4 +--- src/gallium/targets/Makefile.vdpau |4 +--- src/gallium/targets/Makefile.xorg |5 + src/gallium/targets/Makefile.xvmc |4 +--- src/gallium/targets/gbm/Makefile |3 +-- src/gallium/targets/xa-vmwgfx/Makefile |4 +--- 8 files changed, 7 insertions(+), 21 deletions(-) diff --git a/configure.ac b/configure.ac index 49e81ad..a21c9b7 100644 --- a/configure.ac +++ b/configure.ac @@ -1719,7 +1719,7 @@ if test "x$enable_gallium_llvm" = xyes; then if test "x$LLVM_CONFIG" != xno; then LLVM_VERSION=`$LLVM_CONFIG --version` LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed 's/-DNDEBUG\>//g'` - LLVM_LIBS="`$LLVM_CONFIG --libs` -lstdc++" + LLVM_LIBS="`$LLVM_CONFIG --libs` LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` DEFINES="$DEFINES -D__STDC_CONSTANT_MACROS" diff --git a/src/gallium/targets/Makefile.dri b/src/gallium/targets/Makefile.dri index 857ebfe..a26b3ee 100644 --- a/src/gallium/targets/Makefile.dri +++ b/src/gallium/targets/Makefile.dri @@ -4,8 +4,6 @@ ifeq ($(MESA_LLVM),1) LDFLAGS += $(LLVM_LDFLAGS) DRIVER_EXTRAS = $(LLVM_LIBS) -else -LDFLAGS += -lstdc++ endif MESA_MODULES = \ diff --git a/src/gallium/targets/Makefile.va b/src/gallium/targets/Makefile.va index 7ced430..b6ee595 100644 --- a/src/gallium/targets/Makefile.va +++ b/src/gallium/targets/Makefile.va @@ -17,8 +17,6 @@ STATE_TRACKER_LIB = $(TOP)/src/gallium/state_trackers/va/libvatracker.a ifeq ($(MESA_LLVM),1) LDFLAGS += $(LLVM_LDFLAGS) DRIVER_EXTRAS = $(LLVM_LIBS) -else -LDFLAGS += -lstdc++ endif # XXX: Hack, VA public funcs aren't exported @@ -39,7 +37,7 @@ OBJECTS = $(C_SOURCES:.c=.o) \ default: depend symlinks $(TOP)/$(LIB_DIR)/gallium/$(LIBNAME) $(TOP)/$(LIB_DIR)/gallium/$(LIBNAME): $(OBJECTS) $(PIPE_DRIVERS) $(STATE_TRACKER_LIB) $(TOP)/$(LIB_DIR)/gallium Makefile - $(MKLIB) -o $(LIBBASENAME) -linker '$(CC)' -ldflags '$(LDFLAGS)' \ + $(MKLIB) -o $(LIBBASENAME) -linker '$(CXX)' -ldflags '$(LDFLAGS)' \ -major $(VA_MAJOR) -minor $(VA_MINOR) $(MKLIB_OPTIONS) \ -install $(TOP)/$(LIB_DIR)/gallium \ $(OBJECTS) $(STATE_TRACKER_LIB) $(PIPE_DRIVERS) $(LIBS) $(DRIVER_EXTRAS) diff --git a/src/gallium/targets/Makefile.vdpau b/src/gallium/targets/Makefile.vdpau index c634915..f6b89ad 100644 --- a/src/gallium/targets/Makefile.vdpau +++ b/src/gallium/targets/Makefile.vdpau @@ -17,8 +17,6 @@ STATE_TRACKER_LIB = $(TOP)/src/gallium/state_trackers/vdpau/libvdpautracker.a ifeq ($(MESA_LLVM),1) LDFLAGS += $(LLVM_LDFLAGS) DRIVER_EXTRAS = $(LLVM_LIBS) -else -LDFLAGS += -lstdc++ endif # XXX: Hack, VDPAU public funcs aren't exported if we link to libvdpautracker.a :( @@ -39,7 +37,7 @@ OBJECTS = $(C_SOURCES:.c=.o) \ default: depend symlinks $(TOP)/$(LIB_DIR)/gallium/$(LIBNAME) $(TOP)/$(LIB_DIR)/gallium/$(LIBNAME): $(OBJECTS) $(PIPE_DRIVER
Re: [Mesa-dev] [PATCH] gallium/targets: use c++ compiler for linking
On Sun, Oct 16, 2011 at 04:15:14PM +0200, Michel Dänzer wrote: > On Son, 2011-10-16 at 14:54 +0200, Marcin Slusarz wrote: > > On Sun, Oct 16, 2011 at 02:03:16PM +0200, Marcin Slusarz wrote: > > > On Fri, Oct 14, 2011 at 08:22:35AM +0200, Michel Dänzer wrote: > > > > On Don, 2011-10-13 at 15:11 -0500, Patrick Baggett wrote: > > > > > Well, trivial answer is that Win32 uses some C/C++ runtime provided by > > > > > Microsoft, usually something like MSVCR90.DLL (v9.0) etc. Solaris uses > > > > > libC.so, for example. As far as I know, only systems where the GNU C/C > > > > > ++ compiler is main system compiler (and generally therefore the GNU C > > > > > ++ runtime) uses anything named "libstdc++". So I'd expect > > > > > Free/Net/OpenBSD + Linux use that naming and probably not much else. > > > > > On other commercial UNIXes, if it does exist, it is just > > > > > for compatibility with C++ programs compiled using g++. > > > > > > > > gcc -lsdtdc++ doesn't even work on all Linux architectures, as libdstdc > > > > ++ may require other stuff which is only pulled in implicitly by g++. > > > > > > Thanks. > > > > > > > BTW, why does st/xorg need libstdc++ at all without LLVM? > > > > > > Good question. I assumed it's needed by some mesa/gallium core, but > > > I checked it now and it's only needed by (new) nv50/nvc0 driver code. > > > > > > > I found another cases where -lstdc++ was used with gcc. > > Updated patch below. > > Thanks for tracking these down. > > However, I wonder if we shouldn't try to only use the C++ compiler for > linking when it's really necessary, e.g. for the nv50/nvc0 drivers. > Otherwise, even assuming the resulting binaries don't depend on things > like libstdc++ unless they're really needed, this creates an artificial > requirement for a C++ compiler. (I realize a C++ compiler is really > required for things like the GLSL compiler, but it should still be > possible to build at least some of these targets without one). With the attached patch, and with LLVM disabled: uses c++ symbols | links against libstdc++ | name 1 1 i915_dri.so 1 1 i965_dri.so 1 1 nouveau_vieux_dri.so 1 1 r200_dri.so 1 1 r300_dri.so 1 1 r600_dri.so 1 1 radeon_dri.so 1 1 swrast_dri.so 1 1 egl/egl_gallium.so 1 1 gallium/i915_dri.so 1 1 gallium/i965_dri.so 0 0 gallium/libvdpau_r600.so 0 0 gallium/libvdpau_softpipe.so 0 0 gallium/libxatracker.so 1 1 gallium/libXvMCnouveau.so 0 0 gallium/libXvMCr600.so 0 0 gallium/libXvMCsoftpipe.so 1 1 gallium/nouveau_dri.so 1 1 gallium/r600_dri.so 1 1 gallium/swrast_dri.so 1 1 gallium/vmwgfx_dri.so 0 0 gbm/gbm_gallium_drm.so 0 0 gbm/pipe_i915.so 0 0 gbm/pipe_i965.so 1 1 gbm/pipe_nouveau.so 0 0 gbm/pipe_r600.so 0 0 gbm/pipe_vmwgfx.so With LLVM enabled: uses c++ symbols | links against libstdc++ | name 1 1 i915_dri.so 1 1 i965_dri.so 1 1 nouveau_vieux_dri.so 1 1 r200_dri.so 1 1 r300_dri.so 1 1 r600_dri.so 1 1 radeon_dri.so 1 1 swrast_dri.so 1 1 egl/egl_gallium.so 1 1 gallium/i915_dri.so 1 1 gallium/i965_dri.so 1 1 gallium/i965g_drv.so 0 1 gallium/libvdpau_r600.so 1 1 gallium/libvdpau_softpipe.so 1 1 gallium/libxatracker.so 1 1 gallium/libXvMCnouveau.so 0 1 gallium/libXvMCr600.so 1 1 gallium/libXvMCsoftpipe.so 1 1 gallium/modesetting_drv.so 1 1 gallium/nouveau2_drv.so 1 1 gallium/nouveau_dri.so 1 1 gallium/r600_dri.so 0 1 gallium/r600g_drv.so 1 1 gallium/swrast_dri.so 1 1 gallium/vmwgfx_dri.so 0 0 gbm/gbm_gallium_drm.so 1 1 gbm/pipe_i915.so 0 1 gbm/pipe_i965.so 1 1 gbm/pipe_nouveau.so 0 1 gbm/pipe_r600.so 1 1 gbm/pipe_vmwgfx.so --- diff --git a/configure.ac b/configure.ac index 49e81ad..c596164 100644 --- a/configure.ac +++ b/configure.ac @@ -1719,7 +1719,7 @@ if test "x$enable_gallium_llvm" = xyes; then if test "x$LLVM_CONFIG" != xno; then LLVM_VERSION=`$LLVM_CONFIG --version` LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed 's/-DNDEBUG\>//g'` - LLVM_LIBS="`$LLVM_CONFIG --libs` -lstdc++" + LLVM_LIBS="`$LLVM_CONFIG --libs`" LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` DEFINES="$DEFINES -D__STDC_CONSTANT_MACROS" diff --git a/src/gallium/targets/Makefile.dri b/src/gallium/targets/Makefile.dri index 857ebfe..a26b3ee 100644 --- a/src/gallium/targets/Makefile.dri +++ b/src/gallium/targets/Makefile.dri @@ -4,8 +4,6 @@ ifeq ($(MESA_LLVM),1) LDFLAGS += $(LLVM_LDFLAGS) DRIVER_EXTRAS = $(LLVM_LIBS) -else -LDFLAGS += -lstdc++ endif MESA_MODULES = \ diff --git a/src/gallium/targets/Makefile.va b/src/gallium/targets/Makefile.va index 7ced430..920f130 100644 --- a/src/gallium/targets/Makefile.va +++ b/src/gallium/targets/Makef
Re: [Mesa-dev] [PATCH] gallium/targets: use c++ compiler for linking
On Mon, Oct 17, 2011 at 05:32:22PM +0200, Michel Dänzer wrote: > On Son, 2011-10-16 at 18:47 +0200, Marcin Slusarz wrote: > > On Sun, Oct 16, 2011 at 04:15:14PM +0200, Michel Dänzer wrote: > > > On Son, 2011-10-16 at 14:54 +0200, Marcin Slusarz wrote: > > > > On Sun, Oct 16, 2011 at 02:03:16PM +0200, Marcin Slusarz wrote: > > > > > On Fri, Oct 14, 2011 at 08:22:35AM +0200, Michel Dänzer wrote: > > > > > > On Don, 2011-10-13 at 15:11 -0500, Patrick Baggett wrote: > > > > > > > Well, trivial answer is that Win32 uses some C/C++ runtime > > > > > > > provided by > > > > > > > Microsoft, usually something like MSVCR90.DLL (v9.0) etc. Solaris > > > > > > > uses > > > > > > > libC.so, for example. As far as I know, only systems where the > > > > > > > GNU C/C > > > > > > > ++ compiler is main system compiler (and generally therefore the > > > > > > > GNU C > > > > > > > ++ runtime) uses anything named "libstdc++". So I'd expect > > > > > > > Free/Net/OpenBSD + Linux use that naming and probably not much > > > > > > > else. > > > > > > > On other commercial UNIXes, if it does exist, it is just > > > > > > > for compatibility with C++ programs compiled using g++. > > > > > > > > > > > > gcc -lsdtdc++ doesn't even work on all Linux architectures, as > > > > > > libdstdc > > > > > > ++ may require other stuff which is only pulled in implicitly by > > > > > > g++. > > > > > > > > > > Thanks. > > > > > > > > > > > BTW, why does st/xorg need libstdc++ at all without LLVM? > > > > > > > > > > Good question. I assumed it's needed by some mesa/gallium core, but > > > > > I checked it now and it's only needed by (new) nv50/nvc0 driver code. > > > > > > > > > > > > > I found another cases where -lstdc++ was used with gcc. > > > > Updated patch below. > > > > > > Thanks for tracking these down. > > > > > > However, I wonder if we shouldn't try to only use the C++ compiler for > > > linking when it's really necessary, e.g. for the nv50/nvc0 drivers. > > > Otherwise, even assuming the resulting binaries don't depend on things > > > like libstdc++ unless they're really needed, this creates an artificial > > > requirement for a C++ compiler. (I realize a C++ compiler is really > > > required for things like the GLSL compiler, but it should still be > > > possible to build at least some of these targets without one). > > > > With the attached patch, and with LLVM disabled: > > > > uses c++ symbols | links against libstdc++ | name > > [...] > > These look all good. > > > > With LLVM enabled: > > > > uses c++ symbols | links against libstdc++ | name > > [...] > > > 0 1 gallium/libvdpau_r600.so > > [...] > > > 0 1 gallium/libXvMCr600.so > > [...] > > > 0 1 gallium/r600g_drv.so > > [...] > > > 0 1 gbm/pipe_i965.so > > [...] > > 0 1 gbm/pipe_r600.so > > These could avoid linking against libstdc++ if they didn't link with g > ++, right? Anyway, this looks good for now, thanks again. Right. I'll commit it today. Thanks, Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix transform feedback of unsubscripted gl_ClipDistance array
gl_ClipDistance needs special treatment in form of lowering pass
which transforms gl_ClipDistance representation from float[] to
vec4[]. There are 2 implementations - at glsl linker level (enabled
by LowerClipDistance option) and at glsl_to_tgsi level (enabled
unconditionally for gallium drivers). Second implementation is
incomplete - it does not take into account transform feedback (see
commit 642e5b413e0890b2070ba78fde42db381eaf02e5 "mesa: Fix transform
feedback of unsubscripted gl_ClipDistance array" for details).
There are 2 possible fixes:
- adding transform feedback support into glsl_to_tgsi version
- ripping gl_ClipDistance support from glsl_to_tgsi and enabling
gl_ClipDistance lowering on glsl linker side
This patch implements 2nd option. All it does is:
- reverts most of the commit 59be691638200797583bce39a83f641d30d97492
"st/mesa: add support for gl_ClipDistance"
- changes LowerClipDistance to true
Fixes Piglit tests "EXT_transform_feedback/builtin-varyings
gl_ClipDistance[{2,3,4,5,6,7,8}]-no-subscript" on nv50.
---
Can someone test this patch on radeon hw? The command is:
./piglit-run.py -c 0 -t "[Cc]lip[-]*[Dd]istance" tests/quick.tests
results/quick.results
---
src/mesa/state_tracker/st_extensions.c |1 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 49 +++-
2 files changed, 6 insertions(+), 44 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index a9071f5..6a2da58 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -222,6 +222,7 @@ void st_init_limits(struct st_context *st)
options->MaxUnrollIterations = MIN2(screen->get_shader_param(screen,
sh, PIPE_SHADER_CAP_MAX_INSTRUCTIONS), 65536);
else
options->MaxUnrollIterations = 255; /* SM3 limit */
+ options->LowerClipDistance = true;
}
/* PIPE_SHADER_CAP_MAX_INPUTS for the FS specifies the maximum number
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 347a22f..3d87d11 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -304,7 +304,6 @@ public:
int samplers_used;
bool indirect_addr_temps;
bool indirect_addr_consts;
- int num_clip_distances;
int glsl_version;
bool native_integers;
@@ -2819,7 +2818,6 @@ glsl_to_tgsi_visitor::glsl_to_tgsi_visitor()
samplers_used = 0;
indirect_addr_temps = false;
indirect_addr_consts = false;
- num_clip_distances = 0;
glsl_version = 0;
native_integers = false;
mem_ctx = ralloc_context(NULL);
@@ -4587,17 +4585,9 @@ st_translate_program(
}
for (i = 0; i < numOutputs; i++) {
- if (outputSemanticName[i] == TGSI_SEMANTIC_CLIPDIST) {
-int mask = ((1 << (program->num_clip_distances -
4*outputSemanticIndex[i])) - 1) & TGSI_WRITEMASK_XYZW;
-t->outputs[i] = ureg_DECL_output_masked(ureg,
-outputSemanticName[i],
-outputSemanticIndex[i],
-mask);
- } else {
-t->outputs[i] = ureg_DECL_output(ureg,
- outputSemanticName[i],
- outputSemanticIndex[i]);
- }
+ t->outputs[i] = ureg_DECL_output(ureg,
+ outputSemanticName[i],
+ outputSemanticIndex[i]);
}
if (passthrough_edgeflags)
emit_edgeflags(t);
@@ -4753,8 +4743,7 @@ out:
static struct gl_program *
get_mesa_program(struct gl_context *ctx,
struct gl_shader_program *shader_program,
- struct gl_shader *shader,
- int num_clip_distances)
+ struct gl_shader *shader)
{
glsl_to_tgsi_visitor* v = new glsl_to_tgsi_visitor();
struct gl_program *prog;
@@ -4794,7 +4783,6 @@ get_mesa_program(struct gl_context *ctx,
v->options = options;
v->glsl_version = ctx->Const.GLSLVersion;
v->native_integers = ctx->Const.NativeIntegers;
- v->num_clip_distances = num_clip_distances;
_mesa_generate_parameters_list_for_uniforms(shader_program, shader,
prog->Parameters);
@@ -4919,25 +4907,6 @@ get_mesa_program(struct gl_context *ctx,
return prog;
}
-/**
- * Searches through the IR for a declaration of gl_ClipDistance and returns the
- * declared size of the gl_ClipDistance array. Returns 0 if gl_ClipDistance is
- * not declared in the IR.
- */
-int get_clip_distance_size(exec_list *ir)
-{
- foreach_iter (exec_list_iterator, iter, *ir) {
- ir_instruction *inst = (ir_instruction *)iter.get();
- ir_variable *var = inst->as_variable();
- if (var == NULL) continue;
-
Re: [Mesa-dev] [PATCH] st/mesa: fix transform feedback of unsubscripted gl_ClipDistance array
On Sun, Jun 17, 2012 at 07:17:35AM +0400, Vadim Girlin wrote:
> On Sun, 2012-06-17 at 00:43 +0200, Marcin Slusarz wrote:
> > gl_ClipDistance needs special treatment in form of lowering pass
> > which transforms gl_ClipDistance representation from float[] to
> > vec4[]. There are 2 implementations - at glsl linker level (enabled
> > by LowerClipDistance option) and at glsl_to_tgsi level (enabled
> > unconditionally for gallium drivers). Second implementation is
> > incomplete - it does not take into account transform feedback (see
> > commit 642e5b413e0890b2070ba78fde42db381eaf02e5 "mesa: Fix transform
> > feedback of unsubscripted gl_ClipDistance array" for details).
> >
> > There are 2 possible fixes:
> > - adding transform feedback support into glsl_to_tgsi version
> > - ripping gl_ClipDistance support from glsl_to_tgsi and enabling
> > gl_ClipDistance lowering on glsl linker side
> >
> > This patch implements 2nd option. All it does is:
> > - reverts most of the commit 59be691638200797583bce39a83f641d30d97492
> > "st/mesa: add support for gl_ClipDistance"
> > - changes LowerClipDistance to true
> >
> > Fixes Piglit tests "EXT_transform_feedback/builtin-varyings
> > gl_ClipDistance[{2,3,4,5,6,7,8}]-no-subscript" on nv50.
> > ---
> >
> > Can someone test this patch on radeon hw? The command is:
> > ./piglit-run.py -c 0 -t "[Cc]lip[-]*[Dd]istance" tests/quick.tests
> > results/quick.results
>
> Fixes 8 transform feedback tests on evergreen, no regressions.
Thanks!
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [libdrm PATCH 3/4] nouveau/nouveau.c: Fix two memory leaks.
On Thu, Jun 28, 2012 at 09:51:57PM +0200, Johannes Obermayr wrote:
> ---
> nouveau/nouveau.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
> index 5aa4107..e91287f 100644
> --- a/nouveau/nouveau.c
> +++ b/nouveau/nouveau.c
> @@ -95,6 +95,7 @@ nouveau_device_wrap(int fd, int close, struct
> nouveau_device **pdev)
> (dev->drm_version < 0x0100 ||
>dev->drm_version >= 0x0200)) {
> nouveau_device_del(&dev);
> + free(nvdev);
> return -EINVAL;
> }
>
> @@ -105,6 +106,7 @@ nouveau_device_wrap(int fd, int close, struct
> nouveau_device **pdev)
> ret = nouveau_getparam(dev, NOUVEAU_GETPARAM_AGP_SIZE, &gart);
> if (ret) {
> nouveau_device_del(&dev);
> + free(nvdev);
> return ret;
> }
>
> --
nouveau_device_del already does it.
NAK
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [libdrm PATCH 2/4] libkms/nouveau.c: Fix a memory leak and cleanup code a bit.
On Thu, Jun 28, 2012 at 09:51:56PM +0200, Johannes Obermayr wrote:
> ---
> libkms/nouveau.c | 20 +++-
> 1 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/libkms/nouveau.c b/libkms/nouveau.c
> index 0e24a15..4cbca96 100644
> --- a/libkms/nouveau.c
> +++ b/libkms/nouveau.c
> @@ -94,14 +94,18 @@ nouveau_bo_create(struct kms_driver *kms,
> if (!bo)
> return -ENOMEM;
>
> - if (type == KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8) {
> + switch (type) {
> + case KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8:
> pitch = 64 * 4;
> size = 64 * 64 * 4;
> - } else if (type == KMS_BO_TYPE_SCANOUT_X8R8G8B8) {
> + break;
> + case KMS_BO_TYPE_SCANOUT_X8R8G8B8:
> pitch = width * 4;
> pitch = (pitch + 512 - 1) & ~(512 - 1);
> size = pitch * height;
> - } else {
> + break;
> + default:
> + free(bo);
> return -EINVAL;
> }
>
> @@ -114,8 +118,10 @@ nouveau_bo_create(struct kms_driver *kms,
> arg.channel_hint = 0;
>
> ret = drmCommandWriteRead(kms->fd, DRM_NOUVEAU_GEM_NEW, &arg,
> sizeof(arg));
> - if (ret)
> - goto err_free;
> + if (ret) {
> + free(bo);
> + return ret;
> + }
>
> bo->base.kms = kms;
> bo->base.handle = arg.info.handle;
> @@ -126,10 +132,6 @@ nouveau_bo_create(struct kms_driver *kms,
> *out = &bo->base;
>
> return 0;
> -
> -err_free:
> - free(bo);
> - return ret;
> }
>
> static int
> --
Looks good, but moving bo allocation after type check would be simplier
(-3+3 lines patch) and have the same effect.
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [libdrm PATCH 1/4] libkms/intel.c: Fix a memory leak and a dead assignment as well as cleanup code a bit.
On Thu, Jun 28, 2012 at 09:51:55PM +0200, Johannes Obermayr wrote:
> ---
> libkms/intel.c | 23 ---
> 1 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/libkms/intel.c b/libkms/intel.c
> index 8b8249b..7bf1f76 100644
> --- a/libkms/intel.c
> +++ b/libkms/intel.c
> @@ -93,14 +93,18 @@ intel_bo_create(struct kms_driver *kms,
> if (!bo)
> return -ENOMEM;
>
> - if (type == KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8) {
> + switch (type) {
> + case KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8:
> pitch = 64 * 4;
> size = 64 * 64 * 4;
> - } else if (type == KMS_BO_TYPE_SCANOUT_X8R8G8B8) {
> + break;
> + case KMS_BO_TYPE_SCANOUT_X8R8G8B8:
> pitch = width * 4;
> pitch = (pitch + 512 - 1) & ~(512 - 1);
> size = pitch * ((height + 4 - 1) & ~(4 - 1));
> - } else {
> + break;
> + default:
> + free(bo);
> return -EINVAL;
> }
>
> @@ -108,8 +112,10 @@ intel_bo_create(struct kms_driver *kms,
> arg.size = size;
>
> ret = drmCommandWriteRead(kms->fd, DRM_I915_GEM_CREATE, &arg,
> sizeof(arg));
> - if (ret)
> - goto err_free;
> + if (ret) {
> + free(bo);
> + return ret;
> + }
>
> bo->base.kms = kms;
> bo->base.handle = arg.handle;
The same comment as in nouveau patch.
> @@ -124,9 +130,8 @@ intel_bo_create(struct kms_driver *kms,
> tile.handle = bo->base.handle;
> tile.tiling_mode = I915_TILING_X;
> tile.stride = bo->base.pitch;
> -
> - ret = drmCommandWriteRead(kms->fd, DRM_I915_GEM_SET_TILING,
> &tile, sizeof(tile));
> #if 0
> + ret = drmCommandWriteRead(kms->fd, DRM_I915_GEM_SET_TILING,
> &tile, sizeof(tile));
> if (ret) {
> kms_bo_destroy(out);
> return ret;
This is wrong. You want to ignore the return value, not remove whole ioctl call.
See commit 8838bb1d63bdb8ffa808cd41b7e0ffd2e62ff7bc.
> @@ -135,10 +140,6 @@ intel_bo_create(struct kms_driver *kms,
> }
>
> return 0;
> -
> -err_free:
> - free(bo);
> - return ret;
> }
>
> static int
> --
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [libdrm PATCH 3/4] nouveau/nouveau.c: Fix two memory leaks.
On Thu, Jun 28, 2012 at 11:11:51PM +0200, Johannes Obermayr wrote:
> Am Donnerstag, 28. Juni 2012, 23:06:10 schrieb Marcin Slusarz:
> > On Thu, Jun 28, 2012 at 09:51:57PM +0200, Johannes Obermayr wrote:
> > > ---
> > > nouveau/nouveau.c |2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
> > > index 5aa4107..e91287f 100644
> > > --- a/nouveau/nouveau.c
> > > +++ b/nouveau/nouveau.c
> > > @@ -95,6 +95,7 @@ nouveau_device_wrap(int fd, int close, struct
> > > nouveau_device **pdev)
> > > (dev->drm_version < 0x0100 ||
> > >dev->drm_version >= 0x0200)) {
> > > nouveau_device_del(&dev);
> > > + free(nvdev);
> > > return -EINVAL;
> > > }
> > >
> > > @@ -105,6 +106,7 @@ nouveau_device_wrap(int fd, int close, struct
> > > nouveau_device **pdev)
> > > ret = nouveau_getparam(dev, NOUVEAU_GETPARAM_AGP_SIZE, &gart);
> > > if (ret) {
> > > nouveau_device_del(&dev);
> > > + free(nvdev);
> > > return ret;
> > > }
> > >
> >
> > nouveau_device_del already does it.
> > NAK
> >
> > Marcin
>
> nvdev != &dev or I am wrong?
dev is a prefix of nvdev.
Just read the code...
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [libdrm PATCH 4/4] xf86drm.c: Make more code UDEV unrelevant and fix a memory leak.
On Thu, Jun 28, 2012 at 09:51:58PM +0200, Johannes Obermayr wrote:
These patches should be sent to dri-devel, not mesa-dev.
> ---
> xf86drm.c | 15 ++-
> 1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 6ea068f..798f1fd 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char
> *id2, int pci_domain_ok)
> return 0;
> }
>
> +#if !defined(UDEV)
> /**
> * Handles error checking for chown call.
> *
> @@ -284,6 +285,7 @@ static int chown_check_return(const char *path, uid_t
> owner, gid_t group)
> path, errno, strerror(errno));
> return -1;
> }
> +#endif
>
> /**
> * Open the DRM device, creating it if necessary.
> @@ -303,13 +305,15 @@ static int drmOpenDevice(long dev, int minor, int type)
> stat_t st;
> charbuf[64];
> int fd;
> +
> +sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME,
> minor);
> +drmMsg("drmOpenDevice: node name is %s\n", buf);
> +
> +#if !defined(UDEV)
> mode_t devmode = DRM_DEV_MODE, serv_mode;
> int isroot = !geteuid();
> uid_t user= DRM_DEV_UID;
> gid_t group = DRM_DEV_GID, serv_group;
> -
> -sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME,
> minor);
> -drmMsg("drmOpenDevice: node name is %s\n", buf);
>
> if (drm_server_info) {
> drm_server_info->get_perms(&serv_group, &serv_mode);
> @@ -318,7 +322,6 @@ static int drmOpenDevice(long dev, int minor, int type)
> group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
> }
>
> -#if !defined(UDEV)
> if (stat(DRM_DIR_NAME, &st)) {
> if (!isroot)
> return DRM_ERR_NOT_ROOT;
You should not mix code with declarations.
However, UDEV and non-UDEV codepaths share very little code. I'm wondering
whether it would be better to organize it like:
static int drmOpenDevice(long dev, int minor, int type)
{
#if defined(UDEV)
...
#else
...
#endif
}
> @@ -1395,8 +1398,10 @@ drm_context_t *drmGetReservedContextList(int fd, int
> *count)
> }
>
> res.contexts = list;
> -if (drmIoctl(fd, DRM_IOCTL_RES_CTX, &res))
> +if (drmIoctl(fd, DRM_IOCTL_RES_CTX, &res)) {
> + drmFree(retval);
> return NULL;
> +}
>
> for (i = 0; i < res.count; i++)
> retval[i] = list[i].handle;
> --
This is not enough. list will leak too.
Make it a separate patch please.
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] targets/xorg-nouveau: add libnvc0.a to nouveau libs
--- src/gallium/targets/xorg-nouveau/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/targets/xorg-nouveau/Makefile b/src/gallium/targets/xorg-nouveau/Makefile index 2fcd9ff..5a2cdb1 100644 --- a/src/gallium/targets/xorg-nouveau/Makefile +++ b/src/gallium/targets/xorg-nouveau/Makefile @@ -15,6 +15,7 @@ DRIVER_PIPES = \ $(TOP)/src/gallium/winsys/nouveau/drm/libnouveaudrm.a \ $(TOP)/src/gallium/drivers/nvfx/libnvfx.a \ $(TOP)/src/gallium/drivers/nv50/libnv50.a \ + $(TOP)/src/gallium/drivers/nvc0/libnvc0.a \ $(TOP)/src/gallium/drivers/nouveau/libnouveau.a \ $(TOP)/src/gallium/drivers/trace/libtrace.a \ $(TOP)/src/gallium/drivers/rbug/librbug.a -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] targets/xorg-nouveau: load nouveau_dri.so instead of i915_dri.so
---
src/gallium/targets/xorg-nouveau/nouveau_xorg.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
index 699af09..f0d6492 100644
--- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
+++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
@@ -136,7 +136,7 @@ nouveau_xorg_pci_probe(DriverPtr driver,
NULL, NULL, NULL, NULL, NULL);
if (scrn != NULL) {
scrn->driverVersion = 1;
- scrn->driverName = "i915";
+ scrn->driverName = "nouveau";
scrn->name = "modesetting";
scrn->Probe = NULL;
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xorg: fix typos
---
src/gallium/state_trackers/xorg/xorg_driver.c |6 +++---
src/gallium/state_trackers/xorg/xorg_exa.c|2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_driver.c
b/src/gallium/state_trackers/xorg/xorg_driver.c
index 19e9bf8..063ae92 100644
--- a/src/gallium/state_trackers/xorg/xorg_driver.c
+++ b/src/gallium/state_trackers/xorg/xorg_driver.c
@@ -831,9 +831,9 @@ drv_screen_init(int scrnIndex, ScreenPtr pScreen, int argc,
char **argv)
#endif
}
-xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"##\n");
-xf86DrvMsg(pScrn->scrnIndex, X_INFO, "# Usefull debugging info follows
#\n");
-xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"##\n");
+xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"#\n");
+xf86DrvMsg(pScrn->scrnIndex, X_INFO, "# Useful debugging info follows
#\n");
+xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"#\n");
xf86DrvMsg(pScrn->scrnIndex, X_INFO, "Using %s backend\n",
ms->screen ? "Gallium3D" : "libkms");
xf86DrvMsg(pScrn->scrnIndex, X_INFO, "2D Acceleration is %s\n",
diff --git a/src/gallium/state_trackers/xorg/xorg_exa.c
b/src/gallium/state_trackers/xorg/xorg_exa.c
index e7d6a93..e1172db 100644
--- a/src/gallium/state_trackers/xorg/xorg_exa.c
+++ b/src/gallium/state_trackers/xorg/xorg_exa.c
@@ -336,7 +336,7 @@ ExaPrepareSolid(PixmapPtr pPixmap, int alu, Pixel
planeMask, Pixel fg)
return FALSE;
if (!exa->pipe)
- XORG_FALLBACK("accle not enabled");
+ XORG_FALLBACK("accel not enabled");
if (!priv || !priv->tex)
XORG_FALLBACK("%s", !priv ? "!priv" : "!priv->tex");
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: don't touch git_sha1.h if sha1 didn't change
Less recompiles... --- bin/extract_git_sha1 |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index e6e6731..fc7bf85 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -1,10 +1,14 @@ #!/bin/sh -touch src/mesa/main/git_sha1.h if which git > /dev/null; then # Extract the 7-digit "short" SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in # src/mesa/main/version.c to put the GIT SHA1 in the GL_VERSION string. git log -n 1 --oneline |\ sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 "git-\1"/' \ - > src/mesa/main/git_sha1.h + > src/mesa/main/git_sha1.h.tmp +if ! diff src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h >/dev/null; then + mv src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h +fi +else +touch src/mesa/main/git_sha1.h fi -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/xorg st/nv50/i915: add PIPE_BIND_CURSOR
We need to distinguish surfaces for mouse cursors from scanouts, because nv50
hardware display engine ignores tiling flags.
i915 seems to have similar needs, so fix it too.
---
src/gallium/drivers/i915/i915_resource_texture.c |6 +-
src/gallium/drivers/nv50/nv50_miptree.c | 11 +--
src/gallium/include/pipe/p_defines.h |1 +
src/gallium/state_trackers/xorg/xorg_crtc.c |1 +
4 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/i915/i915_resource_texture.c
b/src/gallium/drivers/i915/i915_resource_texture.c
index 7816925..7ad191b 100644
--- a/src/gallium/drivers/i915/i915_resource_texture.c
+++ b/src/gallium/drivers/i915/i915_resource_texture.c
@@ -826,11 +826,7 @@ i915_texture_create(struct pipe_screen *screen,
}
/* for scanouts and cursors, cursors arn't scanouts */
-
- /* XXX: use a custom flag for cursors, don't rely on magically
-* guessing that this is Xorg asking for a cursor
-*/
- if ((template->bind & PIPE_BIND_SCANOUT) && template->width0 != 64)
+ if ((template->bind & PIPE_BIND_SCANOUT) && !(template->bind &
PIPE_BIND_CURSOR))
buf_usage = I915_NEW_SCANOUT;
else
buf_usage = I915_NEW_TEXTURE;
diff --git a/src/gallium/drivers/nv50/nv50_miptree.c
b/src/gallium/drivers/nv50/nv50_miptree.c
index 9eeca05..d632e21 100644
--- a/src/gallium/drivers/nv50/nv50_miptree.c
+++ b/src/gallium/drivers/nv50/nv50_miptree.c
@@ -158,7 +158,9 @@ nv50_miptree_create(struct pipe_screen *pscreen,
tile_flags = 0x6000;
break;
default:
- if ((pt->bind & PIPE_BIND_SCANOUT) &&
+ if (pt->bind & PIPE_BIND_CURSOR)
+ tile_flags = 0; /* PDISPLAY does not support tiling */
+ else if ((pt->bind & PIPE_BIND_SCANOUT) &&
util_format_get_blocksizebits(pt->format) == 32)
tile_flags = 0x7a00;
else
@@ -176,7 +178,12 @@ nv50_miptree_create(struct pipe_screen *pscreen,
unsigned blocksize = util_format_get_blocksize(pt->format);
lvl->offset = mt->total_size;
- lvl->tile_mode = get_tile_dims(nbx, nby, d);
+
+ if (tile_flags == 0)
+ lvl->tile_mode = 0;
+ else
+ lvl->tile_mode = get_tile_dims(nbx, nby, d);
+
lvl->pitch = align(nbx * blocksize, NV50_TILE_PITCH(lvl->tile_mode));
mt->total_size += lvl->pitch *
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 431a7fb..ae82baa 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -301,6 +301,7 @@ enum pipe_transfer_usage {
#define PIPE_BIND_TRANSFER_READ(1 << 10) /* get_transfer */
#define PIPE_BIND_STREAM_OUTPUT(1 << 11) /* set_stream_output_buffers
*/
#define PIPE_BIND_CUSTOM (1 << 16) /* state-tracker/winsys
usages */
+#define PIPE_BIND_CURSOR (1 << 17) /* mouse cursor */
/* The first two flags above were previously part of the amorphous
* TEXTURE_USAGE, most of which are now descriptions of the ways a
diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c
b/src/gallium/state_trackers/xorg/xorg_crtc.c
index d751ac1..8eaf414 100644
--- a/src/gallium/state_trackers/xorg/xorg_crtc.c
+++ b/src/gallium/state_trackers/xorg/xorg_crtc.c
@@ -218,6 +218,7 @@ crtc_load_cursor_argb_ga3d(xf86CrtcPtr crtc, CARD32 * image)
memset(&templat, 0, sizeof(templat));
templat.bind |= PIPE_BIND_RENDER_TARGET;
templat.bind |= PIPE_BIND_SCANOUT;
+ templat.bind |= PIPE_BIND_CURSOR;
templat.target = PIPE_TEXTURE_2D;
templat.last_level = 0;
templat.depth0 = 1;
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xorg: remove _modesettingRec.cursor
It's not used for anything useful.
---
src/gallium/state_trackers/xorg/xorg_crtc.c| 13 -
src/gallium/state_trackers/xorg/xorg_driver.c |5 -
src/gallium/state_trackers/xorg/xorg_tracker.h |1 -
3 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c
b/src/gallium/state_trackers/xorg/xorg_crtc.c
index 8eaf414..b8d9474 100644
--- a/src/gallium/state_trackers/xorg/xorg_crtc.c
+++ b/src/gallium/state_trackers/xorg/xorg_crtc.c
@@ -302,21 +302,8 @@ err_bo_destroy:
static void
crtc_load_cursor_argb(xf86CrtcPtr crtc, CARD32 * image)
{
-xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
modesettingPtr ms = modesettingPTR(crtc->scrn);
-/* Older X servers have cursor reference counting bugs leading to use of
- * freed memory and consequently random crashes. Should be fixed as of
- * xserver 1.8, but this workaround shouldn't hurt anyway.
- */
-if (config->cursor)
- config->cursor->refcnt++;
-
-if (ms->cursor)
- FreeCursor(ms->cursor, None);
-
-ms->cursor = config->cursor;
-
if (ms->screen)
crtc_load_cursor_argb_ga3d(crtc, image);
#ifdef HAVE_LIBKMS
diff --git a/src/gallium/state_trackers/xorg/xorg_driver.c
b/src/gallium/state_trackers/xorg/xorg_driver.c
index 063ae92..e338f86 100644
--- a/src/gallium/state_trackers/xorg/xorg_driver.c
+++ b/src/gallium/state_trackers/xorg/xorg_driver.c
@@ -999,11 +999,6 @@ drv_close_screen(int scrnIndex, ScreenPtr pScreen)
modesettingPtr ms = modesettingPTR(pScrn);
CustomizerPtr cust = ms->cust;
-if (ms->cursor) {
- FreeCursor(ms->cursor, None);
- ms->cursor = NULL;
-}
-
if (cust && cust->winsys_screen_close)
cust->winsys_screen_close(cust);
diff --git a/src/gallium/state_trackers/xorg/xorg_tracker.h
b/src/gallium/state_trackers/xorg/xorg_tracker.h
index 664e8c7..e345cd6 100644
--- a/src/gallium/state_trackers/xorg/xorg_tracker.h
+++ b/src/gallium/state_trackers/xorg/xorg_tracker.h
@@ -105,7 +105,6 @@ typedef struct _modesettingRec
Bool noAccel;
Bool SWCursor;
-CursorPtr cursor;
Bool swapThrottling;
Bool dirtyThrottling;
CloseScreenProcPtr CloseScreen;
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xorg: flush after loading the cursor
We need cursor data to land in destination buffer before drmModeSetCursor. It fixes "cursor lag" at least on nv50. --- src/gallium/state_trackers/xorg/xorg_crtc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c b/src/gallium/state_trackers/xorg/xorg_crtc.c index b8d9474..e8ca631 100644 --- a/src/gallium/state_trackers/xorg/xorg_crtc.c +++ b/src/gallium/state_trackers/xorg/xorg_crtc.c @@ -247,6 +247,7 @@ crtc_load_cursor_argb_ga3d(xf86CrtcPtr crtc, CARD32 * image) 64, 64, (void*)image, 64 * 4, 0, 0); ms->ctx->transfer_unmap(ms->ctx, transfer); ms->ctx->transfer_destroy(ms->ctx, transfer); +ms->ctx->flush(ms->ctx, NULL); if (crtc->cursor_shown) drmModeSetCursor(ms->fd, crtcp->drm_crtc->crtc_id, -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] targets/xorg-nouveau: add libnvc0.a to nouveau libs
On Mon, Apr 25, 2011 at 11:57:11PM +0200, Marcin Slusarz wrote: > > --- > src/gallium/targets/xorg-nouveau/Makefile |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/src/gallium/targets/xorg-nouveau/Makefile > b/src/gallium/targets/xorg-nouveau/Makefile > index 2fcd9ff..5a2cdb1 100644 > --- a/src/gallium/targets/xorg-nouveau/Makefile > +++ b/src/gallium/targets/xorg-nouveau/Makefile > @@ -15,6 +15,7 @@ DRIVER_PIPES = \ > $(TOP)/src/gallium/winsys/nouveau/drm/libnouveaudrm.a \ > $(TOP)/src/gallium/drivers/nvfx/libnvfx.a \ > $(TOP)/src/gallium/drivers/nv50/libnv50.a \ > + $(TOP)/src/gallium/drivers/nvc0/libnvc0.a \ > $(TOP)/src/gallium/drivers/nouveau/libnouveau.a \ > $(TOP)/src/gallium/drivers/trace/libtrace.a \ > $(TOP)/src/gallium/drivers/rbug/librbug.a > -- ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] targets/xorg-nouveau: load nouveau_dri.so instead of i915_dri.so
On Mon, Apr 25, 2011 at 11:59:40PM +0200, Marcin Slusarz wrote:
>
> ---
> src/gallium/targets/xorg-nouveau/nouveau_xorg.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> index 699af09..f0d6492 100644
> --- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> +++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> @@ -136,7 +136,7 @@ nouveau_xorg_pci_probe(DriverPtr driver,
> NULL, NULL, NULL, NULL, NULL);
> if (scrn != NULL) {
> scrn->driverVersion = 1;
> - scrn->driverName = "i915";
> + scrn->driverName = "nouveau";
> scrn->name = "modesetting";
> scrn->Probe = NULL;
>
> --
ping
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: don't touch git_sha1.h if sha1 didn't change
On Mon, May 02, 2011 at 06:25:31AM -0700, Dan Nicholson wrote: > On Sun, May 1, 2011 at 2:53 PM, Marcin Slusarz > wrote: > > Less recompiles... > > Good idea. Couple nits. > > > --- > > bin/extract_git_sha1 | 8 ++-- > > 1 files changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 > > index e6e6731..fc7bf85 100755 > > --- a/bin/extract_git_sha1 > > +++ b/bin/extract_git_sha1 > > @@ -1,10 +1,14 @@ > > #!/bin/sh > > -touch src/mesa/main/git_sha1.h > > Instead of moving the touch out to when there's no git, perhaps it > would be better to just touch the file when it doesn't exist. > > [ -f src/mesa/main/git_sha1.h ] || touch src/mesa/main/git_sha1.h > > That way your later diff command won't complain on stdout that one of > the files is missing on a fresh checkout. > > > if which git > /dev/null; then > > # Extract the 7-digit "short" SHA1 for the current HEAD, convert > > # it to a string, and wrap it in a #define. This is used in > > # src/mesa/main/version.c to put the GIT SHA1 in the GL_VERSION string. > > git log -n 1 --oneline |\ > > sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 "git-\1"/' \ > > - > src/mesa/main/git_sha1.h > > + > src/mesa/main/git_sha1.h.tmp > > + if ! diff src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h > > >/dev/null; then > > + mv src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h > > + fi > > I might suggest using "cmp -s" here since it's more suited to what we > want: just says if the files are the same without having to figure out > what's different. > > > +else > > + touch src/mesa/main/git_sha1.h > > fi > > -- I applied your suggestions. Thanks. New patch in reponse to this message. I found one more thing to fix... Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/2] mesa: don't touch git_sha1.h if sha1 didn't change
Less recompiles... --- bin/extract_git_sha1 | 10 -- src/mesa/main/.gitignore |1 + 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index e6e6731..5e635d4 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -1,10 +1,16 @@ #!/bin/sh -touch src/mesa/main/git_sha1.h +if [ ! -f src/mesa/main/git_sha1.h ]; then + touch src/mesa/main/git_sha1.h +fi + if which git > /dev/null; then # Extract the 7-digit "short" SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in # src/mesa/main/version.c to put the GIT SHA1 in the GL_VERSION string. git log -n 1 --oneline |\ sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 "git-\1"/' \ - > src/mesa/main/git_sha1.h + > src/mesa/main/git_sha1.h.tmp +if ! cmp -s src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h; then + mv src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h +fi fi diff --git a/src/mesa/main/.gitignore b/src/mesa/main/.gitignore index e48030e..2575f44 100644 --- a/src/mesa/main/.gitignore +++ b/src/mesa/main/.gitignore @@ -3,3 +3,4 @@ api_exec_es2.c get_es1.c get_es2.c git_sha1.h +git_sha1.h.tmp -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: don't call git if it's not git repository
--- bin/extract_git_sha1 |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index 5e635d4..8283870 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -3,6 +3,10 @@ if [ ! -f src/mesa/main/git_sha1.h ]; then touch src/mesa/main/git_sha1.h fi +if [ ! -d .git ]; then + exit +fi + if which git > /dev/null; then # Extract the 7-digit "short" SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/xorg st/nv50/i915: add PIPE_BIND_CURSOR
On Mon, May 02, 2011 at 03:11:00PM +0200, Daniel Vetter wrote: > On Mon, May 2, 2011 at 2:56 PM, Benjamin Franzke > wrote: > > I think in i915g the CURSOR flag should be used in i9x5_scanout_layout > > for the "special case for cursors" as well, instead of only checking > > only pt->width0 == 64 && pt->height0 == 64. > > Oops, so much for actually re-checking the code. On the other hand, that > part is broken, it needs a >tex->tiling = I915_TILE_NONE; > and perhaps some check that width == height == 64 indeed holds. Then > move it out as the first if clause and it'd start to make sense ... Could you fix it in separate patch? I couldn't even test it... Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: flush after loading the cursor
On Mon, May 02, 2011 at 08:57:25AM +0200, Michel Dänzer wrote:
> On Mon, 2011-05-02 at 00:01 +0200, Marcin Slusarz wrote:
> > We need cursor data to land in destination buffer before drmModeSetCursor.
> > It fixes "cursor lag" at least on nv50.
> > ---
> > src/gallium/state_trackers/xorg/xorg_crtc.c |1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c
> > b/src/gallium/state_trackers/xorg/xorg_crtc.c
> > index b8d9474..e8ca631 100644
> > --- a/src/gallium/state_trackers/xorg/xorg_crtc.c
> > +++ b/src/gallium/state_trackers/xorg/xorg_crtc.c
> > @@ -247,6 +247,7 @@ crtc_load_cursor_argb_ga3d(xf86CrtcPtr crtc, CARD32 *
> > image)
> >64, 64, (void*)image, 64 * 4, 0, 0);
> > ms->ctx->transfer_unmap(ms->ctx, transfer);
> > ms->ctx->transfer_destroy(ms->ctx, transfer);
> > +ms->ctx->flush(ms->ctx, NULL);
> >
> > if (crtc->cursor_shown)
> > drmModeSetCursor(ms->fd, crtcp->drm_crtc->crtc_id,
>
> To guarantee that the data lands before drmModeSetCursor, you'd have to
> take a fence from the flush and finish that as well.
>
Thanks!
Updated patch below.
---
From: Marcin Slusarz
Subject: [PATCH v2] st/xorg: flush after loading the cursor
We need cursor data to land in destination buffer before drmModeSetCursor.
It fixes "cursor lag" on nv50.
---
src/gallium/state_trackers/xorg/xorg_crtc.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c
b/src/gallium/state_trackers/xorg/xorg_crtc.c
index 23970d6..0499ed1 100644
--- a/src/gallium/state_trackers/xorg/xorg_crtc.c
+++ b/src/gallium/state_trackers/xorg/xorg_crtc.c
@@ -210,6 +210,9 @@ crtc_load_cursor_argb_ga3d(xf86CrtcPtr crtc, CARD32 * image)
modesettingPtr ms = modesettingPTR(crtc->scrn);
struct crtc_private *crtcp = crtc->driver_private;
struct pipe_transfer *transfer;
+struct pipe_fence_handle *fence = NULL;
+struct pipe_context *ctx = ms->ctx;
+struct pipe_screen *screen = ms->screen;
if (!crtcp->cursor_tex) {
struct pipe_resource templat;
@@ -230,24 +233,28 @@ crtc_load_cursor_argb_ga3d(xf86CrtcPtr crtc, CARD32 *
image)
memset(&whandle, 0, sizeof(whandle));
whandle.type = DRM_API_HANDLE_TYPE_KMS;
- crtcp->cursor_tex = ms->screen->resource_create(ms->screen,
- &templat);
- ms->screen->resource_get_handle(ms->screen, crtcp->cursor_tex,
&whandle);
+ crtcp->cursor_tex = screen->resource_create(screen, &templat);
+ screen->resource_get_handle(screen, crtcp->cursor_tex, &whandle);
crtcp->cursor_handle = whandle.handle;
}
-transfer = pipe_get_transfer(ms->ctx, crtcp->cursor_tex,
+transfer = pipe_get_transfer(ctx, crtcp->cursor_tex,
0, 0,
PIPE_TRANSFER_WRITE,
0, 0, 64, 64);
-ptr = ms->ctx->transfer_map(ms->ctx, transfer);
+ptr = ctx->transfer_map(ctx, transfer);
util_copy_rect(ptr, crtcp->cursor_tex->format,
transfer->stride, 0, 0,
64, 64, (void*)image, 64 * 4, 0, 0);
-ms->ctx->transfer_unmap(ms->ctx, transfer);
-ms->ctx->transfer_destroy(ms->ctx, transfer);
-ms->ctx->flush(ms->ctx, NULL);
+ctx->transfer_unmap(ctx, transfer);
+ctx->transfer_destroy(ctx, transfer);
+ctx->flush(ctx, &fence);
+
+if (fence) {
+ screen->fence_finish(screen, fence, PIPE_TIMEOUT_INFINITE);
+ screen->fence_reference(screen, &fence, NULL);
+}
if (crtc->cursor_shown)
drmModeSetCursor(ms->fd, crtcp->drm_crtc->crtc_id,
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: flush after loading the cursor
On Tue, May 03, 2011 at 09:40:55AM +0200, Michel Dänzer wrote:
> On Mon, 2011-05-02 at 21:26 +0200, Marcin Slusarz wrote:
> > On Mon, May 02, 2011 at 08:57:25AM +0200, Michel Dänzer wrote:
> > > On Mon, 2011-05-02 at 00:01 +0200, Marcin Slusarz wrote:
> > > > We need cursor data to land in destination buffer before
> > > > drmModeSetCursor.
> > > > It fixes "cursor lag" at least on nv50.
> > > > ---
> > > > src/gallium/state_trackers/xorg/xorg_crtc.c |1 +
> > > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c
> > > > b/src/gallium/state_trackers/xorg/xorg_crtc.c
> > > > index b8d9474..e8ca631 100644
> > > > --- a/src/gallium/state_trackers/xorg/xorg_crtc.c
> > > > +++ b/src/gallium/state_trackers/xorg/xorg_crtc.c
> > > > @@ -247,6 +247,7 @@ crtc_load_cursor_argb_ga3d(xf86CrtcPtr crtc, CARD32
> > > > * image)
> > > >64, 64, (void*)image, 64 * 4, 0, 0);
> > > > ms->ctx->transfer_unmap(ms->ctx, transfer);
> > > > ms->ctx->transfer_destroy(ms->ctx, transfer);
> > > > +ms->ctx->flush(ms->ctx, NULL);
> > > >
> > > > if (crtc->cursor_shown)
> > > > drmModeSetCursor(ms->fd, crtcp->drm_crtc->crtc_id,
> > >
> > > To guarantee that the data lands before drmModeSetCursor, you'd have to
> > > take a fence from the flush and finish that as well.
> > >
> >
> > Thanks!
> >
> > Updated patch below.
>
> Actually, it looks like an incremental patch against the previous
> version. A real updated patch would be better.
Yes. I forgot to join them. Sorry.
>
> > +ctx->transfer_unmap(ctx, transfer);
> > +ctx->transfer_destroy(ctx, transfer);
> > +ctx->flush(ctx, &fence);
> > +
> > +if (fence) {
> > + screen->fence_finish(screen, fence, PIPE_TIMEOUT_INFINITE);
> > + screen->fence_reference(screen, &fence, NULL);
> > +}
>
> This looks good.
Thanks.
New patch below.
---
From: Marcin Slusarz
Subject: [PATCH v3] st/xorg: flush after loading the cursor
We need cursor data to land in destination buffer before drmModeSetCursor.
It fixes "cursor lag" on nv50.
---
src/gallium/state_trackers/xorg/xorg_crtc.c | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c
b/src/gallium/state_trackers/xorg/xorg_crtc.c
index 8eaf414..0499ed1 100644
--- a/src/gallium/state_trackers/xorg/xorg_crtc.c
+++ b/src/gallium/state_trackers/xorg/xorg_crtc.c
@@ -210,6 +210,9 @@ crtc_load_cursor_argb_ga3d(xf86CrtcPtr crtc, CARD32 * image)
modesettingPtr ms = modesettingPTR(crtc->scrn);
struct crtc_private *crtcp = crtc->driver_private;
struct pipe_transfer *transfer;
+struct pipe_fence_handle *fence = NULL;
+struct pipe_context *ctx = ms->ctx;
+struct pipe_screen *screen = ms->screen;
if (!crtcp->cursor_tex) {
struct pipe_resource templat;
@@ -230,23 +233,28 @@ crtc_load_cursor_argb_ga3d(xf86CrtcPtr crtc, CARD32 *
image)
memset(&whandle, 0, sizeof(whandle));
whandle.type = DRM_API_HANDLE_TYPE_KMS;
- crtcp->cursor_tex = ms->screen->resource_create(ms->screen,
- &templat);
- ms->screen->resource_get_handle(ms->screen, crtcp->cursor_tex,
&whandle);
+ crtcp->cursor_tex = screen->resource_create(screen, &templat);
+ screen->resource_get_handle(screen, crtcp->cursor_tex, &whandle);
crtcp->cursor_handle = whandle.handle;
}
-transfer = pipe_get_transfer(ms->ctx, crtcp->cursor_tex,
+transfer = pipe_get_transfer(ctx, crtcp->cursor_tex,
0, 0,
PIPE_TRANSFER_WRITE,
0, 0, 64, 64);
-ptr = ms->ctx->transfer_map(ms->ctx, transfer);
+ptr = ctx->transfer_map(ctx, transfer);
util_copy_rect(ptr, crtcp->cursor_tex->format,
transfer->stride, 0, 0,
64, 64, (void*)image, 64 * 4, 0, 0);
-ms->ctx->transfer_unmap(ms->ctx, transfer);
-ms->ctx->transfer_destroy(ms->ctx, transfer);
+ctx->transfer_unmap(ctx, transfer);
+ctx->transfer_destroy(ctx, transfer);
+ctx->flush(ctx, &fence);
+
+if (fence) {
+ screen->fence_finish(screen, fence, PIPE_TIMEOUT_INFINITE);
+ screen->fence_reference(screen, &fence, NULL);
+}
if (crtc->cursor_shown)
drmModeSetCursor(ms->fd, crtcp->drm_crtc->crtc_id,
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [git pull] extract_git_sha1 changes
The following changes since commit f60235e73a5260f92630ce472e06d8c5c00414fb: r600g: Match alpha ref precision to color format precision. (2011-05-05 21:00:38 +0200) are available in the git repository at: git://github.com/mslusarz/mesa.git gitsha1 Marcin Slusarz (2): mesa: don't touch git_sha1.h if sha1 didn't change mesa: don't call git if it's not git repository bin/extract_git_sha1 | 14 -- src/mesa/main/.gitignore |1 + 2 files changed, 13 insertions(+), 2 deletions(-) :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: don't touch git_sha1.h if sha1 didn't change
Reviewed-by: Dan Nicholson Reviewed-by: Ian Romanick --- bin/extract_git_sha1 | 10 -- src/mesa/main/.gitignore |1 + 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index e6e6731..5e635d4 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -1,10 +1,16 @@ #!/bin/sh -touch src/mesa/main/git_sha1.h +if [ ! -f src/mesa/main/git_sha1.h ]; then + touch src/mesa/main/git_sha1.h +fi + if which git > /dev/null; then # Extract the 7-digit "short" SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in # src/mesa/main/version.c to put the GIT SHA1 in the GL_VERSION string. git log -n 1 --oneline |\ sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 "git-\1"/' \ - > src/mesa/main/git_sha1.h + > src/mesa/main/git_sha1.h.tmp +if ! cmp -s src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h; then + mv src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h +fi fi diff --git a/src/mesa/main/.gitignore b/src/mesa/main/.gitignore index e48030e..2575f44 100644 --- a/src/mesa/main/.gitignore +++ b/src/mesa/main/.gitignore @@ -3,3 +3,4 @@ api_exec_es2.c get_es1.c get_es2.c git_sha1.h +git_sha1.h.tmp -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: don't call git if it's not git repository
Reviewed-by: Dan Nicholson Reviewed-by: Ian Romanick --- bin/extract_git_sha1 |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index 5e635d4..8283870 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -3,6 +3,10 @@ if [ ! -f src/mesa/main/git_sha1.h ]; then touch src/mesa/main/git_sha1.h fi +if [ ! -d .git ]; then + exit +fi + if which git > /dev/null; then # Extract the 7-digit "short" SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/xorg st/nv50/i915: add PIPE_BIND_CURSOR
On Tue, May 03, 2011 at 12:06:33PM +0200, Daniel Vetter wrote: > On Mon, May 2, 2011 at 8:40 PM, Marcin Slusarz > wrote: > > On Mon, May 02, 2011 at 03:11:00PM +0200, Daniel Vetter wrote: > >> On Mon, May 2, 2011 at 2:56 PM, Benjamin Franzke > >> wrote: > >> > I think in i915g the CURSOR flag should be used in i9x5_scanout_layout > >> > for the "special case for cursors" as well, instead of only checking > >> > only pt->width0 == 64 && pt->height0 == 64. > >> > >> Oops, so much for actually re-checking the code. On the other hand, that > >> part is broken, it needs a > >> tex->tiling = I915_TILE_NONE; > >> and perhaps some check that width == height == 64 indeed holds. Then > >> move it out as the first if clause and it'd start to make sense ... > > > > Could you fix it in separate patch? > > Jakob has said (on irc) that he intends to again play with xorg-i915g ... Christoph commited generic and nv50 part (Thanks again!). i915 part below. --- From: Marcin Slusarz Subject: [PATCH] i915: use PIPE_BIND_CURSOR --- src/gallium/drivers/i915/i915_resource_texture.c |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/src/gallium/drivers/i915/i915_resource_texture.c b/src/gallium/drivers/i915/i915_resource_texture.c index e05b059..97ac012 100644 --- a/src/gallium/drivers/i915/i915_resource_texture.c +++ b/src/gallium/drivers/i915/i915_resource_texture.c @@ -825,11 +825,7 @@ i915_texture_create(struct pipe_screen *screen, } /* for scanouts and cursors, cursors arn't scanouts */ - - /* XXX: use a custom flag for cursors, don't rely on magically -* guessing that this is Xorg asking for a cursor -*/ - if ((template->bind & PIPE_BIND_SCANOUT) && template->width0 != 64) + if ((template->bind & PIPE_BIND_SCANOUT) && !(template->bind & PIPE_BIND_CURSOR)) buf_usage = I915_NEW_SCANOUT; else buf_usage = I915_NEW_TEXTURE; -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/nouveau: remove unused nouveau_screen_bo_user
---
src/gallium/drivers/nouveau/nouveau_screen.c | 14 --
src/gallium/drivers/nouveau/nouveau_screen.h |2 --
2 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c
b/src/gallium/drivers/nouveau/nouveau_screen.c
index 401155b..223e768 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -81,20 +81,6 @@ nouveau_screen_bo_new(struct pipe_screen *pscreen, unsigned
alignment,
return bo;
}
-struct nouveau_bo *
-nouveau_screen_bo_user(struct pipe_screen *pscreen, void *ptr, unsigned bytes)
-{
- struct nouveau_device *dev = nouveau_screen(pscreen)->device;
- struct nouveau_bo *bo = NULL;
- int ret;
-
- ret = nouveau_bo_user(dev, ptr, bytes, &bo);
- if (ret)
- return NULL;
-
- return bo;
-}
-
void *
nouveau_screen_bo_map(struct pipe_screen *pscreen,
struct nouveau_bo *bo,
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.h
b/src/gallium/drivers/nouveau/nouveau_screen.h
index 186ada3..d910809 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.h
+++ b/src/gallium/drivers/nouveau/nouveau_screen.h
@@ -47,8 +47,6 @@ nouveau_screen(struct pipe_screen *pscreen)
struct nouveau_bo *
nouveau_screen_bo_new(struct pipe_screen *pscreen, unsigned alignment,
unsigned usage, unsigned bind, unsigned size);
-struct nouveau_bo *
-nouveau_screen_bo_user(struct pipe_screen *pscreen, void *ptr, unsigned bytes);
void *
nouveau_screen_bo_map(struct pipe_screen *pscreen,
struct nouveau_bo *pb,
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] st/xorg: fix compilation of xorg_exa.c with DEBUG_PRINT set to 1
---
src/gallium/state_trackers/xorg/xorg_exa.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_exa.c
b/src/gallium/state_trackers/xorg/xorg_exa.c
index 91c206f..fe843fe 100644
--- a/src/gallium/state_trackers/xorg/xorg_exa.c
+++ b/src/gallium/state_trackers/xorg/xorg_exa.c
@@ -584,19 +584,17 @@ ExaCheckComposite(int op,
ScrnInfoPtr pScrn = xf86Screens[pDstPicture->pDrawable->pScreen->myNum];
modesettingPtr ms = modesettingPTR(pScrn);
struct exa_context *exa = ms->exa;
+ Bool accelerated = exa->accel && xorg_composite_accelerated(op,
+pSrcPicture,
+pMaskPicture,
+pDstPicture);
#if DEBUG_PRINT
debug_printf("ExaCheckComposite(%d, %p, %p, %p) = %d\n",
op, pSrcPicture, pMaskPicture, pDstPicture, accelerated);
#endif
- if (!exa->accel)
- return FALSE;
-
- return xorg_composite_accelerated(op,
-pSrcPicture,
-pMaskPicture,
-pDstPicture);
+ return accelerated;
}
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] st/xorg: remove DEBUG_PRINT macro and add exa_debug_printf
Localizes preprocessor usage to one place.
---
src/gallium/state_trackers/xorg/xorg_exa.c | 59 ++--
1 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_exa.c
b/src/gallium/state_trackers/xorg/xorg_exa.c
index fe843fe..60a1ef9 100644
--- a/src/gallium/state_trackers/xorg/xorg_exa.c
+++ b/src/gallium/state_trackers/xorg/xorg_exa.c
@@ -49,9 +49,24 @@
#include "util/u_box.h"
#include "util/u_surface.h"
-#define DEBUG_PRINT 0
#define ROUND_UP_TEXTURES 1
+static INLINE void
+exa_debug_printf(const char *format, ...) _util_printf_format(1,2);
+
+static INLINE void
+exa_debug_printf(const char *format, ...)
+{
+#if 0
+ va_list ap;
+ va_start(ap, format);
+ _debug_vprintf(format, ap);
+ va_end(ap);
+#else
+ (void) format; /* silence warning */
+#endif
+}
+
/*
* Helper functions
*/
@@ -195,10 +210,8 @@ ExaDownloadFromScreen(PixmapPtr pPix, int x, int y, int
w, int h, char *dst,
if (!transfer)
return FALSE;
-#if DEBUG_PRINT
-debug_printf("-- ExaDownloadFromScreen(%d, %d, %d, %d, %d)\n",
+exa_debug_printf("-- ExaDownloadFromScreen(%d, %d, %d, %d, %d)\n",
x, y, w, h, dst_pitch);
-#endif
util_copy_rect((unsigned char*)dst, priv->tex->format, dst_pitch, 0, 0,
w, h, exa->pipe->transfer_map(exa->pipe, transfer),
@@ -229,10 +242,8 @@ ExaUploadToScreen(PixmapPtr pPix, int x, int y, int w, int
h, char *src,
if (!transfer)
return FALSE;
-#if DEBUG_PRINT
-debug_printf("++ ExaUploadToScreen(%d, %d, %d, %d, %d)\n",
+exa_debug_printf("++ ExaUploadToScreen(%d, %d, %d, %d, %d)\n",
x, y, w, h, src_pitch);
-#endif
util_copy_rect(exa->pipe->transfer_map(exa->pipe, transfer),
priv->tex->format, transfer->stride, 0, 0, w, h,
@@ -329,9 +340,8 @@ ExaPrepareSolid(PixmapPtr pPixmap, int alu, Pixel
planeMask, Pixel fg)
struct exa_pixmap_priv *priv = exaGetPixmapDriverPrivate(pPixmap);
struct exa_context *exa = ms->exa;
-#if DEBUG_PRINT
-debug_printf("ExaPrepareSolid(0x%x)\n", fg);
-#endif
+exa_debug_printf("ExaPrepareSolid(0x%x)\n", fg);
+
if (!exa->accel)
return FALSE;
@@ -364,9 +374,7 @@ ExaSolid(PixmapPtr pPixmap, int x0, int y0, int x1, int y1)
struct exa_context *exa = ms->exa;
struct exa_pixmap_priv *priv = exaGetPixmapDriverPrivate(pPixmap);
-#if DEBUG_PRINT
-debug_printf("\tExaSolid(%d, %d, %d, %d)\n", x0, y0, x1, y1);
-#endif
+exa_debug_printf("\tExaSolid(%d, %d, %d, %d)\n", x0, y0, x1, y1);
if (x0 == 0 && y0 == 0 &&
x1 == pPixmap->drawable.width && y1 == pPixmap->drawable.height) {
@@ -406,9 +414,7 @@ ExaPrepareCopy(PixmapPtr pSrcPixmap, PixmapPtr pDstPixmap,
int xdir,
struct exa_pixmap_priv *priv = exaGetPixmapDriverPrivate(pDstPixmap);
struct exa_pixmap_priv *src_priv = exaGetPixmapDriverPrivate(pSrcPixmap);
-#if DEBUG_PRINT
-debug_printf("ExaPrepareCopy\n");
-#endif
+exa_debug_printf("ExaPrepareCopy\n");
if (!exa->accel)
return FALSE;
@@ -488,10 +494,8 @@ ExaCopy(PixmapPtr pDstPixmap, int srcX, int srcY, int
dstX, int dstY,
struct exa_context *exa = ms->exa;
struct exa_pixmap_priv *priv = exaGetPixmapDriverPrivate(pDstPixmap);
-#if DEBUG_PRINT
- debug_printf("\tExaCopy(srcx=%d, srcy=%d, dstX=%d, dstY=%d, w=%d, h=%d)\n",
+ exa_debug_printf("\tExaCopy(srcx=%d, srcy=%d, dstX=%d, dstY=%d, w=%d,
h=%d)\n",
srcX, srcY, dstX, dstY, width, height);
-#endif
debug_assert(priv == exa->copy.dst);
(void) priv;
@@ -589,10 +593,8 @@ ExaCheckComposite(int op,
pMaskPicture,
pDstPicture);
-#if DEBUG_PRINT
- debug_printf("ExaCheckComposite(%d, %p, %p, %p) = %d\n",
+ exa_debug_printf("ExaCheckComposite(%d, %p, %p, %p) = %d\n",
op, pSrcPicture, pMaskPicture, pDstPicture, accelerated);
-#endif
return accelerated;
}
@@ -611,14 +613,13 @@ ExaPrepareComposite(int op, PicturePtr pSrcPicture,
if (!exa->accel)
return FALSE;
-#if DEBUG_PRINT
- debug_printf("ExaPrepareComposite(%d, src=0x%p, mask=0x%p, dst=0x%p)\n",
+ exa_debug_printf("ExaPrepareComposite(%d, src=0x%p, mask=0x%p, dst=0x%p)\n",
op, pSrcPicture, pMaskPicture, pDstPicture);
- debug_printf("\tFormats: src(%s), mask(%s), dst(%s)\n",
+ exa_debug_printf("\tFormats: src(%s), mask(%s), dst(%s)\n",
pSrcPicture ? render_format_name(pSrcPicture->format) : "none",
pMaskPicture ? render_format_name(pMaskPicture->format) :
"none",
pDstPicture ? render_format_name(pDstPicture->format) :
"none");
-#endif
+
if (!exa->pipe)
XORG_FALLBACK("accel not enabled");
@@ -685,12 +686,10 @@ ExaComposite(PixmapPtr pDst, int srcX, int srcY, int
maskX, int maskY,
struct exa_context *exa = ms->exa;
struct exa_pixm
[Mesa-dev] [PATCH 3/3] st/xorg: add some debugging messages to xorg_exa.c
---
src/gallium/state_trackers/xorg/xorg_exa.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_exa.c
b/src/gallium/state_trackers/xorg/xorg_exa.c
index 60a1ef9..b072f53 100644
--- a/src/gallium/state_trackers/xorg/xorg_exa.c
+++ b/src/gallium/state_trackers/xorg/xorg_exa.c
@@ -272,6 +272,8 @@ ExaPrepareAccess(PixmapPtr pPix, int index)
if (!priv->tex)
return FALSE;
+exa_debug_printf("ExaPrepareAccess %d\n", index);
+
if (priv->map_count == 0)
{
assert(pPix->drawable.width <= priv->tex->width0);
@@ -300,6 +302,8 @@ ExaPrepareAccess(PixmapPtr pPix, int index)
priv->map_count++;
+exa_debug_printf("ExaPrepareAccess %d prepared\n", index);
+
return TRUE;
}
@@ -319,6 +323,8 @@ ExaFinishAccess(PixmapPtr pPix, int index)
if (!priv->map_transfer)
return;
+exa_debug_printf("ExaFinishAccess %d\n", index);
+
if (--priv->map_count == 0) {
assert(priv->map_transfer);
exa->pipe->transfer_unmap(exa->pipe, priv->map_transfer);
@@ -326,6 +332,8 @@ ExaFinishAccess(PixmapPtr pPix, int index)
priv->map_transfer = NULL;
pPix->devPrivate.ptr = NULL;
}
+
+exa_debug_printf("ExaFinishAccess %d finished\n", index);
}
/***
@@ -396,8 +404,10 @@ ExaDoneSolid(PixmapPtr pPixmap)
if (!priv)
return;
-
+
+exa_debug_printf("ExaDoneSolid\n");
xorg_composite_done(exa);
+exa_debug_printf("ExaDoneSolid done\n");
}
/***
@@ -531,12 +541,16 @@ ExaDoneCopy(PixmapPtr pPixmap)
if (!priv)
return;
+ exa_debug_printf("ExaDoneCopy\n");
+
renderer_draw_flush(exa->renderer);
exa->copy.src = NULL;
exa->copy.dst = NULL;
pipe_surface_reference(&exa->copy.dst_surface, NULL);
pipe_resource_reference(&exa->copy.src_texture, NULL);
+
+ exa_debug_printf("ExaDoneCopy done\n");
}
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50/nvc0: make transfers aware of PIPE_TRANSFER_MAP_DIRECTLY
If state tracker asked us to map resource directly and we can't
do it (because of tiling), return NULL instead of doing full transfer
- state tracker should handle it and fallback to some other method
or repeat transfer without PIPE_TRANSFER_MAP_DIRECTLY.
It greatly improves performance of xorg state tracker on nv50+,
because fallback (DFS/UTS) is much faster than full transfer.
---
src/gallium/drivers/nv50/nv50_transfer.c | 31 +++-
src/gallium/drivers/nvc0/nvc0_transfer.c | 32 -
2 files changed, 43 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_transfer.c
b/src/gallium/drivers/nv50/nv50_transfer.c
index 7486977..13ac372 100644
--- a/src/gallium/drivers/nv50/nv50_transfer.c
+++ b/src/gallium/drivers/nv50/nv50_transfer.c
@@ -209,6 +209,10 @@ nv50_miptree_transfer_new(struct pipe_context *pctx,
uint32_t w, h, d, z, layer;
int ret;
+ if ((usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
+ nouveau_bo_tile_layout(mt->base.bo))
+ return NULL;
+
if (mt->layout_3d) {
z = box->z;
d = u_minify(res->depth0, level);
@@ -252,6 +256,11 @@ nv50_miptree_transfer_new(struct pipe_context *pctx,
tx->rect[0].pitch = lvl->pitch;
tx->rect[0].domain = NOUVEAU_BO_VRAM;
+ if (usage & PIPE_TRANSFER_MAP_DIRECTLY) {
+ tx->rect[1] = tx->rect[0];
+ return &tx->base;
+ }
+
size = tx->base.layer_stride;
ret = nouveau_bo_new(dev, NOUVEAU_BO_GART | NOUVEAU_BO_MAP, 0,
@@ -296,19 +305,21 @@ nv50_miptree_transfer_del(struct pipe_context *pctx,
struct nv50_miptree *mt = nv50_miptree(tx->base.resource);
unsigned i;
- if (tx->base.usage & PIPE_TRANSFER_WRITE) {
- for (i = 0; i < tx->base.box.depth; ++i) {
- nv50_m2mf_transfer_rect(pscreen, &tx->rect[0], &tx->rect[1],
- tx->nblocksx, tx->nblocksy);
- if (mt->layout_3d)
-tx->rect[0].z++;
- else
-tx->rect[0].base += mt->layer_stride;
- tx->rect[1].base += tx->nblocksy * tx->base.stride;
+ if (!(tx->base.usage & PIPE_TRANSFER_MAP_DIRECTLY)) {
+ if (tx->base.usage & PIPE_TRANSFER_WRITE) {
+ for (i = 0; i < tx->base.box.depth; ++i) {
+nv50_m2mf_transfer_rect(pscreen, &tx->rect[0], &tx->rect[1],
+tx->nblocksx, tx->nblocksy);
+if (mt->layout_3d)
+ tx->rect[0].z++;
+else
+ tx->rect[0].base += mt->layer_stride;
+tx->rect[1].base += tx->nblocksy * tx->base.stride;
+ }
}
+ nouveau_bo_ref(NULL, &tx->rect[1].bo);
}
- nouveau_bo_ref(NULL, &tx->rect[1].bo);
pipe_resource_reference(&transfer->resource, NULL);
FREE(tx);
diff --git a/src/gallium/drivers/nvc0/nvc0_transfer.c
b/src/gallium/drivers/nvc0/nvc0_transfer.c
index 7bbfe05..6a2721c 100644
--- a/src/gallium/drivers/nvc0/nvc0_transfer.c
+++ b/src/gallium/drivers/nvc0/nvc0_transfer.c
@@ -246,6 +246,10 @@ nvc0_miptree_transfer_new(struct pipe_context *pctx,
uint32_t w, h, d, z, layer;
int ret;
+ if ((usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
+ nouveau_bo_tile_layout(mt->base.bo))
+ return NULL;
+
tx = CALLOC_STRUCT(nvc0_transfer);
if (!tx)
return NULL;
@@ -290,6 +294,11 @@ nvc0_miptree_transfer_new(struct pipe_context *pctx,
tx->rect[0].pitch = lvl->pitch;
tx->rect[0].domain = NOUVEAU_BO_VRAM;
+ if (usage & PIPE_TRANSFER_MAP_DIRECTLY) {
+ tx->rect[1] = tx->rect[0];
+ return &tx->base;
+ }
+
size = tx->base.layer_stride;
ret = nouveau_bo_new(dev, NOUVEAU_BO_GART | NOUVEAU_BO_MAP, 0,
@@ -334,19 +343,22 @@ nvc0_miptree_transfer_del(struct pipe_context *pctx,
struct nvc0_miptree *mt = nvc0_miptree(tx->base.resource);
unsigned i;
- if (tx->base.usage & PIPE_TRANSFER_WRITE) {
- for (i = 0; i < tx->nlayers; ++i) {
- nvc0_m2mf_transfer_rect(pscreen, &tx->rect[0], &tx->rect[1],
- tx->nblocksx, tx->nblocksy);
- if (mt->layout_3d)
-tx->rect[0].z++;
- else
-tx->rect[0].base += mt->layer_stride;
- tx->rect[1].base += tx->nblocksy * tx->base.stride;
+ if (!(tx->base.usage & PIPE_TRANSFER_MAP_DIRECTLY)) {
+ if (tx->base.usage & PIPE_TRANSFER_WRITE) {
+ for (i = 0; i < tx->nlayers; ++i) {
+nvc0_m2mf_transfer_rect(pscreen, &tx->rect[0], &tx->rect[1],
+tx->nblocksx, tx->nblocksy);
+if (mt->layout_3d)
+ tx->rect[0].z++;
+else
+ tx->rect[0].base += mt->layer_stride;
+tx->rect[1].base += tx->nblocksy * tx->base.stride;
+ }
}
+
+ nouveau_bo_ref(NULL, &tx->rect[1].bo);
}
- nouveau_bo_ref(NULL, &tx->rect[1].bo);
pipe_resource_reference(&transfer->resource, NULL);
FREE(tx);
--
1.7.4.1
__
[Mesa-dev] [PATCH v2] nv50/nvc0: make transfers aware of PIPE_TRANSFER_MAP_DIRECTLY
If state tracker asked us to map resource directly and we can't
do it (because of tiling), return NULL instead of doing full transfer
- state tracker should handle it and fallback to some other method
or repeat transfer without PIPE_TRANSFER_MAP_DIRECTLY.
It greatly improves performance of xorg state tracker on nv50+,
because its fallback (DFS/UTS) is much faster than full transfer.
---
src/gallium/drivers/nv50/nv50_transfer.c |3 +++
src/gallium/drivers/nvc0/nvc0_transfer.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_transfer.c
b/src/gallium/drivers/nv50/nv50_transfer.c
index 7486977..d9fb22aa 100644
--- a/src/gallium/drivers/nv50/nv50_transfer.c
+++ b/src/gallium/drivers/nv50/nv50_transfer.c
@@ -209,6 +209,9 @@ nv50_miptree_transfer_new(struct pipe_context *pctx,
uint32_t w, h, d, z, layer;
int ret;
+ if (usage & PIPE_TRANSFER_MAP_DIRECTLY)
+ return NULL;
+
if (mt->layout_3d) {
z = box->z;
d = u_minify(res->depth0, level);
diff --git a/src/gallium/drivers/nvc0/nvc0_transfer.c
b/src/gallium/drivers/nvc0/nvc0_transfer.c
index 7bbfe05..0509113 100644
--- a/src/gallium/drivers/nvc0/nvc0_transfer.c
+++ b/src/gallium/drivers/nvc0/nvc0_transfer.c
@@ -246,6 +246,9 @@ nvc0_miptree_transfer_new(struct pipe_context *pctx,
uint32_t w, h, d, z, layer;
int ret;
+ if (usage & PIPE_TRANSFER_MAP_DIRECTLY)
+ return NULL;
+
tx = CALLOC_STRUCT(nvc0_transfer);
if (!tx)
return NULL;
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] xorg/nouveau: blacklist all pre NV30 cards
Bail out early in probe, so other driver can take control of the card.
Doing it in screen_create would be too late.
PCIID list taken from xf86-video-nv, so it's probably complete.
---
src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 100 +--
1 files changed, 93 insertions(+), 7 deletions(-)
diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
index a25254a..6d3b8f2 100644
--- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
+++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
@@ -43,11 +43,6 @@ static const struct pci_id_match nouveau_xorg_device_match[]
= {
{0, 0, 0},
};
-static SymTabRec nouveau_xorg_chipsets[] = {
-{PCI_MATCH_ANY, "NVIDIA Graphics Device"},
-{-1, NULL}
-};
-
static PciChipsets nouveau_xorg_pci_devices[] = {
{PCI_MATCH_ANY, PCI_MATCH_ANY, NULL},
{-1, -1, NULL}
@@ -121,16 +116,107 @@ nouveau_xorg_setup(pointer module, pointer opts, int
*errmaj, int *errmin)
static void
nouveau_xorg_identify(int flags)
{
-xf86PrintChipsets("nouveau2", "Driver for Modesetting Kernel Drivers",
- nouveau_xorg_chipsets);
+xf86DrvMsg(0, X_INFO, "nouveau2: Gallium3D based 2D driver for NV30+
NVIDIA chipsets\n");
}
+/* List of cards we DO NOT SUPPORT. */
+static SymTabRec NVPreNV30Chipsets[] =
+{
+ { 0x12D20018, "RIVA 128" },
+
+ { 0x10DE0020, "RIVA TNT" },
+
+ { 0x10DE0028, "RIVA TNT2" },
+ { 0x10DE002A, "Unknown TNT2" },
+ { 0x10DE002C, "Vanta" },
+ { 0x10DE0029, "RIVA TNT2 Ultra" },
+ { 0x10DE002D, "RIVA TNT2 Model 64" },
+
+ { 0x10DE00A0, "Aladdin TNT2" },
+
+ { 0x10DE0100, "GeForce 256" },
+ { 0x10DE0101, "GeForce DDR" },
+ { 0x10DE0103, "Quadro" },
+
+ { 0x10DE0110, "GeForce2 MX/MX 400" },
+ { 0x10DE0111, "GeForce2 MX 100/200" },
+ { 0x10DE0112, "GeForce2 Go" },
+ { 0x10DE0113, "Quadro2 MXR/EX/Go" },
+
+ { 0x10DE01A0, "GeForce2 Integrated GPU" },
+
+ { 0x10DE0150, "GeForce2 GTS" },
+ { 0x10DE0151, "GeForce2 Ti" },
+ { 0x10DE0152, "GeForce2 Ultra" },
+ { 0x10DE0153, "Quadro2 Pro" },
+
+ { 0x10DE0170, "GeForce4 MX 460" },
+ { 0x10DE0171, "GeForce4 MX 440" },
+ { 0x10DE0172, "GeForce4 MX 420" },
+ { 0x10DE0173, "GeForce4 MX 440-SE" },
+ { 0x10DE0174, "GeForce4 440 Go" },
+ { 0x10DE0175, "GeForce4 420 Go" },
+ { 0x10DE0176, "GeForce4 420 Go 32M" },
+ { 0x10DE0177, "GeForce4 460 Go" },
+ { 0x10DE0178, "Quadro4 550 XGL" },
+ { 0x10DE0179, "GeForce4 MX (Mac) / 440 Go 64M" },
+ { 0x10DE017A, "Quadro NVS" },
+ { 0x10DE017C, "Quadro4 500 GoGL" },
+ { 0x10DE017D, "GeForce4 410 Go 16M" },
+
+ { 0x10DE0181, "GeForce4 MX 440 with AGP8X" },
+ { 0x10DE0182, "GeForce4 MX 440SE with AGP8X" },
+ { 0x10DE0183, "GeForce4 MX 420 with AGP8X" },
+ { 0x10DE0185, "GeForce4 MX 4000" },
+ { 0x10DE0186, "GeForce4 448 Go" },
+ { 0x10DE0187, "GeForce4 488 Go" },
+ { 0x10DE0188, "Quadro4 580 XGL" },
+ { 0x10DE0189, "GeForce4 MX with AGP8X (Mac)" },
+ { 0x10DE018A, "Quadro4 NVS 280 SD" },
+ { 0x10DE018B, "Quadro4 380 XGL" },
+ { 0x10DE018C, "Quadro NVS 50 PCI" },
+ { 0x10DE018D, "GeForce4 448 Go" },
+
+ { 0x10DE01F0, "GeForce4 MX Integrated GPU" },
+
+ { 0x10DE0200, "GeForce3" },
+ { 0x10DE0201, "GeForce3 Ti 200" },
+ { 0x10DE0202, "GeForce3 Ti 500" },
+ { 0x10DE0203, "Quadro DCC" },
+
+ { 0x10DE0250, "GeForce4 Ti 4600" },
+ { 0x10DE0251, "GeForce4 Ti 4400" },
+ { 0x10DE0253, "GeForce4 Ti 4200" },
+ { 0x10DE0258, "Quadro4 900 XGL" },
+ { 0x10DE0259, "Quadro4 750 XGL" },
+ { 0x10DE025B, "Quadro4 700 XGL" },
+
+ { 0x10DE0280, "GeForce4 Ti 4800" },
+ { 0x10DE0281, "GeForce4 Ti 4200 with AGP8X" },
+ { 0x10DE0282, "GeForce4 Ti 4800 SE" },
+ { 0x10DE0286, "GeForce4 4200 Go" },
+ { 0x10DE028C, "Quadro4 700 GoGL" },
+ { 0x10DE0288, "Quadro4 980 XGL" },
+ { 0x10DE0289, "Quadro4 780 XGL" },
+
+ {-1, NULL}
+};
+
+
static Bool
nouveau_xorg_pci_probe(DriverPtr driver,
int entity_num, struct pci_device *device, intptr_t match_data)
{
ScrnInfoPtr scrn = NULL;
EntityInfoPtr entity;
+SymTabRec *cur;
+
+int pciid = device->vendor_id << 16 | device->device_id;
+
+for (cur = &NVPreNV30Chipsets[0]; cur->token != -1; cur++) {
+ if (cur->token == pciid)
+ return FALSE;
+}
scrn = xf86ConfigPciEntity(scrn, 0, entity_num, nouveau_xorg_pci_devices,
NULL, NULL, NULL, NULL, NULL);
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills
It's a hack, but it allows rendercheck to pass all fill and most blend tests.
(without it all blend tests failed)
---
src/gallium/state_trackers/xorg/xorg_composite.c | 70 +++---
src/gallium/state_trackers/xorg/xorg_composite.h |6 +-
src/gallium/state_trackers/xorg/xorg_exa.c | 16 +-
3 files changed, 66 insertions(+), 26 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_composite.c
b/src/gallium/state_trackers/xorg/xorg_composite.c
index d4dc84a..cadec59 100644
--- a/src/gallium/state_trackers/xorg/xorg_composite.c
+++ b/src/gallium/state_trackers/xorg/xorg_composite.c
@@ -51,19 +51,53 @@ static const struct xorg_composite_blend xorg_blends[] = {
};
-static INLINE void
-pixel_to_float4(Pixel pixel, float *color)
+boolean xorg_pixel_to_float4(Pixel pixel, unsigned char bpp,
+ unsigned char depth, float *color)
{
CARD32 r, g, b, a;
- a = (pixel >> 24) & 0xff;
- r = (pixel >> 16) & 0xff;
- g = (pixel >> 8) & 0xff;
- b = (pixel >> 0) & 0xff;
- color[0] = ((float)r) / 255.;
- color[1] = ((float)g) / 255.;
- color[2] = ((float)b) / 255.;
- color[3] = ((float)a) / 255.;
+ if (depth == 32) {
+ a = (pixel >> 24) & 0xff;
+ r = (pixel >> 16) & 0xff;
+ g = (pixel >> 8) & 0xff;
+ b = (pixel >> 0) & 0xff;
+ color[0] = ((float)r) / 255.;
+ color[1] = ((float)g) / 255.;
+ color[2] = ((float)b) / 255.;
+ color[3] = ((float)a) / 255.;
+ } else if (depth == 24) {
+ r = (pixel >> 16) & 0xff;
+ g = (pixel >> 8) & 0xff;
+ b = (pixel >> 0) & 0xff;
+ color[0] = ((float)r) / 255.;
+ color[1] = ((float)g) / 255.;
+ color[2] = ((float)b) / 255.;
+ color[3] = 0;
+ } else if (depth == 8) {
+ r = pixel & 0xff;
+ color[0] = ((float)r) / 255.;
+ color[1] = 0;
+ color[2] = 0;
+ color[3] = 0;
+ } else if (depth == 16) {
+ r = (pixel >> 11) & 0x1f;
+ g = (pixel >> 5) & 0x3f;
+ b = (pixel >> 0) & 0x1f;
+ color[0] = ((float)r) / 31.;
+ color[1] = ((float)g) / 63.;
+ color[2] = ((float)b) / 31.;
+ color[3] = 0;
+ } else if (depth == 15) {
+ r = (pixel >> 10) & 0x1f;
+ g = (pixel >> 5) & 0x1f;
+ b = (pixel >> 0) & 0x1f;
+ color[0] = ((float)r) / 31.;
+ color[1] = ((float)g) / 31.;
+ color[2] = ((float)b) / 31.;
+ color[3] = 0;
+ } else
+ return FALSE;
+ return TRUE;
}
static boolean
@@ -310,8 +344,8 @@ bind_shaders(struct exa_context *exa, int op,
fs_traits |= FS_SOLID_FILL;
vs_traits |= VS_SOLID_FILL;
debug_assert(pSrcPicture->format == PICT_a8r8g8b8);
-pixel_to_float4(pSrcPicture->pSourcePict->solidFill.color,
-exa->solid_color);
+xorg_pixel_to_float4(pSrcPicture->pSourcePict->solidFill.color,
+32, 32, exa->solid_color);
exa->has_solid_color = TRUE;
} else {
debug_assert("!gradients not supported");
@@ -526,24 +560,14 @@ void xorg_composite(struct exa_context *exa,
}
boolean xorg_solid_bind_state(struct exa_context *exa,
- struct exa_pixmap_priv *pixmap,
- Pixel fg)
+ struct exa_pixmap_priv *pixmap)
{
struct pipe_surface *dst_surf = xorg_gpu_surface(exa->pipe, pixmap);
unsigned vs_traits, fs_traits;
struct xorg_shader shader;
- pixel_to_float4(fg, exa->solid_color);
exa->has_solid_color = TRUE;
-#if 0
- debug_printf("Color Pixel=(%d, %d, %d, %d), RGBA=(%f, %f, %f, %f)\n",
-(fg >> 24) & 0xff, (fg >> 16) & 0xff,
-(fg >> 8) & 0xff, (fg >> 0) & 0xff,
-exa->solid_color[0], exa->solid_color[1],
-exa->solid_color[2], exa->solid_color[3]);
-#endif
-
vs_traits = VS_SOLID_FILL;
fs_traits = FS_SOLID_FILL;
diff --git a/src/gallium/state_trackers/xorg/xorg_composite.h
b/src/gallium/state_trackers/xorg/xorg_composite.h
index ec71ebf..a83fec1 100644
--- a/src/gallium/state_trackers/xorg/xorg_composite.h
+++ b/src/gallium/state_trackers/xorg/xorg_composite.h
@@ -22,9 +22,11 @@ void xorg_composite(struct exa_context *exa,
int srcX, int srcY, int maskX, int maskY,
int dstX, int dstY, int width, int height);
+boolean xorg_pixel_to_float4(Pixel pixel, unsigned char bpp,
+unsigned char depth, float *color);
+
boolean xorg_solid_bind_state(struct exa_context *exa,
- struct exa_pixmap_priv *pixmap,
- Pixel fg);
+ struct exa_pixmap_priv *pixmap);
void xorg_solid(struct exa_context *exa,
struct exa_pixmap_priv *pixmap,
int x0, int y0, int x1, int y1);
diff --git a/src/gallium/state_trackers/xorg/xorg_exa.c
b/src/gallium
[Mesa-dev] [PATCH] st/xorg: fix crash triggered by rendercheck -t blend -f a8r8g8b8 -o Clear
---
src/gallium/state_trackers/xorg/xorg_composite.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_composite.c
b/src/gallium/state_trackers/xorg/xorg_composite.c
index cadec59..9fdbc90 100644
--- a/src/gallium/state_trackers/xorg/xorg_composite.c
+++ b/src/gallium/state_trackers/xorg/xorg_composite.c
@@ -271,7 +271,7 @@ picture_format_fixups(struct exa_pixmap_priv *pSrc,
PicturePtr pSrcPicture, bool
boolean swizzle = FALSE;
unsigned ret = 0;
- if (pSrc->picture_format == pSrcPicture->format) {
+ if (pSrc && pSrc->picture_format == pSrcPicture->format) {
if (pSrc->picture_format == PICT_a8) {
if (mask)
return FS_MASK_LUMINANCE;
@@ -286,7 +286,7 @@ picture_format_fixups(struct exa_pixmap_priv *pSrc,
PicturePtr pSrcPicture, bool
return 0;
}
- if (pSrc->picture_format != PICT_a8r8g8b8) {
+ if (pSrc && pSrc->picture_format != PICT_a8r8g8b8) {
assert(!"can not handle formats");
return 0;
}
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xorg: fix crash triggered by rendercheck -t composite -f a8r8g8b8 -o Src, Saturate
samplers[0] may remain uninititialized if src picture/pixmap is null
---
src/gallium/state_trackers/xorg/xorg_composite.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_composite.c
b/src/gallium/state_trackers/xorg/xorg_composite.c
index 9fdbc90..eca3bbf 100644
--- a/src/gallium/state_trackers/xorg/xorg_composite.c
+++ b/src/gallium/state_trackers/xorg/xorg_composite.c
@@ -389,7 +389,7 @@ bind_samplers(struct exa_context *exa, int op,
struct exa_pixmap_priv *pMask,
struct exa_pixmap_priv *pDst)
{
- struct pipe_sampler_state *samplers[PIPE_MAX_SAMPLERS];
+ struct pipe_sampler_state *samplers[PIPE_MAX_SAMPLERS] = {0};
struct pipe_sampler_state src_sampler, mask_sampler;
struct pipe_sampler_view view_templ;
struct pipe_sampler_view *src_view;
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util: add \n to debug_checkpoint_full
---
src/gallium/auxiliary/util/u_debug.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_debug.h
b/src/gallium/auxiliary/util/u_debug.h
index c47c13c..b5ea405 100644
--- a/src/gallium/auxiliary/util/u_debug.h
+++ b/src/gallium/auxiliary/util/u_debug.h
@@ -192,7 +192,7 @@ void _debug_assert_fail(const char *expr,
*/
#ifdef DEBUG
#define debug_checkpoint_full() \
- _debug_printf("%s:%u:%s", __FILE__, __LINE__, __FUNCTION__)
+ _debug_printf("%s:%u:%s\n", __FILE__, __LINE__, __FUNCTION__)
#else
#define debug_checkpoint_full() \
((void)0)
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] xorg/nouveau: rename to nouveau2
---
src/gallium/targets/xorg-nouveau/Makefile |2 +-
src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/gallium/targets/xorg-nouveau/Makefile
b/src/gallium/targets/xorg-nouveau/Makefile
index 5a2cdb1..16ac954 100644
--- a/src/gallium/targets/xorg-nouveau/Makefile
+++ b/src/gallium/targets/xorg-nouveau/Makefile
@@ -1,7 +1,7 @@
TOP = ../../../..
include $(TOP)/configs/current
-LIBNAME = modesetting_drv.so
+LIBNAME = nouveau2_drv.so
C_SOURCES = \
nouveau_target.c \
diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
index f0d6492..a25254a 100644
--- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
+++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
@@ -54,7 +54,7 @@ static PciChipsets nouveau_xorg_pci_devices[] = {
};
static XF86ModuleVersionInfo nouveau_xorg_version = {
-"modesetting",
+"nouveau2",
MODULEVENDORSTRING,
MODINFOSTRING1,
MODINFOSTRING2,
@@ -70,9 +70,9 @@ static XF86ModuleVersionInfo nouveau_xorg_version = {
* Xorg driver exported structures
*/
-_X_EXPORT DriverRec modesetting = {
+_X_EXPORT DriverRec nouveau2 = {
1,
-"modesetting",
+"nouveau2",
nouveau_xorg_identify,
NULL,
xorg_tracker_available_options,
@@ -85,7 +85,7 @@ _X_EXPORT DriverRec modesetting = {
static MODULESETUPPROTO(nouveau_xorg_setup);
-_X_EXPORT XF86ModuleData modesettingModuleData = {
+_X_EXPORT XF86ModuleData nouveau2ModuleData = {
&nouveau_xorg_version,
nouveau_xorg_setup,
NULL
@@ -104,7 +104,7 @@ nouveau_xorg_setup(pointer module, pointer opts, int
*errmaj, int *errmin)
*/
if (!setupDone) {
setupDone = 1;
- xf86AddDriver(&modesetting, module, HaveDriverFuncs);
+ xf86AddDriver(&nouveau2, module, HaveDriverFuncs);
/*
* The return value must be non-NULL on success even though there
@@ -121,7 +121,7 @@ nouveau_xorg_setup(pointer module, pointer opts, int
*errmaj, int *errmin)
static void
nouveau_xorg_identify(int flags)
{
-xf86PrintChipsets("modesetting", "Driver for Modesetting Kernel Drivers",
+xf86PrintChipsets("nouveau2", "Driver for Modesetting Kernel Drivers",
nouveau_xorg_chipsets);
}
@@ -137,7 +137,7 @@ nouveau_xorg_pci_probe(DriverPtr driver,
if (scrn != NULL) {
scrn->driverVersion = 1;
scrn->driverName = "nouveau";
- scrn->name = "modesetting";
+ scrn->name = "nouveau2";
scrn->Probe = NULL;
entity = xf86GetEntityInfo(entity_num);
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills
On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote:
> Hmm not sure about the 8-bit case. Is that really mono and ok if we use
> red channel? And I guess it doesn't make a difference if you'd use 1.0
> as color[3] instead of 0 (just seems that would be more correct)?
Something is definitely wrong in a8 handling and I'm not sure yet what.
With this patch applied, a8 fill test pass, but blend don't.
I'll figure this out, but not now...
> Also, you're passing in bpp to xorg_pixel_to_float4 but don't actually
> use it.
Yes, that comes from previous version ot the patch which used bpp.
I'm attaching fixed version.
> Otherwise, doesn't really look hacky to me - unless we could get other
> channel ordering or something similar...
It makes assumptions about how color components are ordered and what are
their widths - e.g. it can't distinguish r5g6b5 from a1r5g5b5.
---
From: Marcin Slusarz
Subject: [PATCH] st/xorg: add some support for non 32-bit color solid fills
It's a hack, but it allows rendercheck to pass all fill and most blend tests.
(without it all blend tests fail)
---
src/gallium/state_trackers/xorg/xorg_composite.c | 69 ++---
src/gallium/state_trackers/xorg/xorg_composite.h |5 +-
src/gallium/state_trackers/xorg/xorg_exa.c | 15 +-
3 files changed, 63 insertions(+), 26 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_composite.c
b/src/gallium/state_trackers/xorg/xorg_composite.c
index f696b72..13acd1c 100644
--- a/src/gallium/state_trackers/xorg/xorg_composite.c
+++ b/src/gallium/state_trackers/xorg/xorg_composite.c
@@ -51,19 +51,52 @@ static const struct xorg_composite_blend xorg_blends[] = {
};
-static INLINE void
-pixel_to_float4(Pixel pixel, float *color)
+boolean xorg_pixel_to_float4(Pixel pixel, unsigned char depth, float *color)
{
CARD32 r, g, b, a;
- a = (pixel >> 24) & 0xff;
- r = (pixel >> 16) & 0xff;
- g = (pixel >> 8) & 0xff;
- b = (pixel >> 0) & 0xff;
- color[0] = ((float)r) / 255.;
- color[1] = ((float)g) / 255.;
- color[2] = ((float)b) / 255.;
- color[3] = ((float)a) / 255.;
+ if (depth == 32) {
+ a = (pixel >> 24) & 0xff;
+ r = (pixel >> 16) & 0xff;
+ g = (pixel >> 8) & 0xff;
+ b = (pixel >> 0) & 0xff;
+ color[0] = ((float)r) / 255.;
+ color[1] = ((float)g) / 255.;
+ color[2] = ((float)b) / 255.;
+ color[3] = ((float)a) / 255.;
+ } else if (depth == 24) {
+ r = (pixel >> 16) & 0xff;
+ g = (pixel >> 8) & 0xff;
+ b = (pixel >> 0) & 0xff;
+ color[0] = ((float)r) / 255.;
+ color[1] = ((float)g) / 255.;
+ color[2] = ((float)b) / 255.;
+ color[3] = 0;
+ } else if (depth == 8) {
+ r = pixel & 0xff;
+ color[0] = ((float)r) / 255.;
+ color[1] = 0;
+ color[2] = 0;
+ color[3] = 0;
+ } else if (depth == 16) {
+ r = (pixel >> 11) & 0x1f;
+ g = (pixel >> 5) & 0x3f;
+ b = (pixel >> 0) & 0x1f;
+ color[0] = ((float)r) / 31.;
+ color[1] = ((float)g) / 63.;
+ color[2] = ((float)b) / 31.;
+ color[3] = 0;
+ } else if (depth == 15) {
+ r = (pixel >> 10) & 0x1f;
+ g = (pixel >> 5) & 0x1f;
+ b = (pixel >> 0) & 0x1f;
+ color[0] = ((float)r) / 31.;
+ color[1] = ((float)g) / 31.;
+ color[2] = ((float)b) / 31.;
+ color[3] = 0;
+ } else
+ return FALSE;
+ return TRUE;
}
static boolean
@@ -310,8 +343,8 @@ bind_shaders(struct exa_context *exa, int op,
fs_traits |= FS_SOLID_FILL;
vs_traits |= VS_SOLID_FILL;
debug_assert(pSrcPicture->format == PICT_a8r8g8b8);
-pixel_to_float4(pSrcPicture->pSourcePict->solidFill.color,
-exa->solid_color);
+xorg_pixel_to_float4(pSrcPicture->pSourcePict->solidFill.color,
+32, exa->solid_color);
exa->has_solid_color = TRUE;
} else {
debug_assert("!gradients not supported");
@@ -526,24 +559,14 @@ void xorg_composite(struct exa_context *exa,
}
boolean xorg_solid_bind_state(struct exa_context *exa,
- struct exa_pixmap_priv *pixmap,
- Pixel fg)
+ struct exa_pixmap_priv *pixmap)
{
struct pipe_surface *dst_surf = xorg_gpu_surface(exa->pipe, pixmap);
unsigned vs_traits, fs_traits;
struct xorg_shader shader;
- pixel_to_float4(fg, exa->solid_color);
exa->has_solid_color = TRUE;
-#if 0
- debug_printf("Color Pixel=(%d, %d, %d, %d), RGBA=(%f, %f, %f, %f)\n",
-(fg >> 24) & 0xff, (fg >> 16) &
[Mesa-dev] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
Bail out early in probe, so other driver can take control of the card.
Doing it in screen_create would be too late.
---
src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 ++-
1 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
index a25254a..5392e50 100644
--- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
+++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
@@ -38,16 +38,9 @@ static Bool nouveau_xorg_pci_probe(DriverPtr driver, int
entity_num,
static const struct pci_id_match nouveau_xorg_device_match[] = {
{ 0x10de, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
0x0003, 0x00ff, 0 },
-{ 0x12d2, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
- 0x0003, 0x00ff, 0 },
{0, 0, 0},
};
-static SymTabRec nouveau_xorg_chipsets[] = {
-{PCI_MATCH_ANY, "NVIDIA Graphics Device"},
-{-1, NULL}
-};
-
static PciChipsets nouveau_xorg_pci_devices[] = {
{PCI_MATCH_ANY, PCI_MATCH_ANY, NULL},
{-1, -1, NULL}
@@ -121,16 +114,49 @@ nouveau_xorg_setup(pointer module, pointer opts, int
*errmaj, int *errmin)
static void
nouveau_xorg_identify(int flags)
{
-xf86PrintChipsets("nouveau2", "Driver for Modesetting Kernel Drivers",
- nouveau_xorg_chipsets);
+xf86DrvMsg(0, X_INFO, "nouveau2: Gallium3D based 2D driver for NV30+
NVIDIA chipsets\n");
}
+struct pcirange {
+ unsigned int low;
+ unsigned int high;
+};
+
+/* List of cards we DO NOT SUPPORT. */
+static struct pcirange NVPreNV30Chipsets[] =
+{
+ {0x0020, 0x002F}, /* NV04/05 */
+ {0x00A0, 0x00AF}, /* ? */
+ {0x0100, 0x010F}, /* NV10 */
+ {0x0110, 0x011F}, /* NV11 */
+ {0x01A0, 0x01AF}, /* NV1A */
+ {0x0150, 0x015F}, /* NV15 */
+ {0x0170, 0x017F}, /* NV17 */
+ {0x0180, 0x018F}, /* NV18 */
+ {0x01F0, 0x01FF}, /* NV1F */
+ {0x0200, 0x020F}, /* NV20 */
+ {0x02A0, 0x02AF}, /* NV2A */
+ {0x0250, 0x025F}, /* NV25 */
+ {0x0280, 0x028F}, /* NV28 */
+ {0, 0}
+};
+
+
static Bool
nouveau_xorg_pci_probe(DriverPtr driver,
int entity_num, struct pci_device *device, intptr_t match_data)
{
ScrnInfoPtr scrn = NULL;
EntityInfoPtr entity;
+struct pcirange *cur;
+
+if (device->vendor_id != 0x10DE)
+ return FALSE;
+
+for (cur = &NVPreNV30Chipsets[0]; cur->low != 0; cur++) {
+ if (device->device_id >= cur->low && device->device_id <= cur->high)
+ return FALSE;
+}
scrn = xf86ConfigPciEntity(scrn, 0, entity_num, nouveau_xorg_pci_devices,
NULL, NULL, NULL, NULL, NULL);
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills
On Tue, May 17, 2011 at 09:27:45AM +0200, Michel Dänzer wrote: > On Die, 2011-05-17 at 00:12 +0200, Marcin Slusarz wrote: > > On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote: > > > Otherwise, doesn't really look hacky to me - unless we could get other > > > channel ordering or something similar... > > > > It makes assumptions about how color components are ordered and what are > > their widths - e.g. it can't distinguish r5g6b5 from a1r5g5b5. > > Such assumptions should be fine for non-RENDER operations. For RENDER, > maybe you could use something like exaGetRGBAFromPixel, at least for > inspiration. The problem is that exa does not pass format to PrepareSolid - only raw color data and depth, but pipe_context->clear wants float[4], so we need to figure out color format first. (Or add raw_clear operation...) For 2D drivers this exa misdesign didn't matter because they used 2D engines - which care only about BPP for solid fills. Accelerating RENDER operations should not be a big problem for gallium, because exa passes all formats (through PicturePtr). For now xorg st fallbacks too much, but this is something I'm going to tackle soon. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills
On Tue, May 17, 2011 at 06:40:02PM +0200, Michel Dänzer wrote: > On Die, 2011-05-17 at 18:30 +0200, Marcin Slusarz wrote: > > On Tue, May 17, 2011 at 09:27:45AM +0200, Michel Dänzer wrote: > > > On Die, 2011-05-17 at 00:12 +0200, Marcin Slusarz wrote: > > > > On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote: > > > > > Otherwise, doesn't really look hacky to me - unless we could get other > > > > > channel ordering or something similar... > > > > > > > > It makes assumptions about how color components are ordered and what are > > > > their widths - e.g. it can't distinguish r5g6b5 from a1r5g5b5. > > > > > > Such assumptions should be fine for non-RENDER operations. For RENDER, > > > maybe you could use something like exaGetRGBAFromPixel, at least for > > > inspiration. > > > > The problem is that exa does not pass format to PrepareSolid - only raw > > color > > data and depth, but pipe_context->clear wants float[4], so we need to figure > > out color format first. (Or add raw_clear operation...) > > The format can be determined from the destination pixmap if necessary? I couldn't find it. How to do it? Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills
On Tue, May 17, 2011 at 07:15:50PM +0200, Michel Dänzer wrote: > On Die, 2011-05-17 at 18:59 +0200, Marcin Slusarz wrote: > > On Tue, May 17, 2011 at 06:40:02PM +0200, Michel Dänzer wrote: > > > On Die, 2011-05-17 at 18:30 +0200, Marcin Slusarz wrote: > > > > On Tue, May 17, 2011 at 09:27:45AM +0200, Michel Dänzer wrote: > > > > > On Die, 2011-05-17 at 00:12 +0200, Marcin Slusarz wrote: > > > > > > On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote: > > > > > > > Otherwise, doesn't really look hacky to me - unless we could get > > > > > > > other > > > > > > > channel ordering or something similar... > > > > > > > > > > > > It makes assumptions about how color components are ordered and > > > > > > what are > > > > > > their widths - e.g. it can't distinguish r5g6b5 from a1r5g5b5. > > > > > > > > > > Such assumptions should be fine for non-RENDER operations. For RENDER, > > > > > maybe you could use something like exaGetRGBAFromPixel, at least for > > > > > inspiration. > > > > > > > > The problem is that exa does not pass format to PrepareSolid - only raw > > > > color > > > > data and depth, but pipe_context->clear wants float[4], so we need to > > > > figure > > > > out color format first. (Or add raw_clear operation...) > > > > > > The format can be determined from the destination pixmap if necessary? > > > > I couldn't find it. How to do it? > > priv->tex is the underlying texture, so priv->tex->format should be what > you need. Maybe I'm missing something, but I think priv->tex is only allocated by ExaModifyPixmapHeader, which guesses format from depth (see exa_get_pipe_format)... Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xorg: add GALLIUM_AUXILIARIES to target dependencies
Without it changes to GALLIUM_AUXILIARIES don't induce target rebuild --- src/gallium/targets/Makefile.xorg |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/targets/Makefile.xorg b/src/gallium/targets/Makefile.xorg index 47040bb..6fad710 100644 --- a/src/gallium/targets/Makefile.xorg +++ b/src/gallium/targets/Makefile.xorg @@ -41,7 +41,7 @@ endif default: depend $(TOP)/$(LIB_DIR)/gallium $(LIBNAME) $(LIBNAME_STAGING) -$(LIBNAME): $(OBJECTS) Makefile ../Makefile.xorg $(LIBS) $(DRIVER_PIPES) +$(LIBNAME): $(OBJECTS) Makefile ../Makefile.xorg $(LIBS) $(DRIVER_PIPES) $(GALLIUM_AUXILIARIES) $(MKLIB) -linker '$(CC)' -noprefix -o $@ $(LDFLAGS) $(OBJECTS) $(DRIVER_PIPES) $(GALLIUM_AUXILIARIES) $(DRIVER_LINKS) depend: $(C_SOURCES) $(CPP_SOURCES) $(ASM_SOURCES) $(SYMLINKS) $(GENERATED_SOURCES) -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xorg: initialize drm_mode.type
it's uninitialized, but used by kernel (drm_mode_setcrtc -> drm_mode_set_crtcinfo) --- src/gallium/state_trackers/xorg/xorg_crtc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c b/src/gallium/state_trackers/xorg/xorg_crtc.c index 0499ed1..22e61cf 100644 --- a/src/gallium/state_trackers/xorg/xorg_crtc.c +++ b/src/gallium/state_trackers/xorg/xorg_crtc.c @@ -122,6 +122,7 @@ crtc_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr mode, drm_mode.hskew = mode->HSkew; drm_mode.vscan = mode->VScan; drm_mode.vrefresh = mode->VRefresh; +drm_mode.type = 0; if (!mode->name) xf86SetModeDefaultName(mode); strncpy(drm_mode.name, mode->name, DRM_DISPLAY_MODE_LEN - 1); -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] xorg/nouveau: rename to nouveau2
On Mon, May 16, 2011 at 09:50:29PM +0200, Marcin Slusarz wrote: > > --- > src/gallium/targets/xorg-nouveau/Makefile |2 +- > src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 14 +++--- > 2 files changed, 8 insertions(+), 8 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote: > Bail out early in probe, so other driver can take control of the card. > Doing it in screen_create would be too late. > --- > src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 > ++- > 1 files changed, 35 insertions(+), 9 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: fix crash triggered by rendercheck -t blend -f a8r8g8b8 -o Clear
On Mon, May 16, 2011 at 09:52:05PM +0200, Marcin Slusarz wrote: > > --- > src/gallium/state_trackers/xorg/xorg_composite.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: fix crash triggered by rendercheck -t composite -f a8r8g8b8 -o Src, Saturate
On Mon, May 16, 2011 at 09:52:47PM +0200, Marcin Slusarz wrote: > samplers[0] may remain uninititialized if src picture/pixmap is null > --- > src/gallium/state_trackers/xorg/xorg_composite.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: add \n to debug_checkpoint_full
On Mon, May 16, 2011 at 09:53:06PM +0200, Marcin Slusarz wrote: > > --- > src/gallium/auxiliary/util/u_debug.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 05, 2011 at 09:15:47PM +0200, Maarten Maathuis wrote: > 2011/6/5 Stéphane Marchesin : > > On Sun, Jun 5, 2011 at 12:06, Marcin Slusarz > > wrote: > >> On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote: > >>> Bail out early in probe, so other driver can take control of the card. > >>> Doing it in screen_create would be too late. > >>> --- > >>> src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 > >>> ++- > >>> 1 files changed, 35 insertions(+), 9 deletions(-) > >> > >> ping > >> > > > > Why do you need a list of cards for that, as opposed to reading the reg? > > > > I agree with Stephane, checking register 0 should work fine. First > check for NV04/05, then for NV10-NV2F. > I did it this way because I didn't have access to device file descriptor - it's created somewhere near InitScreen and passed to nouveau_drm_screen_create - too late to exit gracefully (something which I believe is a bug, but I couldn't track it). But now I see xf86-video-nouveau is in exactly the same situation - it opens fd temporarily in PciProbe. I'll adapt its code to target/xorg-nouveau. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 05, 2011 at 09:54:31PM +0200, Maarten Maathuis wrote:
> On Sun, Jun 5, 2011 at 9:46 PM, Marcin Slusarz
> wrote:
> > On Sun, Jun 05, 2011 at 09:15:47PM +0200, Maarten Maathuis wrote:
> >> 2011/6/5 Stéphane Marchesin :
> >> > On Sun, Jun 5, 2011 at 12:06, Marcin Slusarz
> >> > wrote:
> >> >> On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote:
> >> >>> Bail out early in probe, so other driver can take control of the card.
> >> >>> Doing it in screen_create would be too late.
> >> >>> ---
> >> >>> src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44
> >> >>> ++-
> >> >>> 1 files changed, 35 insertions(+), 9 deletions(-)
> >> >>
> >> >> ping
> >> >>
> >> >
> >> > Why do you need a list of cards for that, as opposed to reading the reg?
> >> >
> >>
> >> I agree with Stephane, checking register 0 should work fine. First
> >> check for NV04/05, then for NV10-NV2F.
> >>
> >
> > I did it this way because I didn't have access to device file descriptor -
> > it's created
> > somewhere near InitScreen and passed to nouveau_drm_screen_create - too
> > late to
> > exit gracefully (something which I believe is a bug, but I couldn't track
> > it).
> >
> > But now I see xf86-video-nouveau is in exactly the same situation - it
> > opens fd
> > temporarily in PciProbe. I'll adapt its code to target/xorg-nouveau.
>
> I was incorrect in saying that you should check registers yourself
> (which would require root), but opening the device should give you the
> chipset type.
>
Yeah. New patch below.
Thanks!
---
From: Marcin Slusarz
Subject: [PATCH] xorg/nouveau: blacklist all pre NV30 cards
Bail out early in probe, so other driver (xf86-video-nouveau) can take control
of the card. Doing it in screen_create would be too late.
---
src/gallium/targets/xorg-nouveau/Makefile |3 +
src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 63 +++---
2 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/src/gallium/targets/xorg-nouveau/Makefile
b/src/gallium/targets/xorg-nouveau/Makefile
index 16ac954..755969c 100644
--- a/src/gallium/targets/xorg-nouveau/Makefile
+++ b/src/gallium/targets/xorg-nouveau/Makefile
@@ -23,4 +23,7 @@ DRIVER_PIPES = \
DRIVER_LINKS = \
$(shell pkg-config --libs libdrm libdrm_nouveau)
+DRIVER_INCLUDES = \
+ $(shell pkg-config --cflags-only-I libdrm libdrm_nouveau xf86driproto)
+
include ../Makefile.xorg
diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
index a25254a..43470a1 100644
--- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
+++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
@@ -29,6 +29,9 @@
*/
#include "../../state_trackers/xorg/xorg_winsys.h"
+#include
+#include
+#include
static void nouveau_xorg_identify(int flags);
static Bool nouveau_xorg_pci_probe(DriverPtr driver, int entity_num,
@@ -38,16 +41,9 @@ static Bool nouveau_xorg_pci_probe(DriverPtr driver, int
entity_num,
static const struct pci_id_match nouveau_xorg_device_match[] = {
{ 0x10de, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
0x0003, 0x00ff, 0 },
-{ 0x12d2, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
- 0x0003, 0x00ff, 0 },
{0, 0, 0},
};
-static SymTabRec nouveau_xorg_chipsets[] = {
-{PCI_MATCH_ANY, "NVIDIA Graphics Device"},
-{-1, NULL}
-};
-
static PciChipsets nouveau_xorg_pci_devices[] = {
{PCI_MATCH_ANY, PCI_MATCH_ANY, NULL},
{-1, -1, NULL}
@@ -121,8 +117,7 @@ nouveau_xorg_setup(pointer module, pointer opts, int
*errmaj, int *errmin)
static void
nouveau_xorg_identify(int flags)
{
-xf86PrintChipsets("nouveau2", "Driver for Modesetting Kernel Drivers",
- nouveau_xorg_chipsets);
+xf86DrvMsg(0, X_INFO, "nouveau2: Gallium3D based 2D driver for NV30+
NVIDIA chipsets\n");
}
static Bool
@@ -131,6 +126,56 @@ nouveau_xorg_pci_probe(DriverPtr driver,
{
ScrnInfoPtr scrn = NULL;
EntityInfoPtr entity;
+struct nouveau_device *dev = NULL;
+char *busid;
+int chipset, ret;
+
+if (device->vendor_id != 0x10DE)
+ return FALSE;
+
+if (!xf86LoaderCheckSymbol("DRICreatePCIBusID")) {
+ xf86DrvMsg(-1, X_ERROR, "[drm] No DRICreatePCIBusID symbol\n");
+ return FALSE;
+}
+busid = DRICreatePCIBusID(device);
+
+ret = nouveau_device_open(&dev, busid);
+if (ret) {
+ xf86DrvMsg(-1, X_ERROR, "[drm] failed to open device\n");
+ free(busid)
Re: [Mesa-dev] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 05, 2011 at 02:22:19PM -0500, Patrick Baggett wrote: >Wasn't nouveau targeted to provide HW acceleration for old cards like >the TNT2, or has that idea been killed? > This patch is for Gallium3D accelerated 2D xorg driver. Nobody is killing support for old cards from xf86-video-nouveau. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] [PATCH v3 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 05, 2011 at 11:43:15PM +0200, Marcin Kościelnicki wrote:
> > ---
> > From: Marcin Slusarz
> > Subject: [PATCH] xorg/nouveau: blacklist all pre NV30 cards
> >
> > Bail out early in probe, so other driver (xf86-video-nouveau) can
> > take control
> > of the card. Doing it in screen_create would be too late.
> > ---
> > src/gallium/targets/xorg-nouveau/Makefile |3 +
> > src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 63
> > +++---
> > 2 files changed, 57 insertions(+), 9 deletions(-)
> >
> > diff --git a/src/gallium/targets/xorg-nouveau/Makefile
> > b/src/gallium/targets/xorg-nouveau/Makefile
> > index 16ac954..755969c 100644
> > --- a/src/gallium/targets/xorg-nouveau/Makefile
> > +++ b/src/gallium/targets/xorg-nouveau/Makefile
> > @@ -23,4 +23,7 @@ DRIVER_PIPES = \
> > DRIVER_LINKS = \
> > $(shell pkg-config --libs libdrm libdrm_nouveau)
> >
> > +DRIVER_INCLUDES = \
> > + $(shell pkg-config --cflags-only-I libdrm libdrm_nouveau
> > xf86driproto)
> > +
> > include ../Makefile.xorg
> > diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> > b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> > index a25254a..43470a1 100644
> > --- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> > +++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> > @@ -29,6 +29,9 @@
> > */
> >
> > #include "../../state_trackers/xorg/xorg_winsys.h"
> > +#include
> > +#include
> > +#include
> >
> > static void nouveau_xorg_identify(int flags);
> > static Bool nouveau_xorg_pci_probe(DriverPtr driver, int entity_num,
> > @@ -38,16 +41,9 @@ static Bool nouveau_xorg_pci_probe(DriverPtr
> > driver, int entity_num,
> > static const struct pci_id_match nouveau_xorg_device_match[] = {
> > { 0x10de, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
> >0x0003, 0x00ff, 0 },
> > -{ 0x12d2, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
> > - 0x0003, 0x00ff, 0 },
> > {0, 0, 0},
> > };
> >
> > -static SymTabRec nouveau_xorg_chipsets[] = {
> > -{PCI_MATCH_ANY, "NVIDIA Graphics Device"},
> > -{-1, NULL}
> > -};
> > -
> > static PciChipsets nouveau_xorg_pci_devices[] = {
> > {PCI_MATCH_ANY, PCI_MATCH_ANY, NULL},
> > {-1, -1, NULL}
> > @@ -121,8 +117,7 @@ nouveau_xorg_setup(pointer module, pointer opts,
> > int *errmaj, int *errmin)
> > static void
> > nouveau_xorg_identify(int flags)
> > {
> > -xf86PrintChipsets("nouveau2", "Driver for Modesetting Kernel
> > Drivers",
> > - nouveau_xorg_chipsets);
> > +xf86DrvMsg(0, X_INFO, "nouveau2: Gallium3D based 2D driver for
> > NV30+ NVIDIA chipsets\n");
> > }
> >
> > static Bool
> > @@ -131,6 +126,56 @@ nouveau_xorg_pci_probe(DriverPtr driver,
> > {
> > ScrnInfoPtr scrn = NULL;
> > EntityInfoPtr entity;
> > +struct nouveau_device *dev = NULL;
> > +char *busid;
> > +int chipset, ret;
> > +
> > +if (device->vendor_id != 0x10DE)
> > + return FALSE;
> > +
> > +if (!xf86LoaderCheckSymbol("DRICreatePCIBusID")) {
> > + xf86DrvMsg(-1, X_ERROR, "[drm] No DRICreatePCIBusID symbol\n");
> > + return FALSE;
> > +}
> > +busid = DRICreatePCIBusID(device);
> > +
> > +ret = nouveau_device_open(&dev, busid);
> > +if (ret) {
> > + xf86DrvMsg(-1, X_ERROR, "[drm] failed to open device\n");
> > + free(busid);
> > + return FALSE;
> > +}
> > +
> > +chipset = dev->chipset;
> > +nouveau_device_close(&dev);
> > +
> > +ret = drmCheckModesettingSupported(busid);
> > +free(busid);
> > +if (ret) {
> > + xf86DrvMsg(-1, X_ERROR, "[drm] KMS not enabled\n");
> > + return FALSE;
> > +}
> > +
> > +switch (chipset & 0xf0) {
> > +case 0x00:
> > +case 0x10:
> > +case 0x20:
> > + xf86DrvMsg(-1, X_NOTICE, "Too old chipset: NV%02x\n", chipset);
> > + return FALSE;
> > +case 0x30:
> > +case 0x40:
> > +case 0x60:
> > +case 0x50:
> > +case 0x80:
> > +case 0x90:
> > +case 0xa0:
> > +case 0xc0:
> 0xd0 should be added here, there's NVD9 already.
There's no point in adding it now - mesa does not support it...
(see nouveau_drm_screen_create in
src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c)
> > + xf86DrvMsg(-1, X_INFO, "Detected chipset: NV%02x\n", chipset);
> > + break;
> > +default:
> > + xf86DrvMsg(-1, X_ERROR, "Unknown chipset: NV%02x\n", chipset);
> > + return FALSE;
> > +}
> >
> > scrn = xf86ConfigPciEntity(scrn, 0, entity_num,
> > nouveau_xorg_pci_devices,
> >NULL, NULL, NULL, NULL, NULL);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/nouveau: remove unused nouveau_screen_bo_user
On Mon, May 09, 2011 at 12:35:10AM +0200, Marcin Slusarz wrote: > > --- > src/gallium/drivers/nouveau/nouveau_screen.c | 14 -- > src/gallium/drivers/nouveau/nouveau_screen.h |2 -- > 2 files changed, 0 insertions(+), 16 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: fix crash triggered by rendercheck -t blend -f a8r8g8b8 -o Clear
On Mon, May 16, 2011 at 09:52:05PM +0200, Marcin Slusarz wrote:
>
> ---
> src/gallium/state_trackers/xorg/xorg_composite.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/xorg/xorg_composite.c
> b/src/gallium/state_trackers/xorg/xorg_composite.c
> index cadec59..9fdbc90 100644
> --- a/src/gallium/state_trackers/xorg/xorg_composite.c
> +++ b/src/gallium/state_trackers/xorg/xorg_composite.c
> @@ -271,7 +271,7 @@ picture_format_fixups(struct exa_pixmap_priv *pSrc,
> PicturePtr pSrcPicture, bool
> boolean swizzle = FALSE;
> unsigned ret = 0;
>
> - if (pSrc->picture_format == pSrcPicture->format) {
> + if (pSrc && pSrc->picture_format == pSrcPicture->format) {
>if (pSrc->picture_format == PICT_a8) {
> if (mask)
> return FS_MASK_LUMINANCE;
> @@ -286,7 +286,7 @@ picture_format_fixups(struct exa_pixmap_priv *pSrc,
> PicturePtr pSrcPicture, bool
>return 0;
> }
>
> - if (pSrc->picture_format != PICT_a8r8g8b8) {
> + if (pSrc && pSrc->picture_format != PICT_a8r8g8b8) {
>assert(!"can not handle formats");
>return 0;
> }
> --
Can someone commit this patch?
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: fix crash triggered by rendercheck -t composite -f a8r8g8b8 -o Src, Saturate
On Mon, May 16, 2011 at 09:52:47PM +0200, Marcin Slusarz wrote:
> samplers[0] may remain uninititialized if src picture/pixmap is null
> ---
> src/gallium/state_trackers/xorg/xorg_composite.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/state_trackers/xorg/xorg_composite.c
> b/src/gallium/state_trackers/xorg/xorg_composite.c
> index 9fdbc90..eca3bbf 100644
> --- a/src/gallium/state_trackers/xorg/xorg_composite.c
> +++ b/src/gallium/state_trackers/xorg/xorg_composite.c
> @@ -389,7 +389,7 @@ bind_samplers(struct exa_context *exa, int op,
>struct exa_pixmap_priv *pMask,
>struct exa_pixmap_priv *pDst)
> {
> - struct pipe_sampler_state *samplers[PIPE_MAX_SAMPLERS];
> + struct pipe_sampler_state *samplers[PIPE_MAX_SAMPLERS] = {0};
> struct pipe_sampler_state src_sampler, mask_sampler;
> struct pipe_sampler_view view_templ;
> struct pipe_sampler_view *src_view;
> --
Can someone commit this patch?
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/nouveau: remove unused nouveau_screen_bo_user
On Mon, May 09, 2011 at 12:35:10AM +0200, Marcin Slusarz wrote:
>
> ---
> src/gallium/drivers/nouveau/nouveau_screen.c | 14 --
> src/gallium/drivers/nouveau/nouveau_screen.h |2 --
> 2 files changed, 0 insertions(+), 16 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c
> b/src/gallium/drivers/nouveau/nouveau_screen.c
> index 401155b..223e768 100644
> --- a/src/gallium/drivers/nouveau/nouveau_screen.c
> +++ b/src/gallium/drivers/nouveau/nouveau_screen.c
> @@ -81,20 +81,6 @@ nouveau_screen_bo_new(struct pipe_screen *pscreen,
> unsigned alignment,
> return bo;
> }
>
> -struct nouveau_bo *
> -nouveau_screen_bo_user(struct pipe_screen *pscreen, void *ptr, unsigned
> bytes)
> -{
> - struct nouveau_device *dev = nouveau_screen(pscreen)->device;
> - struct nouveau_bo *bo = NULL;
> - int ret;
> -
> - ret = nouveau_bo_user(dev, ptr, bytes, &bo);
> - if (ret)
> - return NULL;
> -
> - return bo;
> -}
> -
> void *
> nouveau_screen_bo_map(struct pipe_screen *pscreen,
> struct nouveau_bo *bo,
> diff --git a/src/gallium/drivers/nouveau/nouveau_screen.h
> b/src/gallium/drivers/nouveau/nouveau_screen.h
> index 186ada3..d910809 100644
> --- a/src/gallium/drivers/nouveau/nouveau_screen.h
> +++ b/src/gallium/drivers/nouveau/nouveau_screen.h
> @@ -47,8 +47,6 @@ nouveau_screen(struct pipe_screen *pscreen)
> struct nouveau_bo *
> nouveau_screen_bo_new(struct pipe_screen *pscreen, unsigned alignment,
> unsigned usage, unsigned bind, unsigned size);
> -struct nouveau_bo *
> -nouveau_screen_bo_user(struct pipe_screen *pscreen, void *ptr, unsigned
> bytes);
> void *
> nouveau_screen_bo_map(struct pipe_screen *pscreen,
> struct nouveau_bo *pb,
> --
Can someone commit this patch?
Or reject it. Whatever.
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: add GALLIUM_AUXILIARIES to target dependencies
On Sun, Jun 05, 2011 at 09:04:49PM +0200, Marcin Slusarz wrote: > Without it changes to GALLIUM_AUXILIARIES don't induce target rebuild > --- > src/gallium/targets/Makefile.xorg |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/gallium/targets/Makefile.xorg > b/src/gallium/targets/Makefile.xorg > index 47040bb..6fad710 100644 > --- a/src/gallium/targets/Makefile.xorg > +++ b/src/gallium/targets/Makefile.xorg > @@ -41,7 +41,7 @@ endif > > default: depend $(TOP)/$(LIB_DIR)/gallium $(LIBNAME) $(LIBNAME_STAGING) > > -$(LIBNAME): $(OBJECTS) Makefile ../Makefile.xorg $(LIBS) $(DRIVER_PIPES) > +$(LIBNAME): $(OBJECTS) Makefile ../Makefile.xorg $(LIBS) $(DRIVER_PIPES) > $(GALLIUM_AUXILIARIES) > $(MKLIB) -linker '$(CC)' -noprefix -o $@ $(LDFLAGS) $(OBJECTS) > $(DRIVER_PIPES) $(GALLIUM_AUXILIARIES) $(DRIVER_LINKS) > > depend: $(C_SOURCES) $(CPP_SOURCES) $(ASM_SOURCES) $(SYMLINKS) > $(GENERATED_SOURCES) > -- Can someone commit this patch? Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: initialize drm_mode.type
On Sun, Jun 05, 2011 at 09:05:24PM +0200, Marcin Slusarz wrote: > it's uninitialized, but used by kernel (drm_mode_setcrtc -> > drm_mode_set_crtcinfo) > --- > src/gallium/state_trackers/xorg/xorg_crtc.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c > b/src/gallium/state_trackers/xorg/xorg_crtc.c > index 0499ed1..22e61cf 100644 > --- a/src/gallium/state_trackers/xorg/xorg_crtc.c > +++ b/src/gallium/state_trackers/xorg/xorg_crtc.c > @@ -122,6 +122,7 @@ crtc_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr mode, > drm_mode.hskew = mode->HSkew; > drm_mode.vscan = mode->VScan; > drm_mode.vrefresh = mode->VRefresh; > +drm_mode.type = 0; > if (!mode->name) > xf86SetModeDefaultName(mode); > strncpy(drm_mode.name, mode->name, DRM_DISPLAY_MODE_LEN - 1); > -- Can someone commit this patch? Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] xorg/nouveau: rename to nouveau2
On Mon, May 16, 2011 at 09:50:29PM +0200, Marcin Slusarz wrote:
>
> ---
> src/gallium/targets/xorg-nouveau/Makefile |2 +-
> src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 14 +++---
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/targets/xorg-nouveau/Makefile
> b/src/gallium/targets/xorg-nouveau/Makefile
> index 5a2cdb1..16ac954 100644
> --- a/src/gallium/targets/xorg-nouveau/Makefile
> +++ b/src/gallium/targets/xorg-nouveau/Makefile
> @@ -1,7 +1,7 @@
> TOP = ../../../..
> include $(TOP)/configs/current
>
> -LIBNAME = modesetting_drv.so
> +LIBNAME = nouveau2_drv.so
>
> C_SOURCES = \
> nouveau_target.c \
> diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> index f0d6492..a25254a 100644
> --- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> +++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> @@ -54,7 +54,7 @@ static PciChipsets nouveau_xorg_pci_devices[] = {
> };
>
> static XF86ModuleVersionInfo nouveau_xorg_version = {
> -"modesetting",
> +"nouveau2",
> MODULEVENDORSTRING,
> MODINFOSTRING1,
> MODINFOSTRING2,
> @@ -70,9 +70,9 @@ static XF86ModuleVersionInfo nouveau_xorg_version = {
> * Xorg driver exported structures
> */
>
> -_X_EXPORT DriverRec modesetting = {
> +_X_EXPORT DriverRec nouveau2 = {
> 1,
> -"modesetting",
> +"nouveau2",
> nouveau_xorg_identify,
> NULL,
> xorg_tracker_available_options,
> @@ -85,7 +85,7 @@ _X_EXPORT DriverRec modesetting = {
>
> static MODULESETUPPROTO(nouveau_xorg_setup);
>
> -_X_EXPORT XF86ModuleData modesettingModuleData = {
> +_X_EXPORT XF86ModuleData nouveau2ModuleData = {
> &nouveau_xorg_version,
> nouveau_xorg_setup,
> NULL
> @@ -104,7 +104,7 @@ nouveau_xorg_setup(pointer module, pointer opts, int
> *errmaj, int *errmin)
> */
> if (!setupDone) {
> setupDone = 1;
> - xf86AddDriver(&modesetting, module, HaveDriverFuncs);
> + xf86AddDriver(&nouveau2, module, HaveDriverFuncs);
>
> /*
>* The return value must be non-NULL on success even though there
> @@ -121,7 +121,7 @@ nouveau_xorg_setup(pointer module, pointer opts, int
> *errmaj, int *errmin)
> static void
> nouveau_xorg_identify(int flags)
> {
> -xf86PrintChipsets("modesetting", "Driver for Modesetting Kernel Drivers",
> +xf86PrintChipsets("nouveau2", "Driver for Modesetting Kernel Drivers",
> nouveau_xorg_chipsets);
> }
>
> @@ -137,7 +137,7 @@ nouveau_xorg_pci_probe(DriverPtr driver,
> if (scrn != NULL) {
> scrn->driverVersion = 1;
> scrn->driverName = "nouveau";
> - scrn->name = "modesetting";
> + scrn->name = "nouveau2";
> scrn->Probe = NULL;
>
> entity = xf86GetEntityInfo(entity_num);
> --
Can someone commit this patch?
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 05, 2011 at 10:31:59PM +0200, Marcin Slusarz wrote:
> From: Marcin Slusarz
> Subject: [PATCH] xorg/nouveau: blacklist all pre NV30 cards
>
> Bail out early in probe, so other driver (xf86-video-nouveau) can take control
> of the card. Doing it in screen_create would be too late.
> ---
> src/gallium/targets/xorg-nouveau/Makefile |3 +
> src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 63 +++---
> 2 files changed, 57 insertions(+), 9 deletions(-)
>
> diff --git a/src/gallium/targets/xorg-nouveau/Makefile
> b/src/gallium/targets/xorg-nouveau/Makefile
> index 16ac954..755969c 100644
> --- a/src/gallium/targets/xorg-nouveau/Makefile
> +++ b/src/gallium/targets/xorg-nouveau/Makefile
> @@ -23,4 +23,7 @@ DRIVER_PIPES = \
> DRIVER_LINKS = \
> $(shell pkg-config --libs libdrm libdrm_nouveau)
>
> +DRIVER_INCLUDES = \
> + $(shell pkg-config --cflags-only-I libdrm libdrm_nouveau xf86driproto)
> +
> include ../Makefile.xorg
> diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> index a25254a..43470a1 100644
> --- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> +++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> @@ -29,6 +29,9 @@
> */
>
> #include "../../state_trackers/xorg/xorg_winsys.h"
> +#include
> +#include
> +#include
>
> static void nouveau_xorg_identify(int flags);
> static Bool nouveau_xorg_pci_probe(DriverPtr driver, int entity_num,
> @@ -38,16 +41,9 @@ static Bool nouveau_xorg_pci_probe(DriverPtr driver, int
> entity_num,
> static const struct pci_id_match nouveau_xorg_device_match[] = {
> { 0x10de, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
>0x0003, 0x00ff, 0 },
> -{ 0x12d2, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
> - 0x0003, 0x00ff, 0 },
> {0, 0, 0},
> };
>
> -static SymTabRec nouveau_xorg_chipsets[] = {
> -{PCI_MATCH_ANY, "NVIDIA Graphics Device"},
> -{-1, NULL}
> -};
> -
> static PciChipsets nouveau_xorg_pci_devices[] = {
> {PCI_MATCH_ANY, PCI_MATCH_ANY, NULL},
> {-1, -1, NULL}
> @@ -121,8 +117,7 @@ nouveau_xorg_setup(pointer module, pointer opts, int
> *errmaj, int *errmin)
> static void
> nouveau_xorg_identify(int flags)
> {
> -xf86PrintChipsets("nouveau2", "Driver for Modesetting Kernel Drivers",
> - nouveau_xorg_chipsets);
> +xf86DrvMsg(0, X_INFO, "nouveau2: Gallium3D based 2D driver for NV30+
> NVIDIA chipsets\n");
> }
>
> static Bool
> @@ -131,6 +126,56 @@ nouveau_xorg_pci_probe(DriverPtr driver,
> {
> ScrnInfoPtr scrn = NULL;
> EntityInfoPtr entity;
> +struct nouveau_device *dev = NULL;
> +char *busid;
> +int chipset, ret;
> +
> +if (device->vendor_id != 0x10DE)
> + return FALSE;
> +
> +if (!xf86LoaderCheckSymbol("DRICreatePCIBusID")) {
> + xf86DrvMsg(-1, X_ERROR, "[drm] No DRICreatePCIBusID symbol\n");
> + return FALSE;
> +}
> +busid = DRICreatePCIBusID(device);
> +
> +ret = nouveau_device_open(&dev, busid);
> +if (ret) {
> + xf86DrvMsg(-1, X_ERROR, "[drm] failed to open device\n");
> + free(busid);
> + return FALSE;
> +}
> +
> +chipset = dev->chipset;
> +nouveau_device_close(&dev);
> +
> +ret = drmCheckModesettingSupported(busid);
> +free(busid);
> +if (ret) {
> + xf86DrvMsg(-1, X_ERROR, "[drm] KMS not enabled\n");
> + return FALSE;
> +}
> +
> +switch (chipset & 0xf0) {
> +case 0x00:
> +case 0x10:
> +case 0x20:
> + xf86DrvMsg(-1, X_NOTICE, "Too old chipset: NV%02x\n", chipset);
> + return FALSE;
> +case 0x30:
> +case 0x40:
> +case 0x60:
> +case 0x50:
> +case 0x80:
> +case 0x90:
> +case 0xa0:
> +case 0xc0:
> + xf86DrvMsg(-1, X_INFO, "Detected chipset: NV%02x\n", chipset);
> + break;
> +default:
> + xf86DrvMsg(-1, X_ERROR, "Unknown chipset: NV%02x\n", chipset);
> + return FALSE;
> +}
>
> scrn = xf86ConfigPciEntity(scrn, 0, entity_num, nouveau_xorg_pci_devices,
> NULL, NULL, NULL, NULL, NULL);
> --
Can someone commit this patch?
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] xorg/nouveau: rename to nouveau2
On Mon, Jun 20, 2011 at 02:39:39AM +0200, Marek Olšák wrote: > Pushed, thanks. Thank you. > The other patch should be pushed by someone who understands it (i.e. not me). > > You already have 36 commits in Mesa master. You should really apply > for an account. Ok, I will apply. Thanks again. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: fix loop_variable_state->var_hash leak
---
src/glsl/loop_analysis.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/glsl/loop_analysis.cpp b/src/glsl/loop_analysis.cpp
index 6a0e4da..6548e15 100644
--- a/src/glsl/loop_analysis.cpp
+++ b/src/glsl/loop_analysis.cpp
@@ -42,8 +42,14 @@ loop_state::loop_state()
}
+static void destroy_loop_var_state(const void *key, void *data, void *closure)
+{
+ delete (loop_variable_state *)data;
+}
+
loop_state::~loop_state()
{
+ hash_table_call_foreach(this->ht, destroy_loop_var_state, NULL);
hash_table_dtor(this->ht);
ralloc_free(this->mem_ctx);
}
--
1.7.8.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: fix deref_hash memory leak in constant_expression_value
---
src/glsl/ir_constant_expression.cpp |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index 08a3328..0713fd7 100644
--- a/src/glsl/ir_constant_expression.cpp
+++ b/src/glsl/ir_constant_expression.cpp
@@ -1275,8 +1275,11 @@
ir_function_signature::constant_expression_value(exec_list *actual_parameters, s
foreach_list(n, actual_parameters) {
ir_constant *constant = ((ir_rvalue *)
n)->constant_expression_value(variable_context);
- if (constant == NULL)
-return NULL;
+ if (constant == NULL) {
+ hash_table_dtor(deref_hash);
+ return NULL;
+ }
+
ir_variable *var = (ir_variable *)parameter_info;
hash_table_insert(deref_hash, constant, var);
--
1.7.8.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Hook up loop_variable_state destructor to plug a memory leak.
On Thu, Jun 07, 2012 at 10:33:39AM -0700, Ian Romanick wrote:
> On 06/05/2012 04:01 PM, Kenneth Graunke wrote:
> > While ~loop_state() is already freeing the loop_variable_state objects
> > via ralloc_free(this->mem_ctx), the ~loop_variable_state() destructor
> > was never getting called, so the hash table inside loop_variable_state
> > was never getting destroyed.
> >
> > Fixes a memory leak in any shader with loops.
> >
> > NOTE: This is a candidate for stable release branches.
> >
> > Signed-off-by: Kenneth Graunke
> > ---
> > src/glsl/loop_analysis.h | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/src/glsl/loop_analysis.h b/src/glsl/loop_analysis.h
> > index 8bed1db..05c982f 100644
> > --- a/src/glsl/loop_analysis.h
> > +++ b/src/glsl/loop_analysis.h
> > @@ -140,6 +140,23 @@ public:
> > {
> > hash_table_dtor(this->var_hash);
> > }
> > +
> > + static void* operator new(size_t size, void *ctx)
> > + {
> > + void *lvs = ralloc_size(ctx, size);
> > + assert(lvs != NULL);
> > +
> > + ralloc_set_destructor(lvs, (void (*)(void*)) destructor);
> > +
> > + return lvs;
> > + }
> > +
> > +private:
> > + static void
> > + destructor(loop_variable_state *lvs)
> > + {
> > + lvs->~loop_variable_state();
> > + }
> > };
> >
> >
>
> This just looks wrong. :) Would it be better to have the real destructor
> code here and ~loop_variable_state call this->destructor?
Nope, this->destructor, when called from ralloc_free, would not call destructors
for this->fields.
Marcin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: fix loop_variable_state->var_hash leak
On Tue, Jun 05, 2012 at 03:58:20PM -0700, Kenneth Graunke wrote:
> On 06/05/2012 02:49 PM, Marcin Slusarz wrote:
> >
> > ---
> > src/glsl/loop_analysis.cpp |6 ++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/glsl/loop_analysis.cpp b/src/glsl/loop_analysis.cpp
> > index 6a0e4da..6548e15 100644
> > --- a/src/glsl/loop_analysis.cpp
> > +++ b/src/glsl/loop_analysis.cpp
> > @@ -42,8 +42,14 @@ loop_state::loop_state()
> > }
> >
> >
> > +static void destroy_loop_var_state(const void *key, void *data, void
> > *closure)
> > +{
> > + delete (loop_variable_state *)data;
> > +}
> > +
> > loop_state::~loop_state()
> > {
> > + hash_table_call_foreach(this->ht, destroy_loop_var_state, NULL);
> > hash_table_dtor(this->ht);
> > ralloc_free(this->mem_ctx);
> > }
>
> This makes me nervous. They're allocated via ralloc:
>
>loop_variable_state *ls = new(this->mem_ctx) loop_variable_state;
>
> which internally uses malloc/calloc and friends, not new/delete.
>
> ~loop_state() already calls ralloc_free(this->mem_ctx), which frees all
> the loop_variable_state objects. However, the loop_variable_state
> destructor isn't hooked up, so hash_table_dtor(this->var_hash) is never
> getting called.
>
> I'll reply in a moment with a patch to use ralloc invoke the destructor.
>
> It may be possible to rework ralloc such that C++ destructors just work.
> I'll have to think about that.
Not possible to "just work" without adding reflection to C++ first.
Below is a patch which "works", but needs one line boilerplate to all
classes which are ralloc'able.
---
From: Marcin Slusarz
Subject: [PATCH] ralloc: call c++ class destructors on free
... and uninline new and delete operators
... which shrinks libglsl.so by 136kB (3%)
---
src/glsl/ast.h | 42 ++-
src/glsl/ast_type.cpp | 25 +++
src/glsl/glsl_parser_extras.cpp|2 +
src/glsl/glsl_parser_extras.h | 19 +-
src/glsl/glsl_symbol_table.cpp | 18 +
src/glsl/glsl_symbol_table.h | 31 +
src/glsl/ir.cpp| 25 +++
src/glsl/ir.h | 21 ++
src/glsl/ir_function_detect_recursion.cpp | 22 +-
src/glsl/ir_variable_refcount.cpp |2 +
src/glsl/ir_variable_refcount.h|1 +
src/glsl/list.h| 42 +--
src/glsl/loop_analysis.cpp |4 +
src/glsl/loop_analysis.h | 20 +-
src/glsl/opt_array_splitting.cpp |1 +
src/glsl/opt_constant_propagation.cpp |2 +
src/glsl/opt_copy_propagation.cpp |2 +
src/glsl/opt_copy_propagation_elements.cpp |2 +
src/glsl/opt_dead_code_local.cpp |1 +
src/glsl/opt_dead_functions.cpp|1 +
src/glsl/opt_structure_splitting.cpp |1 +
src/glsl/ralloc.h | 73
src/glsl/s_expression.cpp |7 ++
src/glsl/s_expression.h|6 ++
src/mesa/drivers/dri/i965/brw_fs.cpp |3 +
src/mesa/drivers/dri/i965/brw_fs.h | 26 +---
src/mesa/drivers/dri/i965/brw_fs_cfg.cpp |5 ++
src/mesa/drivers/dri/i965/brw_fs_cfg.h | 23 +--
.../drivers/dri/i965/brw_fs_copy_propagation.cpp |2 +
src/mesa/drivers/dri/i965/brw_fs_cse.cpp |2 +
.../drivers/dri/i965/brw_fs_live_variables.cpp |2 +
src/mesa/drivers/dri/i965/brw_fs_live_variables.h | 11 +---
.../dri/i965/brw_fs_schedule_instructions.cpp |1 +
.../drivers/dri/i965/brw_fs_vector_splitting.cpp |1 +
src/mesa/drivers/dri/i965/brw_vec4.cpp |4 +
src/mesa/drivers/dri/i965/brw_vec4.h | 38 +-
src/mesa/program/ir_to_mesa.cpp| 14 +---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 15 +---
38 files changed, 252 insertions(+), 265 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index b096c83..33ac78f 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -48,26 +48,8 @@ struct YYLTYPE;
* Base class of all abstract syntax tree nodes
*/
class ast_node {
+ RALLOC_DECLARE_CLASS_HELPERS(ast_node);
public:
- /* Callers of this ralloc-based new need not call delete. It's
-* easier to just ralloc_free 'ctx' (or any of its ancestors). */
- static voi
Re: [Mesa-dev] [PATCH] glsl: Hook up loop_variable_state destructor to plug a memory leak.
On Thu, Jun 07, 2012 at 10:33:39AM -0700, Ian Romanick wrote: > In my dream of dreams, we'd be able to either allocate objects via > ralloc or allocate (automatic) objects on the stack. Hmm, I think it's doable with a patch I just posted + changes to delete calls (passing ralloc context). Is it really that desirable? Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Please test the automake-gallium branch
On Tue, Sep 25, 2012 at 08:35:31AM -0600, Brian Paul wrote: > On Mon, Sep 24, 2012 at 3:52 PM, Matt Turner wrote: > > This series of 105 patches finishes the automake conversion. > > > > I don't think the series needs to be reviewed patch by patch, since > > large chunks are making nearly identical changes to different > > directories. Plus, incorrect changes in the build system should be > > detectable with testing. As such, I won't send the patches to the > > list. > > > > The first patches are some clean ups that may be applicable to 9.0 > > depending on when it's actually going to be released. The middle of > > the series is mostly mindless conversion. And the last of the series > > is removing gobs and gobs of crap like makedepend, MESA_PIC_FLAGS, > > VAAPI, and dead makefiles. > > > > I've paid special attention to linking Gallium targets with gcc vs > > g++. Some drivers (like Nouveau) use C++ in the driver so always need > > to be linked with g++. Others (like r300) always require LLVM and need > > to be linked with g++. Others still, like softpipe, should be linked > > with g++ conditional on LLVM usage. I've tried to handle this, so > > testing with and without LLVM is important. > > > > Please help me find problems now before it goes into master. Here's a > > branch. It's easy to test. If you don't test and I commit this in a > > week and break your stuff, I'm sorry, but you didn't test. > > > > http://cgit.freedesktop.org/~mattst88/mesa/log/?h=automake-gallium > > Dumb question, but how do I clone this repo? > > I've tried "git clone " but got: > > Cloning into ?h=automake-gallium... > fatal: > http://cgit.freedesktop.org/~mattst88/mesa/log/?h=automake-gallium/info/refs > not found: did you run git update-server-info on the server? > > Then I tried "git clone http://cgit.freedesktop.org/~mattst88/mesa/ > Cloning into mesa... > error: inflate: data stream error (incorrect header check) > error: inflate: data stream error (incorrect header check) > error: inflate: data stream error (incorrect header check) > error: inflate: data stream error (incorrect header check) > error: inflate: data stream error (incorrect header check) > error: File 7bb8b305290f538ff0f27bc6b8856b09db5f6dab > (http://cgit.freedesktop.org/git/mesa/mesa.git/objects/20/4ab9fb24a099a1c784fa87ae8027800c2600c5) > corrupt > error: File 7bb8b305290f538ff0f27bc6b8856b09db5f6dab > (http://cgit.freedesktop.org/git/mesa/mesa.git/objects/7b/b8b305290f538ff0f27bc6b8856b09db5f6dab) > corrupt > error: File 11cdf24d15763131a7ab4b366cad78116884d045 > (http://cgit.freedesktop.org/git/mesa/mesa.git/objects/11/cdf24d15763131a7ab4b366cad78116884d045) > corrupt > error: Unable to find 11cdf24d15763131a7ab4b366cad78116884d045 under > http://cgit.freedesktop.org/~mattst88/mesa > Cannot obtain needed object 11cdf24d15763131a7ab4b366cad78116884d045 > while processing commit 96d110955d7341a40d5c9b7749430c377e962190. > error: Fetch failed. $ git remote add mattst88 git://people.freedesktop.org/~mattst88/mesa $ git fetch mattst88 $ git checkout mattst88/automake-gallium Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Please test the automake-gallium branch
On Mon, Sep 24, 2012 at 02:52:28PM -0700, Matt Turner wrote: > This series of 105 patches finishes the automake conversion. > > I don't think the series needs to be reviewed patch by patch, since > large chunks are making nearly identical changes to different > directories. Plus, incorrect changes in the build system should be > detectable with testing. As such, I won't send the patches to the > list. > > The first patches are some clean ups that may be applicable to 9.0 > depending on when it's actually going to be released. The middle of > the series is mostly mindless conversion. And the last of the series > is removing gobs and gobs of crap like makedepend, MESA_PIC_FLAGS, > VAAPI, and dead makefiles. > > I've paid special attention to linking Gallium targets with gcc vs > g++. Some drivers (like Nouveau) use C++ in the driver so always need > to be linked with g++. Others (like r300) always require LLVM and need > to be linked with g++. Others still, like softpipe, should be linked > with g++ conditional on LLVM usage. I've tried to handle this, so > testing with and without LLVM is important. > > Please help me find problems now before it goes into master. Here's a > branch. It's easy to test. If you don't test and I commit this in a > week and break your stuff, I'm sorry, but you didn't test. > > http://cgit.freedesktop.org/~mattst88/mesa/log/?h=automake-gallium With this branch, top level lib directory is not created, so it's impossible to test mesa without installing it first. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Please test the automake-gallium branch
On Tue, Sep 25, 2012 at 10:02:26AM -0700, Matt Turner wrote: > On Tue, Sep 25, 2012 at 9:46 AM, Marcin Slusarz > wrote: > > With this branch, top level lib directory is not created, so it's impossible > > to test mesa without installing it first. > > Indeed. This has been planned for a while. Never heard about it. Intentionally breaking useful features is not acceptable. > Installation is part of the testing procedure, after all. No. People test code, not build systems. > Do DESTDIR=... make install to install to some temporary directory for > testing. Installing every time something changes in the code is a waste of time. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Please test the automake-gallium branch
On Tue, Sep 25, 2012 at 10:38:31AM -0700, Matt Turner wrote: > On Tue, Sep 25, 2012 at 10:31 AM, Marcin Slusarz > wrote: > >> Installation is part of the testing procedure, after all. > > > > No. People test code, not build systems. > > I invite you to reread the subject of this email. So you do not intend to merge this branch to master? I'm fine with that ;) If you'll merge it, it will break testing for all of us, who used to test mesa without installing. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Please test the automake-gallium branch
On Tue, Sep 25, 2012 at 11:00:23AM -0700, Matt Turner wrote: > On Tue, Sep 25, 2012 at 10:56 AM, Marcin Slusarz > wrote: > > On Tue, Sep 25, 2012 at 10:38:31AM -0700, Matt Turner wrote: > >> On Tue, Sep 25, 2012 at 10:31 AM, Marcin Slusarz > >> wrote: > >> >> Installation is part of the testing procedure, after all. > >> > > >> > No. People test code, not build systems. > >> > >> I invite you to reread the subject of this email. > > > > So you do not intend to merge this branch to master? I'm fine with that ;) > > > > If you'll merge it, it will break testing for all of us, who used to > > test mesa without installing. > > You can simply set LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH (like you > were already doing before) to the directories where your libGL and > driver are. Ok, but everyone will have to hunt all those directories manually. Why can't it work like it used to? Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Please test the automake-gallium branch
On Mon, Sep 24, 2012 at 02:52:28PM -0700, Matt Turner wrote: > This series of 105 patches finishes the automake conversion. > > I don't think the series needs to be reviewed patch by patch, since > large chunks are making nearly identical changes to different > directories. Plus, incorrect changes in the build system should be > detectable with testing. As such, I won't send the patches to the > list. > > The first patches are some clean ups that may be applicable to 9.0 > depending on when it's actually going to be released. The middle of > the series is mostly mindless conversion. And the last of the series > is removing gobs and gobs of crap like makedepend, MESA_PIC_FLAGS, > VAAPI, and dead makefiles. > > I've paid special attention to linking Gallium targets with gcc vs > g++. Some drivers (like Nouveau) use C++ in the driver so always need > to be linked with g++. Others (like r300) always require LLVM and need > to be linked with g++. Others still, like softpipe, should be linked > with g++ conditional on LLVM usage. I've tried to handle this, so > testing with and without LLVM is important. > > Please help me find problems now before it goes into master. Here's a > branch. It's easy to test. If you don't test and I commit this in a > week and break your stuff, I'm sorry, but you didn't test. > > http://cgit.freedesktop.org/~mattst88/mesa/log/?h=automake-gallium egl seems to be broken: libEGL warning: Could not open driver /usr/src/gfx/mesa/src/gallium/targets/egl-static/.libs//egl_gallium.so (/usr/src/gfx/mesa/src/gallium/targets/egl-static/.libs//egl_gallium.so: undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE) libEGL warning: DRI2: xcb_connect failed libEGL warning: DRI2: xcb_connect failed libEGL warning: GLX: XOpenDisplay failed EGLUT: failed to initialize EGL display configuration: ./autogen.sh --enable-debug --enable-glx-tls --disable-asm --with-dri-drivers= --with-gallium-drivers=nouveau --enable-texture-float --enable-gles1 --enable-gles2 --disable-gallium-llvm --enable-shared-glapi --enable-gbm --enable-gallium-gbm --enable-gallium-egl --prefix=$XXX --with-egl-platforms=drm,x11 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: add support for gl_InstanceID
...by copying support for gl_InstanceIDARB, but without "#extension" check,
because EXT_draw_instanced spec does not say anything about it (as opposed
to ARB_draw_instanced / gl_InstanceIDARB) and NVIDIA driver already allow it
---
I'm not sure this is correct.
With this patch applied (+ merged floating branch) I can run OilRush on nv50
(run == watch the game crash in a few seconds ;)
src/glsl/ir_variable.cpp | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/src/glsl/ir_variable.cpp b/src/glsl/ir_variable.cpp
index 18a3e0f..bd776ee 100644
--- a/src/glsl/ir_variable.cpp
+++ b/src/glsl/ir_variable.cpp
@@ -34,6 +34,10 @@ static void
generate_ARB_draw_instanced_variables(exec_list *,
struct _mesa_glsl_parse_state *,
bool, _mesa_glsl_parser_targets);
+static void
+generate_EXT_draw_instanced_variables(exec_list *,
+ struct _mesa_glsl_parse_state *,
+ bool, _mesa_glsl_parser_targets);
static ir_variable *
add_variable(const char *name, enum ir_variable_mode mode, int slot,
@@ -335,6 +339,8 @@ initialize_vs_variables(exec_list *instructions,
if (state->ARB_draw_instanced_enable)
generate_ARB_draw_instanced_variables(instructions, state, false,
vertex_shader);
+ generate_EXT_draw_instanced_variables(instructions, state, false,
+vertex_shader);
}
@@ -454,6 +460,25 @@ generate_ARB_draw_instanced_variables(exec_list
*instructions,
}
}
+static void
+generate_EXT_draw_instanced_variables(exec_list *instructions,
+ struct _mesa_glsl_parse_state *state,
+ bool warn,
+ _mesa_glsl_parser_targets target)
+{
+ /* gl_InstanceID is only available in the vertex shader.
+*/
+ if (target == vertex_shader) {
+ ir_variable *const inst =
+ add_variable("gl_InstanceID", ir_var_system_value,
+ SYSTEM_VALUE_INSTANCE_ID,
+ glsl_type::int_type, instructions, state->symbols);
+
+ if (warn)
+ inst->warn_extension = "GL_EXT_draw_instanced";
+ }
+}
+
static void
generate_ARB_shader_stencil_export_variables(exec_list *instructions,
--
1.7.2.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: include u_format.h for util_format_is_supported
Without it gcc complains: nv50_screen.c: In function ‘nv50_screen_is_format_supported’: nv50_screen.c:48: warning: implicit declaration of function ‘util_format_is_supported’ and handles it wrongly - util_format_is_supported returns boolean, which is typedef'ed to uchar, but function without prototype is assumed to return int. For me nv50_screen_is_format_supported was returning true for float formats without --enable-texture-float... --- src/gallium/drivers/i915/i915_screen.c |1 + src/gallium/drivers/i965/brw_screen.c |1 + src/gallium/drivers/nv50/nv50_screen.c |1 + src/gallium/drivers/nvc0/nvc0_screen.c |1 + src/gallium/drivers/nvfx/nvfx_screen.c |1 + src/gallium/drivers/r600/r600_pipe.c |1 + 6 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 6f6a342..0f4327f 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -27,6 +27,7 @@ #include "draw/draw_context.h" +#include "util/u_format.h" #include "util/u_inlines.h" #include "util/u_memory.h" #include "util/u_string.h" diff --git a/src/gallium/drivers/i965/brw_screen.c b/src/gallium/drivers/i965/brw_screen.c index 5353ae2..9178dfa 100644 --- a/src/gallium/drivers/i965/brw_screen.c +++ b/src/gallium/drivers/i965/brw_screen.c @@ -26,6 +26,7 @@ **/ +#include "util/u_format.h" #include "util/u_inlines.h" #include "util/u_memory.h" #include "util/u_string.h" diff --git a/src/gallium/drivers/nv50/nv50_screen.c b/src/gallium/drivers/nv50/nv50_screen.c index e0eea3e..641ad7e 100644 --- a/src/gallium/drivers/nv50/nv50_screen.c +++ b/src/gallium/drivers/nv50/nv50_screen.c @@ -20,6 +20,7 @@ * SOFTWARE. */ +#include "util/u_format.h" #include "util/u_format_s3tc.h" #include "pipe/p_screen.h" diff --git a/src/gallium/drivers/nvc0/nvc0_screen.c b/src/gallium/drivers/nvc0/nvc0_screen.c index c4cdfac..5325807 100644 --- a/src/gallium/drivers/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nvc0/nvc0_screen.c @@ -20,6 +20,7 @@ * SOFTWARE. */ +#include "util/u_format.h" #include "util/u_format_s3tc.h" #include "pipe/p_screen.h" diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c b/src/gallium/drivers/nvfx/nvfx_screen.c index abbed96..ab063d6 100644 --- a/src/gallium/drivers/nvfx/nvfx_screen.c +++ b/src/gallium/drivers/nvfx/nvfx_screen.c @@ -1,5 +1,6 @@ #include "pipe/p_screen.h" #include "pipe/p_state.h" +#include "util/u_format.h" #include "util/u_format_s3tc.h" #include "util/u_simple_screen.h" diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index 066768f..1a581c7 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -30,6 +30,7 @@ #include #include #include +#include "util/u_format.h" #include #include #include -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
