aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/r300/radeon_ioctl.c
Commit message (Collapse)AuthorAgeFilesLines
* R1/2/3/4/5xx: fixed calculation of cliprects in CopyBuffer.Dennis Kasprzyk2008-05-291-4/+6
|
* Use __DRIextension mechanism providing loader functionality to the driver.Kristian Høgsberg2008-02-291-3/+5
| | | | | | | Instead of passing in a fixed struct, the loader now passes in a list of __DRIextension structs, to advertise the functionality it can provide to the driver. Each extension is individually versioned and can be extended or phased out as the interface develops.
* More vblank cleanups.Michel Dänzer2007-10-301-4/+2
| | | | | | | | * Fix crash at context creation in most drivers supporting vblank. * Don't pass vblank sequence or flags to functions that get passed the drawable private already. * Attempt to initialize vblank related drawable private fields just once per drawable. May need more work in some drivers.
* Refactor and fix core vblank supportJesse Barnes2007-10-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Consolidate support for synchronizing to and retrieving vblank counters. Also fix the core vblank code to return monotonic MSC counters, which are required by some GLX extensions. Adding support for multiple pipes to a low level driver is fairly easy, the Intel 965 driver provides simple example code (see intel_buffers.c:intelWindowMoved()). The new code bumps the media stream counter extension version to 2 and adds a new getDrawableMSC callback. This callback takes a drawablePrivate pointer, which is used to calculate the MSC value seen by clients based on the actual vblank counter(s) returned from the kernel. The new drawable private fields are as follows: - vblSeq - used for tracking vblank counts for buffer swapping - vblFlags - flags (e.g. current pipe), updated by low level driver - msc_base - MSC counter from the last time the current pipe changed - vblank_base - kernel DRM vblank counter from the last time the pipe changed Using the above variables, the core vblank code (in vblank.c) can calculate a monotonic MSC value. The low level DRI drivers are responsible for updating the current pipe (by setting VBLANK_FLAG_SECONDARY for example in vblFlags) along with msc_base and vblank_base whenever the pipe associated with a given drawable changes (again, see intelWindowMoved for an example of this). Drivers should fill in the GetDrawableMSC DriverAPIRec field to point to driDrawableGetMSC32 and add code for pipe switching as outlined above to fully support the new scheme.
* Remove r200 dependencyJerome Glisse2006-09-261-24/+2
| | | | | | Remove r200 dependency from the code as r200 merged driver never worked (right ?) and we want to clean the code.
* Removing some of r200 dependency, cleaning up code a bit,Jerome Glisse2006-09-121-8/+2
| | | | | | | and fixing a couple of warning. More cleanup and shuffle to come. I have tested this change they might broke things especialy with r300_texstate.c change (format_x doesn't seems to be use at all by r300).
* retry on EBUSY instead of EAGAIN in radeonWaitIrq (it appears this was the ↵Roland Scheidegger2006-06-011-1/+1
| | | | intention as drm seems to never return EAGAIN) in all radeon drivers.
* Dave Reveman's patch for GLX_MESA_copy_sub_buffer supportBrian Paul2006-03-311-17/+42
|
* Dont rely on writebacksAapo Tahkola2006-03-311-0/+19
|
* First step of Radeon DRI unification:Eric Anholt2005-11-021-6/+6
| | | | | | | | | | | | - Makes all three drivers use the same screen structure and setup code, with a few ifdefs for the separate compilation to deal with symbols not being available to all drivers and the fact that we have no mechanism for dealing with different config options for different chip families in the same driver. These issues should be dealt with later. - Introduces IS_R[123]00_CLASS(radeonScreenPtr) macro for code for taking different paths depending on the general class of chipset. - Adds many new R300-class PCI IDs, though not all those listed in radeon_driver.c.
* Remove few outdated r200 files.Aapo Tahkola2005-10-261-0/+2
|
* remove SetBuffer(). Misc renderbuffer changes.Brian Paul2005-09-031-0/+4
|
* Fixes the glXGetProcAddress portion of the interface. Most of the functionsIan Romanick2005-07-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that are currently obtained via glXGetProcAddress and all of the XF86DRI functions are replaced with a funciton table. This table will be passed to __driCreateNewScreen. One of the functions in the table is getProcAddress. This allows some loaders to expose functionality not in all loaders. This will be immediatly used for glxEnableExtension (formerly known to drivers as __glXScrEnableExtension). libGL (and in the future libglx) expose this function so that drivers can enable GLX extensions. libEGL should exposed eglEnableExtension to enable EGL extensions. The same function cannot be used for both because the extensions have different names and (possibly) different semantics. Drivers can optionally use one, both, or neither. The key parts are in the __DRIinterfaceMethodsRec structure in dri_interface.h. A pointer to one of these structures is passed into __driCreateNewScreen. Because of this, the version of the API is bumped to 20050725. Since the previous version(s) were never in a release, their existance is erased. I was actually a little surprised by how much code this cuts from the drivers. A lot of glXGetProcAddress calls disappear, and a lot of version checks go with them. Nice. The one thing I'm not sure of is removing __glXInitialize. For some reason that function was in the glXGetProcAddress table, but *nothing* in the Mesa tree used it. Did something with DRI conf. use this function? It seems odd...
* -"fix" page flippingAapo Tahkola2005-06-301-0/+18
| | | | -use depth tiling if tiling is enabled
* Modifying to build against current Mesa. Disabled r200*.c files since they ↵Aapo Tahkola2005-04-241-1/+2
| | | | didnt want to build anymore.
* Huge dumb drop. State:Nicolai Haehnle2004-10-151-1/+6
| | | | | | | | | | - Color buffer clear is accelerated, but flickers (possibly caused by a recent DDX or Mesa change or bad merge) - Everything else uses software fallback rendering - There should be no clipping-related artifacts with the sw-clipspan-fixes.patch against Mesa (posted on dri-devel) - Multiple clients should be rock solid with a DDX patch that is soon to come (soon = within the next hour or so)
* Initial revisionNicolai Haehnle2004-09-281-0/+348