dri-announce

[Dri-announce] Merge Complete

[Alan H. <al...@fa...>]

O.k.

I'm committing the final part of the merge now. I have build tested
it and it does build fine, although I've not tested the drivers.

The radeon was indeed the most difficult in this merge due to
the divergence of the Clone modes in the XFree86 CVS etc. Kevin, is
going to take a closer look at the radeon driver this weekend so that
he's happy with the merge. But if anyone does find problems - please
report them, or the other CVS committers can fix it up as they need.

I've tagged the trunk before I started with the tag 'trunk-20021022' and
after the merge with 'X_4_2_99_2-20021023-merge' for those who
need to diff.

Hopefully there aren't too many problems.

Alan.

[Dri-announce] Merge

[Alan H. <al...@fa...>]

I'm about to start a merge of the XFree86 CVS and bring that into
the DRI CVS trunk. No doubt with the trees diverging quite a bit, that
there will undoubtably be some build bustage along the way.

I'll be bringing it across in stages to try and minimize the disruption.

Jose - it may be worth disabling the automated builds for a few days.

Alan.

[Dri-announce] New MGA DRI driver, templated DRM

[Gareth H. <ga...@va...>]

I've just committed two large chunks of work to DRI CVS.

Templated DRM:
--------------

The core DRM now consists of driver-customizable template files, that
each driver needs to include manually.  This fixes a number of problems,
and makes writing new drivers significantly easier.  Indeed, drivers
that don't need to handle DMA are now trivial.  An example is the new
tdfx kernel module:

tdfx.h:

/* This remains constant for all DRM template files.
 */
#define DRM(x) tdfx_##x

#define __HAVE_MTRR		1
#define __HAVE_CTX_BITMAP	1


tdfx_drv.c:

#include <linux/config.h>
#include "tdfx.h"
#include "drmP.h"

#define DRIVER_AUTHOR		"VA Linux Systems Inc."

#define DRIVER_NAME		"tdfx"
#define DRIVER_DESC		"3dfx Banshee/Voodoo3+"
#define DRIVER_DATE		"20010215"

#define DRIVER_MAJOR		1
#define DRIVER_MINOR		0
#define DRIVER_PATCHLEVEL	0

#include "drm_drv.h"


#include "drm_agpsupport.h"
#include "drm_auth.h"
#include "drm_bufs.h"
#include "drm_context.h"
#include "drm_dma.h"
#include "drm_drawable.h"
#include "drm_fops.h"
#include "drm_init.h"
#include "drm_ioctl.h"
#include "drm_lock.h"
#include "drm_memory.h"
#include "drm_proc.h"
#include "drm_vm.h"
#include "drm_stub.h"


The new architecture also avoids symbol clashes when building multiple
drivers into the kernel, and cleans up the build process as a whole.  I
have tested the mga, r128, radeon and tdfx drivers, and done initial
work on the i810, so I encourage other authors/maintainers to move their
drivers to the new architecture.


New MGA driver:
---------------

I have also completely rewritten two core pieces of the MGA DRI driver:
the kernel module and the DRI bootstrapping code in the 2D driver.  The
DMA handling has been completely redone, and at its core consists of
three functions that total less than 100 lines of code.  The driver now
no longer uses interrupts to manage DMA, and uses the primary DMA space
in a ring buffer-like fashion.

This is a major step forward, and will greatly improve the stability and
robustness of the driver.  I strongly encourage people who have tried
the MGA driver and had bad experiences to try the new code out.  I still
need to finish the engine reset code that is used to recover from
lockups and so on, but this is a small amount of work.  The new code
shouldn't be locking the engine anyway :-)

Please let me know if you have problems with the new code.  I would like
to work with anyone who has problems to make sure any remaining issues
get ironed out quickly.

-- Gareth

[Dri-announce] tdfx-3-0-0 branch merged into trunk

[Gareth H. <ga...@va...>]

The major reworking of the tdfx driver that took place on the
tdfx-3-0-0-branch has been merged into the trunk.  This represents a
large departure from the original standalone Mesa FX driver that the
first DRI driver was based on.

This driver has been specially taylored for the Glide 3 API, and as a
result demonstrates very good performance.  A lot of work has gone into
supporting the Voodoo 5, including GL_EXT_texture_env_combine support
and the use of several Glide extensions.

Enjoy!

-- Gareth

[Dri-announce] ATI Radeon work merged into the trunk

[Kevin E M. <ma...@va...>]

Hi all,

I've just finished merging the latest ATI Radeon and Rage 128 work onto
the trunk.  This work adds 3D support for the Radeon cards and enhances
3D support for Rage 128 cards as well.  You should be able check out the
code from the DRI CVS trunk.  Please let us know how it works for you.

Thanks,
Kevin

[Dri-announce] ati-4-1-1 r128 driver

[Gareth H. <ga...@va...>]

I have just completed merging the ati-4-1-1 branch back into the trunk. 
This is a significantly more mature DRI driver for the r128, featuring:

  - Full control of the Concurrent Command Engine (CCE) by the r128
    DRM module, including all programming of 3D commands.  Improved
    security, less overhead in command generation.
  - Indirect buffers for texture uploads.  Reduces copy overhead as the
    HW-format texture image is written directly into AGP space for
    submission to the card.
  - Indexed vertex buffers, the "elt path".  Useful glDrawElements
    accelerated rendering path, builds vertices from array data and
    then renders primitives with indices into this array rather than
    copying individual vertices into a contiguous buffer.
  - Tiled depth buffer for more optimal memory access patterns.
  - Better static partitioning of offscreen memory, resulting in more
    local texture memory.

The performance, stability and interactivity should all be greatly
improved over the XFree86 4.0.1 driver.  At this time, support for PCI
cards has been removed (it was essentially useless anyway).  This will
be added back when PCI GART is done.

-- Gareth

[Dri-announce] TDFX 2.0 Branch Merged on Trunk

[Daryll S. <da...@va...>]

The TDFX 2.0 branch has been merged onto the trunk. The primary goal of
this branch was preliminary support of the V5. This support should be
functional, but not yet complete. To use any of the 3D features of the
V5 you'll need a new version of Glide which hasn't been released
yet. The features/bugs include:

     2D support for the V5

     Locking is moved down into driver for V3,V4,V5 boards. (The X
     server used to grab the lock around it's entire execution. Now it
     only grabs the lock when drawing, so mouse and keyboard input don't
     require the lock.)

     16 & 24 BPP 3D support

     Hardware stencil support

     V5 only enables one chip

     No antialiasing

     No page flipping

     No Glide support

     Other bugs

All the misfeatures listed above are things we are in the processor or
plan to fix.

						- |Daryll



	 

[Dri-announce] New dri-users mailing list

[Daryll S. <da...@pr...>]

Now that we're starting to get releases of XFree that include the DRI
code, I figured it was time to setup a dri-users mailing list. You can
sign up for the list on the project page or here:
     http://lists.sourceforge.net/mailman/listinfo/dri-users

The idea is to separate the development discussions (dri-devel) from the
user setup and application questions (dri-users). Right now the traffic
on dri-devel has been pretty good, but I want to have the user list in
place so that we don't get into bad habits on the development list.

							- |Daryll

[Dri-announce] New: DRI compilation and user guides

[Brian P. <br...@pr...>]

I've uploaded two new documents to the DRI web site:

http://dri.sourceforge.net/DRIcompile.html
http://dri.sourceforge.net/DRIuserguide.html

The first documents how to download, compile, install and test the DRI
and is intended for developers.

The second describes configuring, using and trouble-shooting the DRI
and is intended for all DRI users.

Hopefully these will help to reduce the number of problems reported
on the mailing lists.

Feedback and suggestings for improvements to these documents is
welcome.

-Brian

[Dri-announce] New Checkins

[Daryll S. <da...@pr...>]

I did some major work on the texture engine in the tdfx driver. This
appears to fix all the Q3A problems. I also did a little work on the 2D
driver to make the system dynamically allocate texture memory according
to the display resolution, and to allow VT switching to work. We also
slipped in a quick fix to make Mesa use AMD 3DNow!
optimizations. Finally, we've renamed the device entries from
/dev/graphics to /dev/dri and /proc/graphics to /proc/dri. The old names
clashed with another device on SUSE distributions. Finally, I updated
Mesa to the 3.1 release. (I need to send in patches to Mesa for my
changes) 

There's a lot of good fixes in there. They are pretty much spread out
throughout the tree, so you'll need to do your CVS updates from the top
of the tree, and do a full install when it builds. Don't forget to run
it as 'cvs update -d -P' so that you create new directories and prune
empty ones.

I'll be doing some work on DGA and the 2D engine needs some serious
attention. It is showing some bad blit bugs. I don't know if I'll get
these checked in before I leave for Christmas break. 3.9.17 is due out
before the end of the year and that'll be a major X update. We'll
include that and track down some more of the bug reports when I get back.

This will probably be last big announcement until 2000 (no I'm not going
to say "the new millenium.") I hope every has a happy holiday season.

					- |Daryll

[Dri-announce] Welcome and Status

[Daryll S. <da...@pr...>]

Hello everyone. I haven't had a chance to do a welcome message yet, so
I'm going to take this opportunity to do so. Welcome to the DRI
development project. I suspect that if you're signed up already, you
know what the DRI is about, so I'm not going to go into that, but I
would like to talk a little about why we set this list and what we're
hoping to accomplish.

SourceForge provides a number of services for us, a CVS repository, a
bug database, and mailing lists. I'm not a big fan of on-line forums, so
I don't think they'll get used much. They also provide a task managment
system, but I'm not sure yet how that will be used.

We're using this site because we want to get more of the DRI development
out in the open. We want to make our work available to as many
developers as possible as quickly as possible and this seemed like the
best solution.

We've currently got about 30 people on the development list. That's
great. I'm interested in hearing from you as to what you want to
accomplish with this code. A few people have talked to me about porting
to other architectures (Alpha and PPC) and to other OSes (*BSD). If
you've got a particular project you want to tackle, please post it, so
that those of you who share interests can start getting together. If
you're looking for something to do and have an area of interest, we can
probably make suggestions. We need people to submit bug reports on
pieces that don't work and people to look at the bug list and fix them!

This site is not meant to be static, but we need suggestions from
you. So far, I've setup what I think is the minimal structure. We've got
a really basic web page. We've got a few mailing lists. We've got some
bug tracking (with no categories). As the projects develop we'll need
your input to make the process better. Let me know what you need.

There are three mailing lists. The devel list is for discussions about
DRI development. This is where most of the traffic will be. The announce
list is for announcements of new projects, major checkins, etc. The
patches list is for you to send in patches to the DRI and the place
where all checkins will be recorded. The idea is that you can go there
to see any code anyone has submitted to us and to see from the checkin
logs if we've applied the patches.

Now to the status. The 3dfx code is the first fully operational DRI
driver suite. The code I checked in earlier today is in pretty good
shape. It is running an increasing number of applications and we're
knocking down bugs in the different sections. Q3A has been a driving
application and I can now say we're running it fairly well. We know it
isn't bug free, but it should be a good place for you to start
extending. 

We've also started checking in code for a couple other drivers, the
Matrox G200, and the Intel i810. Those aren't operational yet, but the
code is there to look at and start working with.

So, that does it. Welcome to the DRI development list. I hope you all
find it useful and are able to contribute to the project.

					     Happy Holidays,
						   - |Daryll