Displaying 6 results from an estimated 6 matches for "nvfx_fragprog".
Did you mean:
nv30_fragprog
2012 May 12
7
[Patches] mesa/nv30: Diverse set of patches that improve NV3x render quality V2
A reworked version of 3 out of 4 patches mentioned earlier.
[1/4]: Fixes nearly all piglit vertprog testcases, due to now being able to pass the results on to the fragment shader. V2: rename samplers to texcoords.
[2/4]: Fixes shader compiler assertion errors, as some source registers do not exist for certain operations. Fixes several piglit tests when mesa is compiled with --enable-debug
[3/4]:
2014 Jun 18
1
[PATCH 1/2] nv30: plug some memory leaks on screen destroy and shader compile
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
Cc: "10.2" <mesa-stable at lists.freedesktop.org>
---
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 6 ++++++
src/gallium/drivers/nouveau/nv30/nvfx_fragprog.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index fb9378c..4baabaf 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -327,6 +...
2012 May 09
4
[Patches]mesa/nv30: Diverse set of patches that improve NV3x render quality
For all these patches I'd say: testers are welcome. The first three patches seem good enough to push as we speak IMHO (so if you agree, go ahead!), whereas for the fourth I don't know if this is the desired way to fix. The result of these four patches is that NV34 gives a nearly-correct desktop experience, where only some fading animations appear broken. It's quite useable now!
[1/4]:
2014 Feb 21
3
[PATCH 1/4] nv30: remove use_nv4x, it is identical to is_nv4x
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
Perhaps there was a day when those were different, but that day is not today.
src/gallium/drivers/nouveau/nv30/nv30_context.c | 1 -
src/gallium/drivers/nouveau/nv30/nv30_context.h | 1 -
src/gallium/drivers/nouveau/nv30/nvfx_fragprog.c | 20 ++++++++++----------
src/gallium/drivers/nouveau/nv30/nvfx_vertprog.c | 8 ++++----
4 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_context.c b/src/gallium/drivers/nouveau/nv30/nv30_context.c
index 2146d27..4f68eee 100644
--- a/src/gal...
2015 May 26
2
[PATCH 2/2] nv30/draw: switch varying hookup logic to know about texcoords
...ords = (screen->eng3d->oclass < NV40_3D_CLASS) ? 8 :
>>> 10;
>>> + for (result = 0; result < num_texcoords; result++) {
>>> + if (fp->texcoord[result] == *idx + 8) {
>>
>> maybe i'm too tired, but why exactly *idx + 8 ?
> See nvfx_fragprog.c:
>
> fpc->fp->texcoord[hw] = fdec->Semantic.Index + 8;
>
> when the semantic is GENERIC. (and 0xfffe when it's PCOORD). This is
> because there can be up to 8 TEXCOORD's.
yet you run for 8 or 10 texcoords. Wont this cause problems on nv40+?
>
&...
2015 May 26
2
[PATCH 2/2] nv30/draw: switch varying hookup logic to know about texcoords
On 25.05.2015 21:29, Ilia Mirkin wrote:
> Commit 8acaf862dfe switched things over to use TEXCOORD instead of
> GENERIC, but did not update the nv30 swtnl draw paths. This teaches the
> draw logic about TEXCOORD.
>
> Among other things, this fixes a crash in demos/arbocclude when using
> swtnl. Curiously enough, the point-sprite piglit works without this.
>
> Signed-off-by: