search for: rnndb

--- rnndb/nv50_pgraph.xml | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/rnndb/nv50_pgraph.xml b/rnndb/nv50_pgraph.xml index 92d69ea..6499631 100644 --- a/rnndb/nv50_pgraph.xml +++ b/rnndb/nv50_pgraph.xml @@ -93,6 +93,9 @@ <value value="0x23" name="XY_OUT_OF_BO...

--- rnndb/display/nv3_pramdac.xml | 67 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/rnndb/display/nv3_pramdac.xml b/rnndb/display/nv3_pramdac.xml index 13b6a7b..e236921 100644 --- a/rnndb/display/nv3_pramdac.xml +++ b/rnndb/display/nv3_pramdac.xml @@ -79,12 +79,...

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> --- src/gallium/drive...

...DO NOT EDIT manually! + +This file was generated by the rules-ng-ng headergen tool in this git repository: +http://github.com/envytools/envytools/ +git clone https://github.com/envytools/envytools.git + +The rules-ng-ng source files this header was generated from are: +- /home/skeggsb/git/envytools/rnndb/../rnndb/graph/gm107_texture.xml ( 22057 bytes, from 2016-02-12 03:01:43) +- /home/skeggsb/git/envytools/rnndb/copyright.xml ( 6456 bytes, from 2015-09-10 02:57:40) +- /home/skeggsb/git/envytools/rnndb/nvchipsets.xml ( 2908 bytes, from 2016-02-04 22:19:11)...

On 25/08/2014 20:58, Christian Costa wrote: > --- > rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++--- > 1 file changed, 34 insertions(+), 3 deletions(-) > > diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml > index 500cea9..e006dbe 100644 > --- a/rnndb/memory/nvc0_pbfb.xml > +++ b/rnndb/memory/nvc...

...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 generated files until a better solution is determined. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nvc0/nvc0_2d.xml.h | 380 ------- src/gallium/drivers/nouveau/nvc0/n...

...NV4, NV5, NV10 and maybe NV15 (which is logically pre-NV11) don't support big-endian mode. Not sure about NV1A, which was the IGP of the series and IIRC logically pre-NV11 as well (but clearly could only be used with x86 chips, since it was part of the motherboard). Aha, it's documented in rnndb: https://github.com/envytools/envytools/blob/master/rnndb/bus/pmc.xml <reg32 offset="0x004" name="ENDIAN" variants="NV1A-"/> -ilia

--- rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++--- 1 file changed, 34 insertions(+), 3 deletions(-) diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml index 500cea9..e006dbe 100644 --- a/rnndb/memory/nvc0_pbfb.xml +++ b/rnndb/memory/nvc0_pbfb.xml @@ -49,23 +49,54 @@...

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. https://github.com/envytools/envytools/blob/0d91b8bcef3ceb47ff0b114025d301edb790d472/rnndb/g80_defs.xml#L61 It says it uses 2 queries, how do I know which query it's talking off an...

...I was being unclear, I'm talking about https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nv50_display.c#L1808 and surrounding items. Looks like lut_clr sets 0x40000000 which was previously not used. Not sure what the difference between that and 0x00000000 is. This is what we have in rnndb for it: https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml#L408 So bit 30 is mode, set is "high res", unset is "low res". So really what we want is 0x80000000 which leaves the LUT enabled but uses the low-res mode? All this could use some playing-arou...

Hi, This is my work in documenting EVO. I did some RE to fill missing gaps. Best regards, Maxim Levitsky

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

So there's a register in Render Targets called Array Mode: https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L289 We've witnessed values of 1 and 6 (array mode -> layers) but we can't tell their meaning. Do you guys got any related info? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archi...

...y have some kind of header? Currently I see them as a normal texture matrix with just pitch at the end of each row but If I send the game this values, they go into an ternal loop. Second Question: Pitch Value in Render Targets. In the registers in https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L282 the pitch does not appear anywhere, where is it stored for Render Targets. Thanks in advance and I hope you guys can provide me some info. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/atta...

...NV15 (which is logically pre-NV11) don't support big-endian > mode. Not sure about NV1A, which was the IGP of the series and IIRC > logically pre-NV11 as well (but clearly could only be used with x86 > chips, since it was part of the motherboard). > > Aha, it's documented in rnndb: > > https://github.com/envytools/envytools/blob/master/rnndb/bus/pmc.xml > <reg32 offset="0x004" name="ENDIAN" variants="NV1A-"/> > ohh, I should have checked there.. yeah, will write a fix for it then. Before my patch we just always tried to switch...

...pre-NV11) don't support big-endian > > mode. Not sure about NV1A, which was the IGP of the series and IIRC > > logically pre-NV11 as well (but clearly could only be used with x86 > > chips, since it was part of the motherboard). > > > > Aha, it's documented in rnndb: > > > > https://github.com/envytools/envytools/blob/master/rnndb/bus/pmc.xml > > <reg32 offset="0x004" name="ENDIAN" variants="NV1A-"/> > > > > ohh, I should have checked there.. yeah, will write a fix for it then. > Before my p...

0xc0b5 is not in rnndb, I guess it should be GP100_COPY, right? Reviewed-by: Samuel Pitoiset <samuel.pitoiset at gmail.com> On 10/27/2016 04:02 PM, Ilia Mirkin wrote: > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > src/nouveau_copy.c | 2 ++ > src/nvc0_accel.c | 10 +++++++++-...

...ld let us know what those errors are? (Or, even better, provide the full table so that we'll have a better idea in future cases as well.) Here are a few that we know about, so you know exactly what table I'm talking about (our full list at https://github.com/envytools/envytools/blob/master/rnndb/nv50_defs.xml#L192): 0x04: INVALID_VALUE 0x05: INVALID_ENUM 0x08: INVALID_OBJECT 0x0c: INVALID_BITFIELD 0x3f: PRIMITIVE_ID_NEEDS_GP We read this data error value from mmio reg 0x400110. Furthermore, if you could provide any insight as to why we would see those errors on GF106 but not any other F...

...I feel like there should be a comment explaining the 0x40000000 > (connected to crystal). Or maybe we should be in general more strict > about using constants, I feel like those hardcoded magic numbers are > hard to understand by users. Well, true, but as long as it is well documented in rnndb, I think it is the proper way to go. Otherwise, we would need to maintain macros which we tried and failed at :s In this particular case, the comments at the top of the function should give all the information. We need to make the use of lookup known: $ lookup -a E4 0x61c884 0xc0000000 PDISPL...

Hello, I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: [ 0.000000] Linux version 5.9.0-rc8+ (zary at gsql) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri Oct 9 22:31:40 CEST 2020 ... [ 14.771464] nouveau 0000:01:00.0: GPU not supported on big-endian [ 14.771782] nouveau: probe of 0000:01:00.0 failed with error -38 big-endian? WTF? The