Displaying 6 results from an estimated 6 matches for "hwcso".
2014 Aug 31
2
[Mesa-stable] [PATCH 2/2] nv50: zero out unbound samplers
...ULL. I'm just making sure
> that a subsequent call with a larger number of samplers doesn't try to
> unlock potentially-deleted samplers.
>
for (i = 0; i < nr; ++i) {
struct nv50_tsc_entry *old = nv50->samplers[s][i];
nv50->samplers[s][i] = nv50_tsc_entry(hwcso[i]);
if (old)
nv50_screen_tsc_unlock(nv50->screen, old);
}
In the above hunk we get the old/current tsc, drop in on the floor and assign
the new one in it's place. Does where does the ST keep track of the old one in
order to nuke it via sampler_state_delete, or is it alrea...
2014 Aug 30
3
[Mesa-stable] [PATCH 2/2] nv50: zero out unbound samplers
On 30/08/14 23:02, Ilia Mirkin wrote:
> Samplers are only defined up to num_samplers, so set all samplers above
> nr to NULL so that we don't try to read them again later.
>
Would it be worth doing a similar thing with the unlocked samplers below the
nr mark ? It seems to me that we might be leaking nv50->samplers[s][i], or
perhaps I'm missing something ?
-Emil
>
2015 May 17
14
[PATCH 00/12] Tessellation support for nvc0
This is enough to enable tessellation support on nvc0. It seems to
work a lot better on my GF108 than GK208. I suspect that there's some
sort of scheduling shenanigans that need to be adjusted for
kepler+. Or perhaps some shader header things.
Even with the GF108, I still get occasional blue triangles in Heaven,
but I get a *ton* of them on the GK208 -- seemingly the same issue,
but it's
2014 Aug 31
0
[Mesa-stable] [PATCH 2/2] nv50: zero out unbound samplers
...> that a subsequent call with a larger number of samplers doesn't try to
>> unlock potentially-deleted samplers.
>>
>
> for (i = 0; i < nr; ++i) {
> struct nv50_tsc_entry *old = nv50->samplers[s][i];
>
> nv50->samplers[s][i] = nv50_tsc_entry(hwcso[i]);
> if (old)
> nv50_screen_tsc_unlock(nv50->screen, old);
> }
>
> In the above hunk we get the old/current tsc, drop in on the floor and assign
> the new one in it's place. Does where does the ST keep track of the old one in
> order to nuke it via sa...
2017 Aug 21
20
[Bug 102349] New: nv4x crashing with plasmashell - gdb log included
...inux-gnu/libpthread.so.0
#6 0x00007ffff2728aff in clone () from /lib/x86_64-linux-gnu/libc.so.6
Thread 1 (Thread 0x7ffff7e0a940 (LWP 5160)):
#0 PUSH_RESET (bin=8, push=0x555555ac19f0) at
../../../../../src/gallium/drivers/nouveau/nv30/nv30_winsys.h:39
#1 nv30_fp_state_bind (pipe=0x5555558355b0, hwcso=0x555556648cc0) at
../../../../../src/gallium/drivers/nouveau/nv30/nv30_fragprog.c:174
#2 0x00007fff4b4531a0 in update_fp (st=0x555555f90250) at
../../../src/mesa/state_tracker/st_atom_shader.c:152
#3 0x00007fff4b44f3bb in st_validate_state (st=st at entry=0x555555f90250,
pipeline=pipeline at ent...
2016 Feb 15
24
[PATCH 01/23] nv50: import updated g80_defs.xml.h from rnndb
From: Ben Skeggs <bskeggs at redhat.com>
Signed-off-by: Ben Skeggs <bskeggs at redhat.com>
---
src/gallium/drivers/nouveau/nv50/g80_defs.xml.h | 279 ++++++++++++++++++++++++
1 file changed, 279 insertions(+)
create mode 100644 src/gallium/drivers/nouveau/nv50/g80_defs.xml.h
diff --git a/src/gallium/drivers/nouveau/nv50/g80_defs.xml.h