similar to: [PATCH] use defined method names where available

This has two purposes : - cleaner code - reduce the diff between nv30 and nv40 exa for a possible nvfx_exa merge ? The main differences seem to be that nv30 uses rect texture format (and does not support repeat on that). Then there are some minor changes in TX_FORMAT RT_FORMAT and TEX_FILTER usage. And NVAccelInitNVx0TCL look complete different. Tested with: ./rendercheck -t

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

From: Ben Skeggs <bskeggs at redhat.com> --- src/nv50_accel.c | 38 ++++++++------------------------------ src/nv50_accel.h | 1 - src/nv50_exa.c | 45 ++++++++++++++++++++------------------------- 3 files changed, 28 insertions(+), 56 deletions(-) diff --git a/src/nv50_accel.c b/src/nv50_accel.c index 1218e18..db8c744 100644 --- a/src/nv50_accel.c +++ b/src/nv50_accel.c @@

Turns out we used a misaligned long instruction near the end, and the shader was getting killed after writing R, A components. This has gone unnoticed since the remaining G, B outputs aren't actually used. --- src/nv50_accel.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/nv50_accel.c b/src/nv50_accel.c index 5fa539c..1218e18 100644 --- a/src/nv50_accel.c

Regression from "WIP: port to new libdrm". --- src/nv50_accel.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/nv50_accel.c b/src/nv50_accel.c index 66d6cb8..7c640f2 100644 --- a/src/nv50_accel.c +++ b/src/nv50_accel.c @@ -44,6 +44,9 @@ NV50SyncToVBlank(PixmapPtr ppix, BoxPtr box) if (!crtcs) return; + if (!PUSH_SPACE(push, 10)) + return; +

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- docs/GL3.txt | 2 +- docs/relnotes/10.4.html | 1 + src/gallium/drivers/nouveau/nv50/nv50_context.h | 3 +- src/gallium/drivers/nouveau/nv50/nv50_query.c | 56 +++++++++++++++++++++---- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-

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

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

in nv10_exa.c : check_texture does : if (w > 2046 || h > 2046) NOUVEAU_FALLBACK("picture too large, %dx%d\n", w, h); check_render_target does : if (w > 4096 || h > 4096) return FALSE; So we have different size limits for the source and the destination ? Another thing is that nv20 uses nv10_exa.c code, and the limit in

Clearing can happen at a time when various state objects are incoherent and not ready for a draw. Some of the validation functions don't handle this well, so only flush the framebuffer state. This has the advantage of also not doing extra work. This works around some crashes that can happen when clearing. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> ---

The headers hadn't been regenerated in a long time, and there were a few minor divergences. Among other things, rnndb has changed naming to G80/etc, for now I've not tackled switching that over and manually replaced the nvidia codenames back to the chip ids. However no other modifications of the headergen'd headers was done. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>

The headers hadn't been regenerated in a long time and had seen a number of manual modifications. A few changes: - remove nvc0_2d entirely, use the nv50 header which has the nvc0 values too - remove 3ddefs, it's identical to the nv50 file - move macros out into a separate file Also the upstream rnndb changed the overall chip naming convention; this was fixed up manually in the

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

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=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

We still have to push everything out, might as well kick earlier and flip pushbufs when we know we'll need it. This resolves some issues with the new policy of making sure that we always leave a bit of room at the end for fences. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: mesa-stable at lists.freedesktop.org --- src/gallium/drivers/nouveau/nv50/nv50_shader_state.c | 9

On Sat, Oct 10, 2015 at 3:41 PM, Samuel Pitoiset <samuel.pitoiset at gmail.com> wrote: > This patch looks fine except that it should be a bit more normalized. I > mean, sometimes you break when PUSH_SPACE fails, sometimes not. Same for > PUSH_SPACE calls, sometimes you add it sometimes not. Meh. We need to get our error checking situation straight, but this isn't the patch to