On Wed, Apr 03, 2013 at 06:11:26PM +0200, Michel Dänzer wrote: > On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: > > On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer <michel@xxxxxxxxxxx> > > wrote: > > On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote: > > > > > > Some might argue that we could just export the table content > > to > > > userspace, but that would loose information and possibly > > froze the > > > tile mode table forever as API. > > The current index scheme already is de facto part of the API. Only index 4,8,9,13 are part of current API no of the other are use. > > > The information we loose is what index > > > match to prefered surface format/type combination. > > How so? We can add descriptive names for the existing indices. Look at my kernel patch, for instance i define : RADEON_TILE_MODE_COLOR_2D_32BPP You can then query the kernel with RADEON_TILE_MODE_COLOR_2D_32BPP which gave you corresponding tile index and also correspond gb tile config. http://people.freedesktop.org/~glisse/si2d-sol1/0001-drm-radeon-add-tile-mode-ioctl.patch > > > And the tile mode > > > might be considered API as if kernel ever change what > > userspace expect > > > then we might break some userspace. > > Not sure how that could happen if the purpose of each index is clearly > defined. Well that's the question, are we happy, confident that we will never shuffle around the tile mode array. If so then we need to hard code tile index with a meaning and call it API. It's already the case for index 4,8,9,13 > > > > Maybe I'm missing the problem, but if libdrm_radeon were to > > get the > > tiling mode index chosen by radeonsi, and could retrieve the > > tiling > > parameters for each index from the kernel, it should be able > > to > > calculate things properly, shouldn't it? > > > > > > > > Let's not discuss about who/where the index is pick. No matter where > > it happens the question is do we want to hardcode tile index and make > > it api or do we want to hide it behind symbolic name allowing change > > in tile array (given that right now 4 value are already frozen). You > > can look at my kernel patch to see what i mean. > > The layer of indirection for the indices seems like overengineering at > this point. Even if the fixed indices stop being good enough for some > reason in the future, how can we be sure now the layer of indirection > will be good enough? So I think we shouldn't worry about that until that > day may come. > Well i am fine with that but i just want to make sure everybody understand the implications. Cheers, Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
