similar to: Some cosmetic NV10TCL method changes.

Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- I haven't pushed these changes to renouveau.xml yet, I'll do it soon if you guys are OK with this. nouveau/nouveau_class.h | 1036 +++++++++++++++++++++++----------------------- 1 files changed, 518 insertions(+), 518 deletions(-) diff --git a/nouveau/nouveau_class.h b/nouveau/nouveau_class.h index c5fe5d7..87e167b

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

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

- This avoids problematic "reloc'ed while mapped" messages and some associated corruption as well. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++ src/gallium/drivers/nouveau/nouveau_stateobj.h | 13 +++++++++++++

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>

So, with all the nouveau_class.h changes lately it's become rather difficult to keep libdrm synced up with a particular mesa version. This is much like what happens when we break our kernel ABI, but on a far more regular basis so it has a larger impact. I'm proposing we drop nouveau_class.h from libdrm again, and move it back to the ddx and mesa trees where it can be updated at the same

* Kill the A8+A8 hack. Recent enough X servers (>=1.7) fall back to ARGB glyphs for drivers not supporting A8 render targets. * Kill all the global state. It doesn't matter a lot yet but it might if we get multicard working at some point. * Other random clean-ups with no functional changes. Some numbers from x11perf -aa10text -aa24text -comppixwin10 -comppixwin500: * Before, with A

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

Hello, I found xf86-video-nouveau unable to compile on my system. Failing with two errors in nv_accel_common.c about NV50_2D_CLIP_ENABLE and NV50_2D_COLOR_KEY_ENABLE not being defined. Comparing the source to xf86-video-nv, i found the missing constants to be 0x290 for CLIP_ENABLE and 0x29c for COLOR_KEY_ENABLE. This got nv_accel_common.c to compile. I'd request these two constants to be

Printing without this could lead to the following output, while the values are not exactly zero: IMM[5] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} IMM[6] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} IMM[7] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} when printing the values as hex, we can now see the differences: IMM[5] FLT32 {0x00000019, 0x0000000f, 0x00000005,

Hi, yeah in the long run showing both in an ordered manner would be a nice thing to have! That would include patching the output and the tgsi parser (who wants to delete half the output to parse it again e.g. with nouveau_compiler). I can image an output similar to the one below: IMM[5] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} ^ IMM[5] FLT32 {0x00000019, 0x0000000f, 0x00000005,

(Adding just a bit to Jake's response) On Tue, Mar 26, 2019 at 11:31 AM Jake Ehrlich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Seiya, > > What should I prioritize? I suppose that improving llvm-objcopy is the >> most crucial work in this summer. > > > This is an opinion that will vary a lot from person to person. > +1! And don't forget that

Commit eb168e26aa63f11a47d70c4555cae30691a2cd57 changed the way pipe->clear works so I figured I'd try to make an updated version, so below is the diff - my concerns/uncertainties should be contained in the comments. Or maybe you want to do it the way NV40 does it, just calling surface_fill through a utility function (althoug this does currently seem to only clear one color buffer) .

http://bugs.freedesktop.org/show_bug.cgi?id=20130 Summary: GT200: nv50 chipset 0xa0 lockup Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

--- src/gallium/drivers/nv50/nv50_program.c | 2 +- src/gallium/drivers/nv50/nv50_screen.c | 17 ++++++++--------- src/gallium/drivers/nv50/nv50_state_validate.c | 10 +++++----- src/gallium/drivers/nv50/nv50_transfer.c | 8 ++++---- src/gallium/drivers/nv50/nv50_vbo.c | 24 ++++++++++++------------ 5 files changed, 30 insertions(+), 31 deletions(-)

I'm running on Sun Blade 2500 with a GeForce 8400 GS PCI. After (maybe?) fixing a few errrors with bo allocation, I'm getting a lot of IB_EMPTY errors, ultimately resulting in a GPU lockup. I don't have any sort of framebuffer visible. After reading dma-pusher.txt, I see "An attempt to submit IB entry with length zero will raise DMA_PUSHER error of type IB_EMPTY." How would

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

This patch changes the pushbuffer ABI to: 1. No longer use/expose nouveau_pushbuffer. Everything is directly in nouveau_channel. This saves the extra "pushbuf" pointer dereference. 2. Use cur/end pointers instead of tracking the remaining size. Pushing data now only needs to alter cur and not both cur and remaining. The goal is to make the *_RING macros faster and make the

Hallo, ich schreibe einfach mal deutsch, und hoffe dass Du das auch verstehst (if not write me back in English). OS X 10.3.9 Ich habe R 2.1.0 installiert, und das Programm hat auch funktioniert. Will wenig sp??ter wieder mit R arbeiten, es l??sst sich aber nicht mehr starten. "Das Programm R wurde unerwartet beendet", w??hrend ich versuche es durch Doppelklicken auf das R.app-symbol

On 06/28/2013 04:25 AM, Ady wrote: > > @Wim and @All, > FWIW, in 2013-February there still were other additional issues with > some kernels, including memory testers, so having a problem to boot > memtest(86|86+|other) might or might not be related to the > "PXE-stack-smasher" bug. > > For example, in v.4.06, the cfg entry could be: > LINUX memtest >