[FrontPage] [TitleIndex] [WordIndex] 

Proposed Future Features

Refer also ToDo put new items there (?)

  1. Clarify the notion of what is a "current" and what is an "old" renouveau run. Currently the notion is time based (<30 days, >30days, none), the >30 days case is confusing to renouveau contributors whos cards are listed as yellow, especially when the tests renouveau performs for their card have not changed since the renouveau results for the run >30 days ago were emailed. What is proposed is for "green" to signify that there is a current renouveau run for the specific card and "yellow" to signify that there has been a renouveau run submitted but new tests have subsequently been added to renouveau. The definition of "red" remains unchanged. There are two ways of implementing this;

    1. Simple method - have renouveau include the cvs checkout date in the results emailed. In the script which updates http://users.tkk.fi/~jpakkane/ren/ check that the cvs revision in the submitted results matches renouveau cvs-head. While the minimal overhead approach the problem with this approach is that not all tests need to be run on all cards (e.g an nv5 will never support XvMC in hardware so running XvMC tests on an nv5 is pointless) so if a test is added that only effects XvMC users then we dont want nv5 users thinking there is the need to re-run renouveau.

    2. Complex method - maintain a list of cards which have the features that each new renouveau test exercises. When the new test makes it into cvs-head then update only the effected cards status to "yellow". The submitted information contains the results of the tests exercised, update the script which updates the status to check the list of tests run against the list of tests needed for each card class and use this for the basis of the "green"/"yellow" designation.

    3. As proposed by JussiP at 09:38 in http://lattice.u-strasbg.fr/irclogs/nouveau-2007-04-22 and subsequently raised again at 12:20 in http://lattice.u-strasbg.fr/irclogs/nouveau-2007-04-24 use an RCS stamp in a header so when developers want to increment the renouveau version they just commit to cvs changes to the stamp. Provides only one value to change - does this give enough granularity? If someone forgets to change what happens then? dump version breakage/mismatches?

  2. Have gmail->sf script run by kmeyer record email address of people who can test specific cards? Not discussed on IRC yet, may be seen as possibly scaring people away...? We have the email address in the sf information (submitter.txt) anyway so why not put this information to use to help the project?

  3. Add renouveau tests for OpenGL tests which we dont yet have (see http://lattice.u-strasbg.fr/irclogs/nouveau-2007-04-22 00:04), which version of the OpenGL spec - glxinfo tells us the version that specific nVidia driver versions support, 

    e.g OpenGL version string: 2.1.0 NVIDIA 96.31, with nVidia driver 1.0.9631 installed

    so can use this in conjunction with http://www.opengl.org/documentation/ to exercise features we need to test. Presumably we are interested in tests that get us features that Quake3 needs in order to get to the Q3 milestone as we communally know enough to get glxgears working - at least on one card. What OpenGL features does Q3 need? Didnt the Quake (Q1) game engine print the GL_ features used when loading?

  4. Expand renouveau tests to explore xvmc, need a known data stream to use as basis for xvmc so can spot in the data flowing to card?

Work on implementing Future Features for Renouveau

1. Refining REnouveau Run Status

cvs in my experience (+google) doesnt have a nice simple hash that encapsulates the complete state of the repository like git does. Therefore we need to extract version information from the cvs data we have. cvs status -l is too verbose for what I was thinking of for version tracking. Parsing CVS/Entries to give filename/version pairs seems to be the sanest way to get what I think we want.

Not everyone builds from cvs - hugsie has mentioned on IRC that he is building and packaging renouveau for fedora users, see also http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg30505.html - so CVS/Entries will not always be in the right place when running renouveau. So need to allow for this in how we time when we extract filename/version data and what we do with it, likely best way is to build into the renouveau binary. (does bloat the renouveau binary a bit, but CVS/Entries is only 1.9KB so not a huge bloat factor).

Aim to have the versions of each file from cvs available in the renouveau run output, then when one of the devs enables a new test update the version of the specific file required against only the effected cards. e.g when marcheu reenabled the interesting regs test in main.c v1.121he was interested in specific cards, possible cards >G70?, update the version required for cards >G70 such that current renouveau runs for these cards have to include main.c v 1.121.

This requires a mapping be created between card pciids? and current cvs file versions, JussiP's script would consult the mapping when generating the status page and set current, previous status accordignly. (Inherently relies on cvs increasing the version number of files as changes are checked in).

How handle old renouveau runs prior to cvs version information? Retain existing approach until new dumps are recieved?

Proposed steps;

1. Parse CVS/Entries into an intermediate file "cvs_entries.h" (note: have to make sure this is integrated into Makefile in such a way that parsing happens during make dist and the file "cvs_entries.h" makes it into the tarball produced by make dist) refer cvs-entries-parse.c for proposed parser (written in C so renouveau build does not require perl or python, etc) compile; 

$ gcc -Wall cvs-entries-parse.c -o cvs-entries-parse

use; 

$ ./cvs-entries-parse ./CVS/Entries cvs_entries.h

Sample cvs-entries.h

2. #include "cvs_entries.h" into renouveau build (sample program output-test.c using "cvs_entries.h" generated by parser)

3. output contents of "cvs_entries" during renouveau run into an file, file named to match rest of renouveau output so picked up by existing instructions on REnouveauDumps, 

$ tar cvjf 10de0151.tar.bz2 card*.txt

As pointed out on IRC if we use the same file naming rules as the rest of renouveau then we dont break (or require any changes to) the automated script KoalaBR wrote.

Proposed Renouveau Patch

25/Apr/2007 careym-cvs-info.patch card_10de-0393_cvs_fileinfo.txt Nvidia_10de-0393.tar.bz2 

careys@hereford:~/nouveau/renouveau$ ./renouveau
9/75 test_draw_buffer
No Stereo context. Skipping stereo tests
No double buffering. Skipping double buffer tests
No GL_EXT_vertex_weighting extension.
No GL_NV_texgen_emboss extension.
74/75 test_interesting_regs
careys@hereford:~/nouveau/renouveau$

4. tweak JussiP's script (http://nouveau.cvs.sourceforge.net/nouveau/statuspage/) to do the appropriate tracking. (may have to update kmeyer gmail -> sf script as well, to ensure the file makes it to sf, havent seen gmail->sf script by kmeyer yet to know whats required here)

2013-03-24 13:16