[Mesa-dev] [PATCH v2 5/5] i965/gen9: Allocate YF/YS tiled buffer objects
Anuj Phogat
anuj.phogat at gmail.com
Tue Jul 7 12:14:27 PDT 2015
On Tue, Jul 7, 2015 at 12:11 PM, Anuj Phogat <anuj.phogat at gmail.com> wrote:
> On Tue, Jul 7, 2015 at 2:35 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
>> On Tuesday, June 23, 2015 01:23:05 PM Anuj Phogat wrote:
>>> In case of I915_TILING_{X,Y} we need to pass tiling format to libdrm
>>> using drm_intel_bo_alloc_tiled(). But, In case of YF/YS tiled buffers
>>> libdrm need not know about the tiling format because these buffers
>>> don't have hardware support to be tiled or detiled through a fenced
>>> region. libdrm still need to know buffer alignment value for its use
>>> in kernel when resolving the relocation.
>>>
>>> Using drm_intel_bo_alloc_for_render() for YF/YS tiled buffers
>>> satisfy both the above conditions.
>>>
>>> V2: Delete min/max buffer size restrictions not valid for i965+.
>>> Remove redundant align to tile size statements.
>>> Remove some redundant code now when there are no min/max buffer size.
>>>
>>> Signed-off-by: Anuj Phogat <anuj.phogat at gmail.com>
>>> Cc: Ben Widawsky <ben at bwidawsk.net>
>>> ---
>>> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 62 +++++++++++++++++++++++++--
>>> 1 file changed, 58 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> index 80c52f2..5bcb094 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> @@ -558,6 +558,48 @@ intel_lower_compressed_format(struct brw_context *brw, mesa_format format)
>>> }
>>> }
>>>
>>> +/* This function computes Yf/Ys tiled bo size, alignment and pitch. */
>>> +static uint64_t
>>> +intel_get_yf_ys_bo_size(struct intel_mipmap_tree *mt, unsigned *alignment,
>>> + uint64_t *pitch)
>>
>> Hi Anuj,
>>
>> This patch has a subtle bug: you've specified pitch and stride to be
>> uint64_t here, but below when you call it....
>>
>> [snip]
>>> @@ -616,11 +658,23 @@ intel_miptree_create(struct brw_context *brw,
>>> alloc_flags |= BO_ALLOC_FOR_RENDER;
>>>
>>> unsigned long pitch;
>>> - mt->bo = drm_intel_bo_alloc_tiled(brw->bufmgr, "miptree", total_width,
>>> - total_height, mt->cpp, &mt->tiling,
>>> - &pitch, alloc_flags);
>>> mt->etc_format = etc_format;
>>> - mt->pitch = pitch;
>>> +
>>> + if (mt->tr_mode != INTEL_MIPTREE_TRMODE_NONE) {
>>> + unsigned alignment = 0;
>>> + unsigned long size;
>>> + size = intel_get_yf_ys_bo_size(mt, &alignment, &pitch);
>>
>> ...you're passing a pointer to an unsigned long. On 32-bit builds,
>> unsigned long is a 4 byte value, while uint64_t is 8 bytes. This could
>> lead to stack corruption. (GCC warns about this during a 32-bit build.)
>>
> Thanks for noticing this Ken. I think I never did 32 bit build with these
> patches :(.
>
>> I assumed the solution was to make everything uint32_t, but apparently
>> drm_intel_bo_alloc_tiled actually expects an unsigned long. So we can't
>> change that.
>>
> How about changing the parameter type of pitch to unsigned long*
> and types of size and stride to unsigned long? This fixes the 32 bit
> build warnings.
>
>> Then I looked at your code, and realized that nothing even uses the
>> pitch value. Is there some point to the parameter existing at all?
>>
> pitch value is later assigned to mt->pitch. I could have avoided
> passing &pitch parameter and instead assign mt->pitch in
> drm_intel_bo_alloc_for_render(). But, I used the current approach
Correction: assign mt->pitch in intel_get_yf_ys_bo_size()
> to keep mt->pitch assignments at a single place.
>
> I'm working on some refactoring to make this code look better.
>
>> --Ken
>>
>>> + assert(size);
>>> + mt->bo = drm_intel_bo_alloc_for_render(brw->bufmgr, "miptree",
>>> + size, alignment);
>>> + mt->pitch = pitch;
>>> + } else {
>>> + mt->bo = drm_intel_bo_alloc_tiled(brw->bufmgr, "miptree",
>>> + total_width, total_height, mt->cpp,
>>> + &mt->tiling, &pitch,
>>> + alloc_flags);
>>> + mt->pitch = pitch;
>>> + }
>>>
>>> /* If the BO is too large to fit in the aperture, we need to use the
>>> * BLT engine to support it. Prior to Sandybridge, the BLT paths can't
>>>
More information about the mesa-dev
mailing list