Displaying 6 results from an estimated 6 matches for "vtxprog".
Did you mean:
ctxprog
2015 May 26
2
[PATCH 2/2] nv30/draw: switch varying hookup logic to know about texcoords
...> r->vtxptr[attrib] = vinfo->size | NV30_3D_VTXBUF_DMA1;
> vinfo->size += draw_translate_vinfo_size(emit);
>
> - if (nv30_screen(pscreen)->eng3d->oclass < NV40_3D_CLASS) {
> + if (screen->eng3d->oclass < NV40_3D_CLASS) {
> r->vtxprog[attrib][0] = 0x001f38d8;
> r->vtxprog[attrib][1] = 0x0080001b | (attrib << 9);
> r->vtxprog[attrib][2] = 0x0836106c;
> @@ -276,7 +278,12 @@ vroute_add(struct nv30_render *r, uint attrib, uint sem, uint *idx)
> r->vtxprog[attrib][3] = 0x6041ff80 | (...
2015 May 26
2
[PATCH 2/2] nv30/draw: switch varying hookup logic to know about texcoords
...b] = vinfo->size | NV30_3D_VTXBUF_DMA1;
>>> vinfo->size += draw_translate_vinfo_size(emit);
>>> - if (nv30_screen(pscreen)->eng3d->oclass < NV40_3D_CLASS) {
>>> + if (screen->eng3d->oclass < NV40_3D_CLASS) {
>>> r->vtxprog[attrib][0] = 0x001f38d8;
>>> r->vtxprog[attrib][1] = 0x0080001b | (attrib << 9);
>>> r->vtxprog[attrib][2] = 0x0836106c;
>>> @@ -276,7 +278,12 @@ vroute_add(struct nv30_render *r, uint attrib, uint
>>> sem, uint *idx)
>>>...
2015 May 25
3
[PATCH 1/2] nv30/draw: rework some of the output vertex buffer logic
This makes the vertex buffer go to GART, not VRAM, and redoes the
mapping to not use the UNSYNCHRONIZED access (which is meaningless on a
VRAM buffer anyways). While we're at it, add some flushes for VBO data.
Moving the vertex buffer from VRAM to GART makes glxgears work fully
with NV30_SWTNL=1. The other changes just seem like a good idea. I'm not
sure *why* moving the buffer from VRAM
2010 Jan 18
2
[PATCH 1/2] nv30-nv40: support unlimited queries
.../nv30_screen.c
index 48a562e..2cd5d12 100644
--- a/src/gallium/drivers/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nv30/nv30_screen.c
@@ -252,6 +252,8 @@ nv30_screen_create(struct pipe_winsys *ws, struct nouveau_device *dev)
return NULL;
}
+ LIST_INITHEAD(&screen->query_list);
+
/* Vtxprog resources */
if (nouveau_resource_init(&screen->vp_exec_heap, 0, 256) ||
nouveau_resource_init(&screen->vp_data_heap, 0, 256)) {
diff --git a/src/gallium/drivers/nv30/nv30_screen.h b/src/gallium/drivers/nv30/nv30_screen.h
index cbf945f..9190789 100644
--- a/src/gallium/drivers...
2010 Jan 18
0
[PATCH] nv30-nv40: support unlimited queries (v2)
.../nv30_screen.c
index 9ed4817..755db43 100644
--- a/src/gallium/drivers/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nv30/nv30_screen.c
@@ -261,6 +261,8 @@ nv30_screen_create(struct pipe_winsys *ws, struct nouveau_device *dev)
return NULL;
}
+ LIST_INITHEAD(&screen->query_list);
+
/* Vtxprog resources */
if (nouveau_resource_init(&screen->vp_exec_heap, 0, 256) ||
nouveau_resource_init(&screen->vp_data_heap, 0, 256)) {
diff --git a/src/gallium/drivers/nv30/nv30_screen.h b/src/gallium/drivers/nv30/nv30_screen.h
index 5fbd998..4e8b55c 100644
--- a/src/gallium/drivers...
2010 Jan 18
2
[Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
So, basically, you allocate the rasterizer units according to the
vertex shader, and when the fragment shader comes up, you say "write
rasterizer output 4 to fragment input 1000000"?
The current nouveau drivers can't do this.
There are "routing" registers in hardware, but I think the nVidia
proprietary driver (at least without GLSL) leaves them unaltered after