similar to: [PATCH 1/2] nv50: regenerate rnndb headers

These are copied directly from the mesa repository. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/hwdefs/gm107_texture.xml.h | 365 +++++++++++++++++ src/hwdefs/nvc0_3d.xml.h | 867 +++++++++++++++++++++++++---------------- 2 files changed, 892 insertions(+), 340 deletions(-) create mode 100644 src/hwdefs/gm107_texture.xml.h diff --git

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

I believe I've addressed all the feedback from the first time around, and also made fixes necessary for GM20x based on testing results. I believe now it should actually work for all GM10x and GM20x. Further, GP10x should be very easy to add, but without someone to actually test I didn't want to claim support for it. Ilia Mirkin (7): exa: add GM10x acceleration support hwdefs: update

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

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

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

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

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

On 17/01/14 02:23, Ilia Mirkin wrote: > This is needed since commit 9baa45f78b (st/mesa: bind NULL colorbuffers > as specified by glDrawBuffers). > > This implementation is highly based on a larger commit by > Christoph Bumiller <e0425955 at student.tuwien.ac.at> in his gallium-nine > branch. > Ilia, Do you know why we cannot set the rt height to 64? After all you

The main patches are from Christoph. Unfortunately they're a little beyond my understanding of all the vertex-related details, but they generally seemed fine. I'm just going to push these unless someone steps up to review them. Christoph Bumiller (2): nvc0: add support for indirect drawing nvc0: fix translate path for PRIM_RESTART_WITH_DRAW_ARRAYS Ilia Mirkin (1): nouveau: check if

This is needed since commit 9baa45f78b (st/mesa: bind NULL colorbuffers as specified by glDrawBuffers). Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Not sure whether something needs to be done to clear out the old RT_* settings for that index buffer, or if things are cleared out implicitly. Perhaps instead of skipping indices, RT_CONTROL needs to be adjusted with 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:

So we are currently doing tests and complying with them in our Emulator. Currently the conditional rendering test does not pass (no wonder we not even implement it). I've been looking at the current documentation https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L796 So far I don't understand how the cond address is used and to what it's compared.

So I have been going on over the documentation trying to figure out the exact layout of Pitch Linear Textures and find some missing values. First Question: What's the correct layout of pitch linear textures in memory? Is padding of the pitch added at start or at the end? Do they have some kind of header? Currently I see them as a normal texture matrix with just pitch at the end of each row

This patch-series implements the ARB_viewport_array for nvc0 and does a little house-cleanig afterwords. Tobias Klausmann (3): nvc0: implement multiple viewports/scissors, enable ARB_viewport_array nvc0: mark scissor in nvc0_clear_{} nv50/ir: Remove NV50_SEMANTIC_VIEWPORTINDEX and its last consumer .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 -

This patch-series implements the ARB_viewport_array for nvc0 and does a little house-cleanig afterwords. V2: Add Release-Notes, mark this in GL3 as done for nvc0 Don't mark the scissors dirty when we don't need to do that Tobias Klausmann (3): nvc0: implement multiple viewports/scissors, enable ARB_viewport_array docs: update GL3.txt, relnotes: mark GL_ARB_viewport_array as done

Hello, A user on an NVC3 card (GF106) is running into data errors on m2mf (class 0x9039) that we haven't seen before: http://people.freedesktop.org/~imirkin/nvc0-comparison/nvc3-2014-03-17-agashlin/glean/fbo.html http://people.freedesktop.org/~imirkin/nvc0-comparison/nvc3-2014-03-17-agashlin/spec/!OpenGL%201.1/copyteximage%201D.html Specifically the data errors 0x51 and 0x53, when running

As it turns out, with the proprietary firmware, the VP3 and VP4 interfaces are identical. Furthermore, this is all already implemented for nvc0. So these patches (a) move the easily sharable bits of the nvc0 implementation into the nouveau directory, and then (b) implement the other parts in nv50. The non-shared parts are still largely copies, but there are some differences, not the least of which

This series is to allow NVIDIA chips with shared memory to operate more efficiently (and to operate at all once we disable VRAM from the kernel driver) by allowing nouveau_screen to specify a domain to use for objects originally allocated into VRAM. If the domain is not overridden, the default NOUVEAU_BO_VRAM is used. A NV_VRAM_DOMAIN() macro is then introduced to be used in place of

I went through the gallium-nine tree and picked out nouveau patches that are general bug-fixes. The first bunch I'd like to also get into 10.2. I've reviewed all of them and they make sense to me, but sending them out for public review as well in case there are any objections. Unless I hear objections, I'd like to push this by Friday. Christoph Bumiller (11): nv50,nvc0: always pull