similar to: [PATCH] nv30: don't overwrite blend color setting for r32/r16 float formats

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

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:

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

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 +

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

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

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)

On Tue, Apr 19, 2016 at 11:01 AM, Daniel Melo Jorge da Cunha <dmjcunha at gmail.com> wrote: > 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(...)?

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

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,

Unity3D seems to be working in wine fairly well, despite a few non-critical problems. One such problem is that when a .blend is imported, Unity complains with "Blender could not be found" and instructs me to "Make sure that Blender is installed and the .blend file has Blender as its 'Open with' application!" I installed the windows version of Blender in wine (first

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Would be nice if someone could glance at this... I suppose I could also compare object files. Yeah, I should probably do that. src/nv10_exa.c | 8 ++++---- src/nv30_exa.c | 20 ++++++++++---------- src/nv40_exa.c | 8 ++++---- src/nv50_accel.c | 6 +++--- src/nv50_accel.h | 1 + src/nv50_exa.c

Hello, I attempted doing this a while back, before I really understood what was going on. I got some advice that went totally over my head, and I dropped the issue. I think I'm much better-prepared to tackle the issue this time around. To recap, nv30 (and nv40) hw can't handle certain color/depth format combinations. Specifically, a 16-bit color format must be paired with a 16-bit depth

video card: X1950gt with ati limited driver linux: ubuntu 8.04 wine: 1.1.6 updated from the apt-get today, i try to install cod4 which is my favorite game.And it is my first time to use wine. i just mount the iso file, and run the setup.exe in the iso.Everything is ok at begin,but the error came out when the installation was going to finish.A window came up,said some errors with

On Tue, May 20, 2014 at 4:51 PM, Marek Ol??k <maraeo at gmail.com> wrote: > On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> Hello, >> >> I attempted doing this a while back, before I really understood what >> was going on. I got some advice that went totally over my head, and I >> dropped the issue. I think I'm much

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/nvc0_accel.c | 2 +- src/nvc0_accel.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/src/nvc0_accel.c b/src/nvc0_accel.c index 52a17db..0682806 100644 --- a/src/nvc0_accel.c +++ b/src/nvc0_accel.c @@ -313,7 +313,7 @@ NVAccelInit3D_NVC0(ScrnInfoPtr pScrn) PUSH_DATA (push, 0x00000001); BEGIN_NVC0(push,

I've been looking at REnouveau dumps to check how the blob does the clear buffers thing and they seem to do it a bit differently than what you committed, so I tried a new version of the clear functions (see how I changed it below) with a little test: Setup 2 texture render targets (and a depth target) and glClear them to a color changing with time, then render a triangle textured with the