| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Previously they depended on format blocks, but after removing those
they started depending on format encoding.
|
|
|
|
Keeping this dynamically allocated for texture arrays.
Since we don't use it to store zslice offsets anymore
it's either 1 or 6 integers (cube) ...
|
|
|
|
width/height/depth arrays
|
|
Mip-mapped 3D textures are not arrays of 2D layers
with a mip-map layout like 2D textures, therefore we
cannot use image_nr == depth for them.
Making use of "volume tiling" modes now, the allowed
modes are 0xZY where Z <= 5 and y <= 5.
|
|
First, using width * block size as pitch is evidently
wrong if a block contains more than 1 texel.
For tiled textures, since a block occupies a contiguous
area of memory, y addressing in m2mf has to be done by
block index, not the y coordinate itself.
This should fix compressed textures.
|
|
|
|
The winsys once again has to know about textures it seems, so we need a
common representation between all our pipe drivers to store some
information the winsys will need.
Only the nv50 driver has been fixed so far.
|
|
|
|
The hardware expects a texture's tile mode to change with
the mipmap level.
Also, only multiply by block size once to obtain size.
|
|
What was Z24S8 before is actually S8Z24, and what we had for Z16
is actually X8Z24. Now, we also have the REAL Z24S8 and I added
Z32_FLOAT as well; most of the formats need different tile_flags.
|
|
|
|
|
|
|
|
|
|
The core reference counting code is centralized in p_refcnt.h.
This has some consequences related to struct pipe_buffer:
* The screen member of struct pipe_buffer must be initialized, or
pipe_buffer_reference() will crash trying to destroy a buffer with reference
count 0. u_simple_screen takes care of this, but I may have missed some of
the drivers not using it.
* Except for rare exceptions deep in winsys code, buffers must always be
allocated via pipe_buffer_create() or via screen->*buffer_create() rather
than via winsys->*buffer_create().
|
|
|
|
|
|
Don't look at nouveau_winsys_pipe.h... I promise it's temporary!
|
|
this change disassociates, at least from the driver perspective,
the surface from buffer. surfaces are technically now views on the
textures so make it so by hiding the buffer in the internals of
textures.
|
|
This commit is mostly just a cosmetic change that cleans-up the interfaces,
replacing pipe_winsys::surface_* calls by
/**
* Allocate storage for a display target surface.
*
* Often surfaces which are meant to be blitted to the front screen (i.e.,
* display targets) must be allocated with special characteristics, memory
* pools, or obtained directly from the windowing system.
*
* This callback is invoked by the pipe_screenwhen creating a texture marked
* with the PIPE_TEXTURE_USAGE_DISPLAY_TARGET flag to get the underlying
* buffer storage.
*/
struct pipe_buffer *(*surface_buffer_create)(struct pipe_winsys *ws,
unsigned width, unsigned height,
enum pipe_format format,
unsigned usage,
unsigned *stride);
Most drivers were updated but not all were tested. Use the softpipe pipe
driver and the xlib winsys changes as a reference when fixing other drivers.
|
|
|
|
|
|
|
|
|
|
|
|
Still a little dodgy:
- RTT will hit an assertion (hopefully!) and fail
- 3D textures with depth >= 32 will cause bad things to happen
|
|
|
|
|
|
I swear this didn't work last time I tried it.. Anyhow, still only
suitable for 2D miptrees - more coming once I know the layout.
|
|
|
|
|
|
progs/fp/tri-tex is all good now rather than all scrambled :)
|
|
|
|
OK, seems a lot of people have been getting the idea that nouveau is
dying lately - I decided to commit some of the work I've been doing lately
to prove them wrong :) Progress on my side is slow due to lack of time
mainly, but I'm still around.
Firstly, don't even bother trying to use gallium on G8x/G9x yet, it won't
work. I've deliberately left all the necessary winsys changes out of the
commits for a very good reason - I don't know what we're going to need from
the DRM exactly yet and don't want to be continually breaking interfaces
as I discover additional requirements. On my side, I think I've gone
through about 3 different DRM interface changes, and have just discovered
that I may need more yet. It'd be very annoying for everyone who uses
nouveau to keep things in sync. Once I've got it sorted - I'll commit a
lot of cool stuff. Stay tuned.
Also, don't look at the shader code.. it's horribly nasty and full of hacks,
I used it as an opportunity to learn G8x GPU programs at the same time.
New semi-decent code is in works, and will follow at some point. :)
|
|
|
|
|
|
|
|
NVIDIA love to make life difficult.. we need different flags in PTEs for
zeta.. yay.. not.
|
|
|
|
|
|
probably the last match-gallium-upstream merge for a bit, some cleanup+nv50
work coming RSN...
|
|
|
|
|
|
Untested on NV3x/NV5x. Quite possibly broken.
|
