| Age | Commit message (Collapse) | Author |
|---|
|
The rs690 has an rs4xx style vertex-shader less 3D engine. It uses the new
r500 output engine though. It also needs a new drm with rs690 support,
which is just getting cleaned up.
|
|
|
|
This fixes 3D rendering on x700 SE chips. Reported
by Kano.
|
|
|
|
this is wrong since even if ddx has not set up a surface reg to cover the z
buffer we should pretend it has on those rv100 chips since they presumably do
not do z buffer tiling if not using hyperz, so we can use linear addressing
just the same. Doesn't seem to fix #13080, but it's wrong anyway and the bug
almost certainly broke newer non-tcl chips.
|
|
This seems to have been mismerged with the DRI interface changes.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This pulls the top level createNewScreen entry point out of the drivers
and rewrites __driUtilCreateNewScreen in dri_util.c to be the new entry point.
The change moves more logic into the common/ layer and changes the
createNewScreen entry point to only be defined in one place.
|
|
|
|
The screenConfigs field of __DRIscreen points back to the containing
__GLXscreenConfigs struct. This is a serious abstraction violation; it
assumes that the loader is libGL and that there *is* a __GLXscreenConfigs
type in the loader.
Using the containerOf macro, we can get from the __DRIscreen pointer to
the containing __GLXscreenConfigs struct, at a place in the stack
where the above is a valid assumption. Besides, the __DRI* structs shouldn't
hold state other than the private pointer.
|
|
Many DRI entry points took a __DRInativeDisplay pointer and a screen
index as arguments. The only use for the native display pointer was to
pass it back to the loader when looking up the __DRIscreen for the given
screen index.
Instead, let's just pass in the __DRIscreen pointer directly, which
let's drop the __DRInativeDisplay type and the getScreen function.
The assumption is now that the loader will be able to retrieve context
from the __DRIscreen pointer when necessary.
|
|
Implementation guidance by Michel Dänzer, final testing by Timo Aaltonen.
|
|
|
|
glxgears and googleearth now run so that seems like a good start
Thanks to Aapo Tahkola for doing the 3D work on this so far, I got lost
after the GART changes.
|
|
|
|
Use _mesa_reference_framebuffer() and _mesa_unreference_framebuffer() functions
to be sure reference counting is done correctly. Additional assertions are
done too. Note _mesa_dereference_framebuffer() renamed to "unreference" as
that's more accurate.
|
|
Getting proper SIN and COS wasn't as easy as it appeared.
I had to make make some changes to the fragment program code.
general FP changes:
- support HHH swizzle for vector instructions.
- don't copy a source to a temp when it is not XYZW swizzled, but
combine the two and have the swizzle resolve any issues.
(saves temps/instructions with more elaborate shader code)
- fix overflow in cnstv[].
|
|
|
|
Added code to track the drawable bound to the context for reading. In
addition, when a drawable is initially bound (for reading or drawing)
or when the size of the drawable changes, update the size of the
framebuffer object that back the drawable (for software fallbacks).
Deprecate the old GetBufferSize interface.
Bump the driver date.
These changes were tested with wincopy on both direct rendering and
accelerated indirect rendering (AIGLX).
|
|
nearly the same as outlined in bug #4707, except it disables perspective correction for point sprites to make them actually work. And, separate the state atom into two as the tcl parameters would overwrite vertex program parameters when active. Also implement the GL_VERTEX_PROGRAM_POINT_SIZE_ARB option to make vertex programs outputting a point size work correctly (untested). Smooth points will still always be size 1. While here, enable gouraud shading for fog when using fog coord.
|
|
It does 2 things:
1) Allows you to disable S3TC, wine-games sometimes need S3TC enabled.
2) Disable fallbacks that usually have low impact.
|
|
|
|
not new enough on r200
|
|
instead of 8k (the reasons why it was exactly 8k are unclear). Add register defines, sanity code, fix potential issue with wrong statechange order when disabling fragment programs.
|
|
|
|
|
|
to need 1.6 drm where this first appeared.. this fixes r300 on PCIE
|
|
|
|
|
|
|
|
|
|
enable all texture units by default on those cards (3 for radeon, 6 for r200). Fix the usually forgotten DRIVER_DATE accordingly.
|
|
|
|
known by ddx (probably secondary ids, non-existant cards and similar). Add rs400 to the family enum, and configure the rv410 like a 2 quad chip (?)
|
|
with different methods to calculate the announced maximum texture sizes. Default is still the same (that is, radeon/r200 default to not announce anything which might not fit, i830/i915 default to 1 texture must fit). Bug #5785.
|
|
|
|
(regression from introducing unfied initialization). Fix wrong (so far unused) family assignment for r100 cards.
|
|
|
|
|
|
using only GART memory for textures instead of segfaulting in the texture
management code. (Bug 5115)
|
|
|
|
- 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.
|
