Re: Announcing Piglit, an automated testing framework

2007-03-16 Thread Oliver McFadden 
This is very interesting and useful. Seems it's already showing some areas where
improvement is required in the R300 driver.

I'd suggest getting an account on freedesktop.org and a Git repository there. :)
Sourceforge is... less than reliable.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 10303] glFogCoordPointer broken in DRI Radeon R300 driver

2007-03-16 Thread bugzilla-daemon 
http://bugs.freedesktop.org/show_bug.cgi?id=10303





--- Comment #5 from [EMAIL PROTECTED]  2007-03-16 20:09 PST ---
I agree with that. If there are no objections I can change the vendor string
for R300.  I think that R300 does still use some Tungsten Graphics code, but it
should be acceptable to change the vendor string because the code has
appropriate copyright notices.  I will be away for some of the weekend, so if
there are no objections by the time I'm back I'll commit this change. 


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Announcing Piglit, an automated testing framework

2007-03-16 Thread Nicolai Haehnle 
Hello,

back when I was actively working on DRI drivers almost three years
ago, I always felt uneasy about the fact that I didn't have an
extensive array of tests that I could rely on to test for regressions.

Now I've decided to do something about it. I've taken Glean and some
code from Mesa and wrapped it with Python and cmake glue to
- execute OpenGL tests without user interaction and
- neatly format the results in HTML

You can find the current version (and a sample HTML summary, to get an
idea of what they look like at the moment) at
http://homepages.upb.de/prefect/piglit/

The idea is to make testing dead simple for driver developers. I
believe that Piglit already makes it quite simple, but I'm sure
there's still room for improvement.

My current plans are:
- Hunt some bugs in R300, to get a better feeling for how the tool
fares in practice
- Integrate tests from Mesa; unfortunately, this needs manual work
because those tests are mainly interactive, but it's definitely
necessary to make this useful

I'm also considering setting up a public repository somewhere, perhaps
on Sourceforge.

Please give it a try when you have a little time to spare and tell me
if you find it useful (or more importantly, why you don't find it
useful), and where it could be improved.

Thanks,
Nicolai

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 10303] glFogCoordPointer broken in DRI Radeon R300 driver

2007-03-16 Thread bugzilla-daemon 
http://bugs.freedesktop.org/show_bug.cgi?id=10303





--- Comment #4 from [EMAIL PROTECTED]  2007-03-16 19:41 PST ---
> I think it was Vladimir Dergachev who did a lot of the initial work, at least
> from looking at the R300 Sourceforge site, but I expect that a lot of people
> made significant contributions, so maybe the vendor string should be "Vladimir
> Dergachev et al" or similar.

It's correct that Vladimir wrote the original reverse engineering tools.
Virtually all of the reverse engineering that was actually necessary to start
the driver was done by me, however (some time in late 2004, I think), which is
when I also started the driver. I discontinued my work on the driver because I
ran into hard lockups that I just didn't understand. It's cool to see that
other people continued the work to a point where I can use the driver today.

I could claim that the driver is "mine" and it should be "Nicolai Hähnle et
al", but that would be an insult to all the people who kept development going
when I couldn't continue.

Anything involving attribution in such a prominent place is just bound to cause
hard feelings. I'd remove the name completely, but then people might confuse
the driver with ATI's binary driver. Therefore, I suggest we replace it with
"The DRI project", because that really describes it best.

One can always put a list of authors where it really matters: in the source.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

question about drm_close() for BSD

2007-03-16 Thread Chaohong Guo 
hi, guys,

I am trying to understand the DRI/DRM code. I know about
Linux, but have no knowledge of FreeBSD. Could you please
kindly help me on the following question about DRM on FreeBSD?

For FreeBSD, in drm_close(), there is the following code
to release drmlock in case that current process is dying while
holding drmlock.

---
int drm_close (struct cdev *kdev, int flags, int fmt, DRM_STRUCTPROC *p)
{
...
if (dev->lock.hw_lock && _DRM_LOCK_IS_HELD(dev->lock.hw_lock->lock)
&& dev->lock.filp == filp) {
DRM_DEBUG("Process %d dead, freeing lock for context %d\n",
DRM_CURRENTPID,
_DRM_LOCKING_CONTEXT(dev->lock.hw_lock->lock));
if (dev->driver.reclaim_buffers_locked != NULL)
dev->driver.reclaim_buffers_locked(dev, filp);

drm_lock_free(dev, &dev->lock.hw_lock->lock,
_DRM_LOCKING_CONTEXT(dev->lock.hw_lock->lock));
...
}
---
Here, filp is the pid of current process.


So, if this process executes the following code, will drm_close()
be called when drmClose(fd1) ? and is drm_lock forced-released while
this process still assumes it owns drmlock?

fd0 = drmOpen(/dev/dri/drm0);
fd1 = drmOpen(/dev/dri/drm0);
drmLock(fd0);
drmClose(fd1); <




thanks,
-minskey

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel