similar to: [PATCH 1/2] nv30: avoid doing extra work on clear and hitting unexpected states

On 05/24/2015 06:58 AM, Ilia Mirkin wrote: > nv30_validate_clip depends on the rasterizer state. Also we should > upload all the new clip planes on change since next time the plane data > won't have changed, but the enables might. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > src/gallium/drivers/nouveau/nv30/nv30_state_validate.c | 16

> On 24 May 2015, at 16:03, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > > On 24.05.2015 10:38, Samuel Pitoiset wrote: >> >> >> On 05/24/2015 06:58 AM, Ilia Mirkin wrote: >>> nv30_validate_clip depends on the rasterizer state. Also we should >>> upload all the new clip planes on change since next time the

On Sun, May 24, 2015 at 10:56 AM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > On 24.05.2015 16:15, Pierre Moreau wrote: >>> >>> On 24 May 2015, at 16:03, Tobias Klausmann >>> <tobias.johannes.klausmann at mni.thm.de> wrote: >>> >>> >>> >>> On 24.05.2015 10:38, Samuel Pitoiset wrote:

Hi... I know... glBegin/glEnd is deprecated but I have an old computer 32bit CPU, running fedora 19, mesa-9.2.4, NV63... any help are welcomed. Please forgive if I misuderstood everything. So I have a simple OpenGL program that draws a black background and a white line... I will write the code of myline() inside of main() so as I can learn. main (..) { X and glX stuff... /* at this moment I

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

On Tue, Apr 5, 2016 at 2:38 PM, Daniel Melo Jorge da Cunha <dmjcunha at gmail.com> wrote: > Hi... I know... glBegin/glEnd is deprecated but I have an old computer 32bit > CPU, > running fedora 19, mesa-9.2.4, NV63... any help are welcomed. I've fixed a *ton* of nv3x/nv4x issues since then, I'd recommend giving Mesa 11.2.0 a whirl. > > Please forgive if I misuderstood

https://bugs.freedesktop.org/show_bug.cgi?id=59242 Priority: medium Bug ID: 59242 Assignee: nouveau at lists.freedesktop.org Summary: some mesa demos start to segfault after "nouveau: improve buffer transfers" on nv43 Severity: normal Classification: Unclassified OS: Linux (All)

nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the entire notifier, and use a offset in nv30_context_kick_notify. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 14 +- src/gallium/drivers/nouveau/nouveau_context.h | 5 +

On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the > entire notifier, and use a offset in nv30_context_kick_notify. It would be great if you could detail the list of transformations that were done in the commit description, as well as what the

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Untested. Happened to see this when I was reading this file (don't ask). I can't imagine the current situation to be the intended one, based on this code... src/gallium/drivers/nouveau/nv30/nv30_state_validate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +-

https://bugs.freedesktop.org/show_bug.cgi?id=102349 Bug ID: 102349 Summary: nv4x crashing with plasmashell - gdb log included Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=56474 Priority: medium Bug ID: 56474 Assignee: nouveau at lists.freedesktop.org Summary: 3D app segfaults on NV46 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: 1o5g4r8o at gmail.com Hardware: x86 (IA32) Status: NEW

The current code for primitive splitting and emission on pre-nv50 is severely broken. In particular: 1. Quads and lines are totally broken because "&= 3" should be "&= ~3" and similar for lines 2. Triangle fans and polygons are broken because the first vertex must be repeated for each split chunk 3. Line loops are broken because the must be converted to a line strip,

- Added flush notify functions for NV30 and NV40. - NV30 and NV40 need testing. --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 42 ++++++++++++++++++------ src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++-- src/gallium/drivers/nv30/nv30_context.c | 3 ++ src/gallium/drivers/nv30/nv30_context.h | 1 + src/gallium/drivers/nv30/nv30_state_emit.c | 10

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4

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]:

- Added flush notify functions for NV30 and NV40. - NV30 and NV40 need testing (check for regressions). --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 47 +++++++++++++++++++----- src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++-- src/gallium/drivers/nv30/nv30_context.c | 3 ++ src/gallium/drivers/nv30/nv30_context.h | 1 +

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]:

Hi Ilia, you were straight to the point for me in: "src/mesa/vbo will upload it to a vbo. The driver then points the hardware at the vbo and tells it to read from there." But where is it the function that implements this? Is it in nv30_draw_vbo(...)? Please, give me a function name or at least a file name? 2016-04-19 10:04 GMT-04:00 Ilia Mirkin <imirkin at alum.mit.edu>: >