Some compilers (like the Oracle Studio), require that the function
declaration must be annotated with the same visibility attribute as the
definition. As annotating functions with drm_public is no longer
required just remove the macro.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
After much searching and empricial testing, and reading of
things I've no justifcation for this fix, other than it really
appears this is what the hw is doing or close enough.
It makes sense that each entry in the FMASK corresponds to
an entry in the CMASKm and the CMASK is organised into 128x128
blocks, but I can't find anything in any of the docs/info from AMD.
But I've spent a lot of time on this, and this seems to be the
simplest fix, in that we don't over allocate things too much,
once this fix in place we can nuke the extra multiplier in mesa.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
slice_pt is tileb[0] / tile_split, which isn't directly related to the
pitch.
This caused pitch_bytes to be too large in some cases.
[0] Tile size in bytes
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
All the bof_* symbols are now no longer exported.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Some users report hitting a divide by 0 with the tile split in
certain apps. Tile_split shouldn't ever be 0 unless the surface
structure was not properly initialized. I think there may be some
cases where mesa uses an improperly initialized surface struct,
but I haven't had time to track it down.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=72425
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Bug fixes and simplification by Marek.
We have to use the tile index of 0 for non-MSAA depth-stencil after all.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This fixes VM protection faults.
I have a new piglit test which can iterate over all possible widths, heights,
and depths (including NPOT) and tests mipmapping with various texture targets.
After this is committed, I'll make a new release of libdrm and bump
the libdrm version requirement in Mesa.
v2: Only writte tile index if flags for it is set
v3: Remove useless allow2d scanout flags
v4: Split radeon_drm.h update to its own patch
v5: update against lastest next tree for radeon
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Very similar to Evergreen, but slightly different rules for tile / slice
alignment. Fortunately, these map quite naturally onto the previous fixes for
linear aligned layout on SI.
2D tiling still needs more work here and possibly in the kernel.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
This allows texturing with depth-stencil buffers directly without the copy
to CB. The separate miptree description for stencil is added, because
the stencil mipmap offsets are not really depth offsets/4 (at least
for the texture units).
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Another corner case that isn't well-explained yet.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
If we don't need stencil, don't allocate it.
If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
v2: actually do it correctly
Reviewed-by: Christian König <christian.koenig@amd.com>
On r6xx or evergreen z/stencil surface don't support linear or
linear aligned surface, force 1D tiled mode for those.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Certain cards report the the wrong bank setup which causes
surface init to fail in the ddx and leads to no accel.
If we hit an invalid tiling parameter, just set a default
value and disable 2D tiling.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=43448
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The mipmap level computation was wrong, we need to know the block
width, height, depth of compressed texture to properly compute this.
Change API to provide block width, height, depth instead of nblk_x,
nblk_y, nblk_z.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
The surface allocator is able to build complete miptree when allocating
surface for r600/r700/evergreen/northern islands GPU family. It also
compute bo size and alignment for render buffer, depth buffer and
scanout buffer.
v2 fix r6xx/r7xx 2D tiling width align computation
v3 add tile split support and fix 1d texture alignment
v4 rework to more properly support compressed format, split surface pixel
size and surface element size in separate fields
v5 support texture array (still issue on r6xx)
v6 split surface value computation and mipmap tree building, rework eg
and newer computation
v7 add a check for tile split and 2d tiled
v8 initialize mode value before testing it in all case, reenable
2D macro tile mode on r6xx for cubemap and array. Fix cubemap
to force array size to the number of face.
v9 fix handling of stencil buffer on evergreen
v10 on evergreen depth buffer need to have enough room for a stencil
buffer just after depth one
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Emil Velikov
Dave Airlie
Michel Dänzer
Maks Naumov
Maarten Lankhorst
Marek Olšák
Thomas Klausner
Samuel Li
Alex Deucher
Marek Olšák
Jerome Glisse