Hi Chris,
On 5/20/20 12:56 AM, Chris Wilson wrote:
Quoting Nirmoy Das (2020-05-19 09:44:36)
+#define DRM_MM_ALIGN_SHIFT 6
#define HOLE_SIZE(NODE) ((NODE)->hole_size)
#define HOLE_ADDR(NODE) (__drm_mm_hole_node_start(NODE))
+#define HOLE_SIZE_ALIGN(NODE) ((NODE->hole_size << DRM_MM_ALIGN_SHIFT) | \
+ ffs(HOLE_ADDR(NODE)))
Fwiw, max hole size of 58b, we would need to stop storing byte
extents...
Can you please explain 2nd part of this statement.
static struct drm_mm_node *
-next_hole_low_addr(struct drm_mm_node *entry, u64 size)
+next_hole_low_addr(struct drm_mm_node *entry, u64 size, u64 alignment)
{
struct rb_node *rb_node, *right_rb_node, *parent_rb_node;
struct drm_mm_node *right_node;
+ u64 req_align = (size + alignment) << DRM_MM_ALIGN_SHIFT;
if (!entry)
return NULL;
@@ -513,6 +561,7 @@ next_hole_low_addr(struct drm_mm_node *entry, u64 size)
right_node = rb_entry(right_rb_node,
struct drm_mm_node, rb_hole_addr);
if ((right_node->subtree_max_hole < size ||
+ right_node->subtree_max_hole_align < req_align ||
What was the point in storing the packed alignment if we are just
searching for a hole big enough for (size + alignment)?
Yes, I realized this is not correct :/
Still thinking about a better solution to capture alignment into subtree
elimination.
Regards,
Nirmoy
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cnirmoy.das%40amd.com%7C1b1ab9c2ca03412daa2108d7fc47d26e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255257724473951&sdata=gDRvdhwLV1M%2BKLCgpENik52gAB3O0ik1n%2B%2FaZxLgr%2Fk%3D&reserved=0
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel