[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On 11/19/2011 10:22 PM, Jerome Glisse wrote: > On Sat, Nov 19, 2011 at 4:01 PM, Thomas Hellstrom > wrote: > >> On 11/19/2011 09:37 PM, Jerome Glisse wrote: >> >>> On Sat, Nov 19, 2011 at 2:46 PM, Thomas Hellstrom >>> wrote: >>> >>> On 11/19/2011 07:11 PM, Jerome Glisse wrote: On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom wrote: On 11/19/2011 03:53 PM, Ben Skeggs wrote: On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: On 11/19/2011 01:26 AM, Ben Skeggs wrote: On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: On 11/18/2011 06:26 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: On 11/18/2011 02:15 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: Jerome, I don't like this change for the following reasons -snip- One can take advantage of move notify callback but, there are corner case where bind/unbind might be call without move notify being call (in error path mostly). So to make sure that each virtual address space have a consistent view of wether a buffer object is backed or not by system page it's better to pass the buffer object to bind/unbind. As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. This, I think, could easily be solved by swapping bo->mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. This can probably be solved easily enough too I expect. Ben. OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as "tell the driver the buffer is moving so it can do whatever is necessary as a result". Swapouts are a missed case though, indeed. A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On 11/19/2011 09:37 PM, Jerome Glisse wrote: > On Sat, Nov 19, 2011 at 2:46 PM, Thomas Hellstrom > wrote: > >> On 11/19/2011 07:11 PM, Jerome Glisse wrote: >> >> On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom >> wrote: >> >> >> On 11/19/2011 03:53 PM, Ben Skeggs wrote: >> >> >> On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: >> >> >> >> On 11/19/2011 01:26 AM, Ben Skeggs wrote: >> >> >> >> On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: >> >> >> >> >> On 11/18/2011 06:26 PM, Ben Skeggs wrote: >> >> >> >> >> On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: >> >> >> >> >> >> On 11/18/2011 02:15 PM, Ben Skeggs wrote: >> >> >> >> >> >> On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: >> >> >> >> >> >> >> Jerome, >> >> I don't like this change for the following reasons >> >> >> >> >> >> >> -snip- >> >> >> >> >> >> >> >> One can take advantage of move notify callback but, there are >> corner case where bind/unbind might be call without move notify >> being call (in error path mostly). So to make sure that each >> virtual address space have a consistent view of wether a buffer >> object is backed or not by system page it's better to pass the >> buffer object to bind/unbind. >> >> >> >> >> >> >> As I discussed previously with Jerome on IRC, I believe the >> move_notify >> hook is sufficient. I fixed a couple of issues back with it back >> when I >> implemented support for this in nouveau. >> >> Jerome did point out two issues however, which I believe can be >> solved >> easily enough. >> >> The first was that the error path after move_notify() has been >> called >> doesn't reverse the move_notify() too, leaving incorrect page table >> entries. This, I think, could easily be solved by swapping bo->mem >> and >> mem, and re-calling move_notify() to have the driver reverse >> whatever it >> did. >> >> The second issue is that apparently move_notify() doesn't get called >> in >> the destroy path. Nouveau's GEM layer takes care of this for our >> userspace bos, and we don't use any kernel bos that are mapped into >> a >> channel's address space so we don't hit it. This can probably be >> solved >> easily enough too I expect. >> >> Ben. >> >> >> >> >> >> >> >> OK. I understand. Surely if a move_notify is missing somewhere, that >> can >> easily be fixed. >> >> It might be good if we can outline how the virtual tables are set up. >> In >> my world, the following would happen: >> >> 1) Pre command submission: >> >> a) reserve bo >> b) call ttm_bo_validate to set placement. move_notify will tear down >> any >> existing GPU page tables for the bo. >> c) Set up GPU page tables. >> >> >> >> >> >> Nouveau doesn't do this exactly. I wanted to avoid having to check if >> a >> bo was bound to a particular address space on every command >> submission. >> >> >> >> >> >> It perhaps might be a good idea to revisit this? >> I think using move_notify to set up a new placement before the data has >> actually been moved is very fragile and not the intended use. That >> would >> also save you from having to handle error paths. Also how do you handle >> swapouts? >> >> >> >> >> I don't see how it's fragile, there's only the one error path after that >> point that needs to undo it. And, what *is* the expected use then? I >> see it as "tell the driver the buffer is moving so it can do whatever is >> necessary as a result". >> >> Swapouts are a missed case though, indeed. >> >> >> >> >> >> A quick check in c) that the virtual map hasn't been torn down by a >> move_notify and, in that case, rebuild it would probably be next to >> free. The virtual GPU mapping would then be valid only after validation >> and while the bo is fenced or pinned. >> >> >> >> >> This alone doesn't solve the swapouts issue either unless you're also >> wanting us to unmap once a buffer becomes unfenced, which would lead to >> loads of completely unnecessary map/unmaps. >> >> Ben. >> >> >> >> >> I think you misunderstand me a little. >> The swapout issue should be handled by calling a move_notify() to kill >> the virtual GPU mappings. >> >> However, when moving data that has page tables pointing to it, one >> should (IMHO) do: >> >> 1) Kill the old page tables >> 2) Move the object >> 3) Set up new page tables on demand. >> >> This is done by TTM for CPU page tables and I think that should be done >> also for GPU page tables. move_notify() should be responsible for 1), >> The driver execbuf for 3), and 3) needs only to be done for the >> particular ring / fifo which is executing commands that touch the buffer. >> >> This leaves a clear and well-defined requirement on TTM: >> Notify the driver when it needs to kill its GPU page tables. >> >> >> >> Ok. This I don't really object to really. I read the previous mail as >> that GPU mappings should only exist as long as the buffer is fenced, >> which would be a ridiculous amount of overhead. >> >> >> >> I agree. What I meant was that the page tables wouldn't be
[PATCH] drm/radeon/kms: add a CS ioctl flag not to rewrite tiling flags in the CS
Ping. Will anyone pick up this patch, please?
Marek
On Tue, Oct 25, 2011 at 1:38 AM, Marek Ol??k wrote:
> This adds a new optional chunk to the CS ioctl that specifies optional flags
> to the CS parser. Why this is useful is explained below. Note that some regs
> no longer need the NOP relocation packet if this feature is enabled.
> Tested on r300g and r600g with this flag disabled and enabled.
>
> Assume there are two contexts sharing the same mipmapped tiled texture.
> One context wants to render into the first mipmap and the other one
> wants to render into the last mipmap. As you probably know, the hardware
> has a MACRO_SWITCH feature, which turns off macro tiling for small mipmaps,
> but that only applies to samplers.
> (at least on r300-r500, though later hardware likely behaves the same)
>
> So we want to just re-set the tiling flags before rendering (writing
> packets), right? ... No. The contexts run in parallel, so they may
> set the tiling flags simultaneously and then fire their command streams
> also simultaneously. The last one setting the flags wins, the other one
> loses.
>
> Another problem is when one context wants to render into the first and
> the last mipmap in one CS. Impossible. It must flush before changing
> tiling flags and do the rendering into the smaller mipmaps in another CS.
>
> Yet another problem is that writing copy_blit in userspace would be a mess
> involving re-setting tiling flags to please the kernel, and causing races
> with other contexts at the same time.
>
> The only way out of this is to send tiling flags with each CS, ideally
> with each relocation. But we already do that through the registers.
> So let's just use what we have in the registers.
>
> Signed-off-by: Marek Ol??k
> ---
> ?drivers/gpu/drm/radeon/evergreen_cs.c | ? 92 +---
> ?drivers/gpu/drm/radeon/r300.c ? ? ? ? | ? 94
> ++---
> ?drivers/gpu/drm/radeon/r600_cs.c ? ? ?| ? 26 ++
> ?drivers/gpu/drm/radeon/radeon.h ? ? ? | ? ?3 +-
> ?drivers/gpu/drm/radeon/radeon_cs.c ? ?| ? 11 -
> ?drivers/gpu/drm/radeon/radeon_drv.c ? | ? ?3 +-
> ?include/drm/radeon_drm.h ? ? ? ? ? ? ?| ? ?4 ++
> ?7 files changed, 135 insertions(+), 98 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index a134790..86b060c 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -508,21 +508,23 @@ static inline int evergreen_cs_check_reg(struct
> radeon_cs_parser *p, u32 reg, u3
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case DB_Z_INFO:
> - ? ? ? ? ? ? ? r = evergreen_cs_packet_next_reloc(p, );
> - ? ? ? ? ? ? ? if (r) {
> - ? ? ? ? ? ? ? ? ? ? ? dev_warn(p->dev, "bad SET_CONTEXT_REG "
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "0x%04X\n", reg);
> - ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
> - ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ?track->db_z_info = radeon_get_ib_value(p, idx);
> - ? ? ? ? ? ? ? ib[idx] &= ~Z_ARRAY_MODE(0xf);
> - ? ? ? ? ? ? ? track->db_z_info &= ~Z_ARRAY_MODE(0xf);
> - ? ? ? ? ? ? ? if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
> - ? ? ? ? ? ? ? ? ? ? ? ib[idx] |= Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
> - ? ? ? ? ? ? ? ? ? ? ? track->db_z_info |=
> Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
> - ? ? ? ? ? ? ? } else {
> - ? ? ? ? ? ? ? ? ? ? ? ib[idx] |= Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
> - ? ? ? ? ? ? ? ? ? ? ? track->db_z_info |=
> Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
> + ? ? ? ? ? ? ? if (!p->keep_tiling_flags) {
> + ? ? ? ? ? ? ? ? ? ? ? r = evergreen_cs_packet_next_reloc(p, );
> + ? ? ? ? ? ? ? ? ? ? ? if (r) {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dev_warn(p->dev, "bad SET_CONTEXT_REG "
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "0x%04X\n", reg);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
> + ? ? ? ? ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? ? ? ? ? ib[idx] &= ~Z_ARRAY_MODE(0xf);
> + ? ? ? ? ? ? ? ? ? ? ? track->db_z_info &= ~Z_ARRAY_MODE(0xf);
> + ? ? ? ? ? ? ? ? ? ? ? if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ib[idx] |= Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? track->db_z_info |=
> Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
> + ? ? ? ? ? ? ? ? ? ? ? } else {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ib[idx] |= Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? track->db_z_info |=
> Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
> + ? ? ? ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case DB_STENCIL_INFO:
> @@ -635,40 +637,44 @@ static inline int evergreen_cs_check_reg(struct
> radeon_cs_parser *p, u32 reg, u3
> ? ? ? ?case CB_COLOR5_INFO:
> ? ? ? ?case CB_COLOR6_INFO:
> ? ? ? ?case CB_COLOR7_INFO:
> - ? ? ? ? ? ? ? r = evergreen_cs_packet_next_reloc(p, );
> - ? ? ? ? ? ? ? if (r) {
> - ? ? ? ? ? ? ? ? ? ? ? dev_warn(p->dev, "bad SET_CONTEXT_REG "
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "0x%04X\n", reg);
> - ? ? ? ? ? ? ? ? ? ? ?
[PATCH] drm/ttm: callback move_notify any time bo placement change v3
On 11/19/2011 12:32 AM, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Previously we were calling back move_notify in error path when the
> bo is returned to it's original position or when destroy the bo.
> When destroying the bo set the new mem placement as NULL when calling
> back in the driver.
>
> Updating nouveau to deal with NULL placement properly.
>
> v2: reserve the object before calling move_notify in bo destroy path
> at that point ttm should be the only piece of code interacting
> with the object so atomic_set is safe here.
> v3: callback move notify only once the bo is in its new position
> call move notify want swaping out the buffer
>
> Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c |4 ++--
> drivers/gpu/drm/ttm/ttm_bo.c | 17 +
> 2 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 857bca4..f12dd0f 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -815,10 +815,10 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo,
> struct ttm_mem_reg *new_mem)
> struct nouveau_vma *vma;
>
> list_for_each_entry(vma,>vma_list, head) {
> - if (new_mem->mem_type == TTM_PL_VRAM) {
> + if (new_mem&& new_mem->mem_type == TTM_PL_VRAM) {
> nouveau_vm_map(vma, new_mem->mm_node);
> } else
> - if (new_mem->mem_type == TTM_PL_TT&&
> + if (new_mem&& new_mem->mem_type == TTM_PL_TT&&
> nvbo->page_shift == vma->vm->spg_shift) {
> nouveau_vm_map_sg(vma, 0, new_mem->
> num_pages<< PAGE_SHIFT,
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index de7ad99..0c1d821 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -147,6 +147,12 @@ static void ttm_bo_release_list(struct kref *list_kref)
> BUG_ON(!list_empty(>lru));
> BUG_ON(!list_empty(>ddestroy));
>
> + /* force bo to reserved, at this point we should be the only owner */
> + atomic_set(>reserved, 1);
> + if (bdev->driver->move_notify)
> + bdev->driver->move_notify(bo, NULL);
> + atomic_set(>reserved, 0);
>
We can actually do this from the top of ttm_bo_cleanup_memtype_use().
Then we should catch all current and future use-cases and you wouldn't
need the fake reserving, because at that point, we're already reserved.
> +
> if (bo->ttm)
> ttm_tt_destroy(bo->ttm);
> atomic_dec(>glob->bo_count);
> @@ -404,9 +410,6 @@ static int ttm_bo_handle_move_mem(struct
> ttm_buffer_object *bo,
> }
> }
>
> - if (bdev->driver->move_notify)
> - bdev->driver->move_notify(bo, mem);
> -
> if (!(old_man->flags& TTM_MEMTYPE_FLAG_FIXED)&&
> !(new_man->flags& TTM_MEMTYPE_FLAG_FIXED))
> ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve, no_wait_gpu,
> mem);
> @@ -419,6 +422,9 @@ static int ttm_bo_handle_move_mem(struct
> ttm_buffer_object *bo,
> if (ret)
> goto out_err;
>
> + if (bdev->driver->move_notify)
> + bdev->driver->move_notify(bo, mem);
> +
>
> moved:
> if (bo->evicted) {
> ret = bdev->driver->invalidate_caches(bdev, bo->mem.placement);
> @@ -1872,9 +1878,12 @@ static int ttm_bo_swapout(struct ttm_mem_shrink
> *shrink)
> if (bo->bdev->driver->swap_notify)
> bo->bdev->driver->swap_notify(bo);
>
> + if (bo->bdev->driver->move_notify)
> + bo->bdev->driver->move_notify(bo, NULL);
> +
>
Hmm. On second thought, we could use swap_notify() for this, I missed we
already had that and that's what vmwgfx once used for exactly the same
purpose.
> ret = ttm_tt_swapout(bo->ttm, bo->persistent_swap_storage);
> -out:
>
> +out:
>
Whitespace.
/Thomas
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 Tom Stellard changed: What|Removed |Added Attachment #53692|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43096] New: r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096
Bug #: 43096
Summary: r300g: r300_emit_draw_elements() refusing to render
when max_index = 0x
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: tstellar at gmail.com
Created attachment 53692
--> https://bugs.freedesktop.org/attachment.cgi?id=53692
Callstack from error message
I'm not exactly sure if this is a bug in r300g or st/mesa, but none of the
leader portraits are rendered in Civ4 and this error message is being printed:
r300: Got a huge number of vertices: 310, refusing to render (max_index: -1).
The reason this error message is being printed is because max_index is
0x, so this if statement at r300_render.c:448 evaluates to true:
if (count >= (1 << 24) || max_index >= (1 << 24)) {
fprintf(stderr, "r300: Got a huge number of vertices: %i, "
"refusing to render (max_index: %i).\n", count, max_index);
return;
}
I'm not sure if the state tracker is wrong for passing 0x as the
max_index or if the driver needs to handle a max_index of 0x as a
special case, because it is the default value for pipe_draw_info->max_index. I
have captured the call stack when this error message is printed and attached it
to this bug report.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
ext move_notify(). The intention was >> never to tear down the mappings once the fence had signaled; that would have >> been pretty stupid. >> >> >>> >>>> With the latest patch from jerome: >>>> Notify the driver when it needs to rebuild it page tables. Also on error >>>> paths, but not for swapins because no driver will probably set up GPU >>>> page tables to SYSTEM_MEMORY. >>>> >>>> This is what I mean with fragile, and I much rather see the other >>>> approach. >>>> >>>> Ben, I didn't fully understand why you didn't want to use that approach. >>>> Did you see a significant overhead with it. >>>> >>>> >>> Now I'm more clear on what you meant, no, it wouldn't be a lot of >>> overhead. However, move_notify() was never intended for the use you're >>> proposing now, or the new ttm_mem_reg would never have been being passed >>> in as a parameter... >>> >>> >> I suppose you're right. Still I think this is the right way to go. Since it >> has the following advantages: >> >> 1) TTM doesn't need to care about the driver re-populating its GPU page >> tables. >> Since swapin is handled from the tt layer not the bo layer, this makes it a >> bit easier on us. >> 2) Transition to page-faulted GPU virtual maps is straightforward and >> consistent. A non-page-faulting driver sets up the maps at CS time, A >> pagefaulting driver can set them up directly from an irq handler without >> reserving, since the bo is properly fenced or pinned when the pagefault >> happens. >> 3) A non-page-faulting driver knows at CS time exactly which >> page-table-entries really do need populating, and can do this more >> efficiently. >> >> So unless there are strong objections I suggest we should go this way. >> >> Even if this changes the semantics of the TTM<-> driver interface compared >> to how Nouveau currently does things, it means that Jerome's current patch >> is basically correct and doesn't any longer have any assumptions about >> SYSTEM memory never being used for virtual GPU maps. >> >> Thanks, >> Thomas. >> > I think it's better to let driver choose how it will handle its > virtual page table. For radeon i update in move_notify in order to > minimize the number of update. I don't want to track if an object have > been updated or not against each page table. Of course this add > possibly useless overhead to move notify as we might update page table > to many time (bo from vram->gtt->system) > > I think if move notify is properly call once for each effective move > driver can do their own dance behind curtain. > > Cheers, > Jerome > Jerome, It's not really what the driver does that is the problem, it's what the driver expects from the driver <-> TTM interface. That's why I'd really like a maintainable interface design before coding patches that makes the interface a set of various workarounds. Enforcing this will also force driver writers to think twice before implementing things in their own way adding another load of ad hoc callbacks to TTM, without a clear specification but with the only purpose to fit a specific driver implementation, so in a way it's our responsibility to future driver writers to try to agree on a simple interface that works well and allows drivers to do an efficient implementation, and that adds a little maintenance burden on TTM. If a future driver writer looks at the Radeon code and replicates it, because he thinks it's state of the art, and then finds out his code breaks because he can't use SYSTEM memory for GPU page tables, or use his own private LRU, or the code breaks with partially populated TTMs and finally finds it's quite inefficient too because it unnecessarily populates page tables, we've failed. This is really the point I'd like to make, but as a side note, I'm not asking you to track each bo against each page table. What I'm asking you is to not populate the page tables in bo_move() but in execbuf / pushbuf. The possibility to track a bo against each page table comes as a nice benefit. /Thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2019/8c344202/attachment.html>
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On 11/19/2011 03:53 PM, Ben Skeggs wrote: > On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: > >> On 11/19/2011 01:26 AM, Ben Skeggs wrote: >> >>> On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: >>> >>> On 11/18/2011 06:26 PM, Ben Skeggs wrote: > On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: > > > >> On 11/18/2011 02:15 PM, Ben Skeggs wrote: >> >> >> >>> On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: >>> >>> >>> >>> Jerome, I don't like this change for the following reasons >>> -snip- >>> >>> >>> >>> >>> > One can take advantage of move notify callback but, there are > corner case where bind/unbind might be call without move notify > being call (in error path mostly). So to make sure that each > virtual address space have a consistent view of wether a buffer > object is backed or not by system page it's better to pass the > buffer object to bind/unbind. > > > > >>> As I discussed previously with Jerome on IRC, I believe the move_notify >>> hook is sufficient. I fixed a couple of issues back with it back when I >>> implemented support for this in nouveau. >>> >>> Jerome did point out two issues however, which I believe can be solved >>> easily enough. >>> >>> The first was that the error path after move_notify() has been called >>> doesn't reverse the move_notify() too, leaving incorrect page table >>> entries. This, I think, could easily be solved by swapping bo->mem and >>> mem, and re-calling move_notify() to have the driver reverse whatever it >>> did. >>> >>> The second issue is that apparently move_notify() doesn't get called in >>> the destroy path. Nouveau's GEM layer takes care of this for our >>> userspace bos, and we don't use any kernel bos that are mapped into a >>> channel's address space so we don't hit it. This can probably be solved >>> easily enough too I expect. >>> >>> Ben. >>> >>> >>> >>> >>> >> OK. I understand. Surely if a move_notify is missing somewhere, that can >> easily be fixed. >> >> It might be good if we can outline how the virtual tables are set up. In >> my world, the following would happen: >> >> 1) Pre command submission: >> >> a) reserve bo >> b) call ttm_bo_validate to set placement. move_notify will tear down any >> existing GPU page tables for the bo. >> c) Set up GPU page tables. >> >> >> > Nouveau doesn't do this exactly. I wanted to avoid having to check if a > bo was bound to a particular address space on every command submission. > > > It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? >>> I don't see how it's fragile, there's only the one error path after that >>> point that needs to undo it. And, what *is* the expected use then? I >>> see it as "tell the driver the buffer is moving so it can do whatever is >>> necessary as a result". >>> >>> Swapouts are a missed case though, indeed. >>> >>> >>> A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. >>> This alone doesn't solve the swapouts issue either unless you're also >>> wanting us to unmap once a buffer becomes unfenced, which would lead to >>> loads of completely unnecessary map/unmaps. >>> >>> Ben. >>> >>> >> I think you misunderstand me a little. >> The swapout issue should be handled by calling a move_notify() to kill >> the virtual GPU mappings. >> >> However, when moving data that has page tables pointing to it, one >> should (IMHO) do: >> >> 1) Kill the old page tables >> 2) Move the object >> 3) Set up new page tables on demand. >> >> This is done by TTM for CPU page tables and I think that should be done >> also for GPU page tables. move_notify() should be responsible for 1), >> The driver execbuf for 3), and 3) needs only to be done for the >> particular ring / fifo which is executing commands that touch the buffer. >> >> This leaves a clear and well-defined requirement on TTM: >> Notify the driver when it needs to kill its GPU page tables. >> > Ok. This I
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sat, Nov 19, 2011 at 5:37 PM, Thomas Hellstrom wrote: > On 11/19/2011 10:22 PM, Jerome Glisse wrote: >> >> On Sat, Nov 19, 2011 at 4:01 PM, Thomas Hellstrom >> ?wrote: >> >>> >>> On 11/19/2011 09:37 PM, Jerome Glisse wrote: >>> On Sat, Nov 19, 2011 at 2:46 PM, Thomas Hellstrom ?wrote: > > On 11/19/2011 07:11 PM, Jerome Glisse wrote: > > On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom > ? ?wrote: > > > On 11/19/2011 03:53 PM, Ben Skeggs wrote: > > > On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: > > > > On 11/19/2011 01:26 AM, Ben Skeggs wrote: > > > > On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: > > > > > On 11/18/2011 06:26 PM, Ben Skeggs wrote: > > > > > On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: > > > > > > On 11/18/2011 02:15 PM, Ben Skeggs wrote: > > > > > > On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: > > > > > > > Jerome, > > I don't like this change for the following reasons > > > > > > > -snip- > > > > > > > > One can take advantage of move notify callback but, there are > corner case where bind/unbind might be call without move notify > being call (in error path mostly). So to make sure that each > virtual address space have a consistent view of wether a buffer > object is backed or not by system page it's better to pass the > buffer object to bind/unbind. > > > > > > > As I discussed previously with Jerome on IRC, I believe the > move_notify > hook is sufficient. ?I fixed a couple of issues back with it back > when I > implemented support for this in nouveau. > > Jerome did point out two issues however, which I believe can be > solved > easily enough. > > The first was that the error path after move_notify() has been > called > doesn't reverse the move_notify() too, leaving incorrect page table > entries. ?This, I think, could easily be solved by swapping bo->mem > and > mem, and re-calling move_notify() to have the driver reverse > whatever it > did. > > The second issue is that apparently move_notify() doesn't get called > in > the destroy path. ?Nouveau's GEM layer takes care of this for our > userspace bos, and we don't use any kernel bos that are mapped into > a > channel's address space so we don't hit it. ?This can probably be > solved > easily enough too I expect. > > Ben. > > > > > > > > OK. I understand. Surely if a move_notify is missing somewhere, that > can > easily be fixed. > > It might be good if we can outline how the virtual tables are set up. > In > my world, the following would happen: > > 1) Pre command submission: > > a) reserve bo > b) call ttm_bo_validate to set placement. move_notify will tear down > any > existing GPU page tables for the bo. > c) Set up GPU page tables. > > > > > > Nouveau doesn't do this exactly. ?I wanted to avoid having to check if > a > bo was bound to a particular address space on every command > submission. > > > > > > It perhaps might be a good idea to revisit this? > I think using move_notify to set up a new placement before the data has > actually been moved is very fragile and not the intended use. That > would > also save you from having to handle error paths. Also how do you handle > swapouts? > > > > > I don't see how it's fragile, there's only the one error path after > that > point that needs to undo it. ?And, what *is* the expected use then? ?I > see it as "tell the driver the buffer is moving so it can do whatever > is > necessary as a result". > > Swapouts are a missed case though, indeed. > > > > > > A quick check in c) that the virtual map hasn't been torn down by a > move_notify and, in that case, rebuild it would probably be next to > free. The virtual GPU mapping would then be valid only after validation > and while the bo is fenced or pinned. > > > > > This alone doesn't solve the swapouts issue either unless you're also > wanting us to unmap once a buffer becomes unfenced, which would lead to > loads of completely unnecessary map/unmaps. > > Ben. > > > > > I think you misunderstand me a little. > The swapout issue should be handled by calling a move_notify() to kill > the virtual GPU mappings. > > However, when moving data that has page tables pointing to it, one > should (IMHO) do: > > 1) Kill the
[Bug 34626] Mesa-Gallium with R600 - Framerate limited to 60 fps after suspend-cycle
https://bugs.freedesktop.org/show_bug.cgi?id=34626 --- Comment #9 from Peter Weber 2011-11-19 09:40:14 PST --- I've tested this in the meantime also with a Intel based grapcis solution (Ironlake), it is not affected. But the Intel driver doesn't need the var vblank_mode for switching vsync off (only SwapbuffersWait). Maybe the setting of the var gets "lost" during suspend cycle? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sat, Nov 19, 2011 at 4:01 PM, Thomas Hellstrom wrote: > On 11/19/2011 09:37 PM, Jerome Glisse wrote: >> >> On Sat, Nov 19, 2011 at 2:46 PM, Thomas Hellstrom >> ?wrote: >> >>> >>> On 11/19/2011 07:11 PM, Jerome Glisse wrote: >>> >>> On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom >>> ?wrote: >>> >>> >>> On 11/19/2011 03:53 PM, Ben Skeggs wrote: >>> >>> >>> On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: >>> >>> >>> >>> On 11/19/2011 01:26 AM, Ben Skeggs wrote: >>> >>> >>> >>> On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: >>> >>> >>> >>> >>> On 11/18/2011 06:26 PM, Ben Skeggs wrote: >>> >>> >>> >>> >>> On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: >>> >>> >>> >>> >>> >>> On 11/18/2011 02:15 PM, Ben Skeggs wrote: >>> >>> >>> >>> >>> >>> On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: >>> >>> >>> >>> >>> >>> >>> Jerome, >>> >>> I don't like this change for the following reasons >>> >>> >>> >>> >>> >>> >>> -snip- >>> >>> >>> >>> >>> >>> >>> >>> One can take advantage of move notify callback but, there are >>> corner case where bind/unbind might be call without move notify >>> being call (in error path mostly). So to make sure that each >>> virtual address space have a consistent view of wether a buffer >>> object is backed or not by system page it's better to pass the >>> buffer object to bind/unbind. >>> >>> >>> >>> >>> >>> >>> As I discussed previously with Jerome on IRC, I believe the >>> move_notify >>> hook is sufficient. ?I fixed a couple of issues back with it back >>> when I >>> implemented support for this in nouveau. >>> >>> Jerome did point out two issues however, which I believe can be >>> solved >>> easily enough. >>> >>> The first was that the error path after move_notify() has been >>> called >>> doesn't reverse the move_notify() too, leaving incorrect page table >>> entries. ?This, I think, could easily be solved by swapping bo->mem >>> and >>> mem, and re-calling move_notify() to have the driver reverse >>> whatever it >>> did. >>> >>> The second issue is that apparently move_notify() doesn't get called >>> in >>> the destroy path. ?Nouveau's GEM layer takes care of this for our >>> userspace bos, and we don't use any kernel bos that are mapped into >>> a >>> channel's address space so we don't hit it. ?This can probably be >>> solved >>> easily enough too I expect. >>> >>> Ben. >>> >>> >>> >>> >>> >>> >>> >>> OK. I understand. Surely if a move_notify is missing somewhere, that >>> can >>> easily be fixed. >>> >>> It might be good if we can outline how the virtual tables are set up. >>> In >>> my world, the following would happen: >>> >>> 1) Pre command submission: >>> >>> a) reserve bo >>> b) call ttm_bo_validate to set placement. move_notify will tear down >>> any >>> existing GPU page tables for the bo. >>> c) Set up GPU page tables. >>> >>> >>> >>> >>> >>> Nouveau doesn't do this exactly. ?I wanted to avoid having to check if >>> a >>> bo was bound to a particular address space on every command >>> submission. >>> >>> >>> >>> >>> >>> It perhaps might be a good idea to revisit this? >>> I think using move_notify to set up a new placement before the data has >>> actually been moved is very fragile and not the intended use. That >>> would >>> also save you from having to handle error paths. Also how do you handle >>> swapouts? >>> >>> >>> >>> >>> I don't see how it's fragile, there's only the one error path after that >>> point that needs to undo it. ?And, what *is* the expected use then? ?I >>> see it as "tell the driver the buffer is moving so it can do whatever is >>> necessary as a result". >>> >>> Swapouts are a missed case though, indeed. >>> >>> >>> >>> >>> >>> A quick check in c) that the virtual map hasn't been torn down by a >>> move_notify and, in that case, rebuild it would probably be next to >>> free. The virtual GPU mapping would then be valid only after validation >>> and while the bo is fenced or pinned. >>> >>> >>> >>> >>> This alone doesn't solve the swapouts issue either unless you're also >>> wanting us to unmap once a buffer becomes unfenced, which would lead to >>> loads of completely unnecessary map/unmaps. >>> >>> Ben. >>> >>> >>> >>> >>> I think you misunderstand me a little. >>> The swapout issue should be handled by calling a move_notify() to kill >>> the virtual GPU mappings. >>> >>> However, when moving data that has page tables pointing to it, one >>> should (IMHO) do: >>> >>> 1) Kill the old page tables >>> 2) Move the object >>> 3) Set up new page tables on demand. >>> >>> This is done by TTM for CPU page tables and I think that should be done >>> also for GPU page tables. move_notify() should be responsible for 1), >>> The driver execbuf for 3), and 3) needs only to be done for the >>> particular ring / fifo which is executing commands that touch the buffer. >>> >>> This leaves a clear and well-defined requirement on TTM: >>> Notify the driver when it needs to kill its GPU page tables. >>> >>> >>> >>>
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sat, Nov 19, 2011 at 2:46 PM, Thomas Hellstrom wrote: > On 11/19/2011 07:11 PM, Jerome Glisse wrote: > > On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom > wrote: > > > On 11/19/2011 03:53 PM, Ben Skeggs wrote: > > > On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: > > > > On 11/19/2011 01:26 AM, Ben Skeggs wrote: > > > > On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: > > > > > On 11/18/2011 06:26 PM, Ben Skeggs wrote: > > > > > On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: > > > > > > On 11/18/2011 02:15 PM, Ben Skeggs wrote: > > > > > > On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: > > > > > > > Jerome, > > I don't like this change for the following reasons > > > > > > > -snip- > > > > > > > > One can take advantage of move notify callback but, there are > corner case where bind/unbind might be call without move notify > being call (in error path mostly). So to make sure that each > virtual address space have a consistent view of wether a buffer > object is backed or not by system page it's better to pass the > buffer object to bind/unbind. > > > > > > > As I discussed previously with Jerome on IRC, I believe the > move_notify > hook is sufficient. ?I fixed a couple of issues back with it back > when I > implemented support for this in nouveau. > > Jerome did point out two issues however, which I believe can be > solved > easily enough. > > The first was that the error path after move_notify() has been > called > doesn't reverse the move_notify() too, leaving incorrect page table > entries. ?This, I think, could easily be solved by swapping bo->mem > and > mem, and re-calling move_notify() to have the driver reverse > whatever it > did. > > The second issue is that apparently move_notify() doesn't get called > in > the destroy path. ?Nouveau's GEM layer takes care of this for our > userspace bos, and we don't use any kernel bos that are mapped into > a > channel's address space so we don't hit it. ?This can probably be > solved > easily enough too I expect. > > Ben. > > > > > > > > OK. I understand. Surely if a move_notify is missing somewhere, that > can > easily be fixed. > > It might be good if we can outline how the virtual tables are set up. > In > my world, the following would happen: > > 1) Pre command submission: > > a) reserve bo > b) call ttm_bo_validate to set placement. move_notify will tear down > any > existing GPU page tables for the bo. > c) Set up GPU page tables. > > > > > > Nouveau doesn't do this exactly. ?I wanted to avoid having to check if > a > bo was bound to a particular address space on every command > submission. > > > > > > It perhaps might be a good idea to revisit this? > I think using move_notify to set up a new placement before the data has > actually been moved is very fragile and not the intended use. That > would > also save you from having to handle error paths. Also how do you handle > swapouts? > > > > > I don't see how it's fragile, there's only the one error path after that > point that needs to undo it. ?And, what *is* the expected use then? ?I > see it as "tell the driver the buffer is moving so it can do whatever is > necessary as a result". > > Swapouts are a missed case though, indeed. > > > > > > A quick check in c) that the virtual map hasn't been torn down by a > move_notify and, in that case, rebuild it would probably be next to > free. The virtual GPU mapping would then be valid only after validation > and while the bo is fenced or pinned. > > > > > This alone doesn't solve the swapouts issue either unless you're also > wanting us to unmap once a buffer becomes unfenced, which would lead to > loads of completely unnecessary map/unmaps. > > Ben. > > > > > I think you misunderstand me a little. > The swapout issue should be handled by calling a move_notify() to kill > the virtual GPU mappings. > > However, when moving data that has page tables pointing to it, one > should (IMHO) do: > > 1) Kill the old page tables > 2) Move the object > 3) Set up new page tables on demand. > > This is done by TTM for CPU page tables and I think that should be done > also for GPU page tables. move_notify() should be responsible for 1), > The driver execbuf for 3), and 3) needs only to be done for the > particular ring / fifo which is executing commands that touch the buffer. > > This leaves a clear and well-defined requirement on TTM: > Notify the driver when it needs to kill its GPU page tables. > > > > Ok. ?This I don't really object to really. ?I read the previous mail as > that GPU mappings should only exist as long as the buffer is fenced, > which would be a ridiculous amount of overhead. > > > > I agree. What I meant was that the page tables wouldn't be considered valid > when the fence had signaled. However that was actually incorrect because > they would actually be valid until the next move_notify(). The intention was > never to tear down the mappings once the fence had signaled; that would have > been pretty
[PATCH] drm: Fix missed parenthesis
This adds a missed parenthesis in drm_mode.h header file.
Signed-off-by: Joonyoung Shim
---
include/drm/drm_mode.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 094da8a..27d7faf 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -266,7 +266,7 @@ struct drm_mode_fb_cmd {
__u32 handle;
};
-#define DRM_MODE_FB_INTERLACED (1<<0 /* for interlaced framebuffers */
+#define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */
struct drm_mode_fb_cmd2 {
__u32 fb_id;
--
1.7.5.4
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom wrote: > On 11/19/2011 03:53 PM, Ben Skeggs wrote: >> >> On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: >> >>> >>> On 11/19/2011 01:26 AM, Ben Skeggs wrote: >>> On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: > > On 11/18/2011 06:26 PM, Ben Skeggs wrote: > > >> >> On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: >> >> >> >>> >>> On 11/18/2011 02:15 PM, Ben Skeggs wrote: >>> >>> >>> On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: > > Jerome, > > I don't like this change for the following reasons > > > > -snip- >> >> One can take advantage of move notify callback but, there are >> corner case where bind/unbind might be call without move notify >> being call (in error path mostly). So to make sure that each >> virtual address space have a consistent view of wether a buffer >> object is backed or not by system page it's better to pass the >> buffer object to bind/unbind. >> >> >> >> As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. ?I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. ?This, I think, could easily be solved by swapping bo->mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. ?Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. ?This can probably be solved easily enough too I expect. Ben. >>> >>> OK. I understand. Surely if a move_notify is missing somewhere, that >>> can >>> easily be fixed. >>> >>> It might be good if we can outline how the virtual tables are set up. >>> In >>> my world, the following would happen: >>> >>> 1) Pre command submission: >>> >>> a) reserve bo >>> b) call ttm_bo_validate to set placement. move_notify will tear down >>> any >>> existing GPU page tables for the bo. >>> c) Set up GPU page tables. >>> >>> >>> >> >> Nouveau doesn't do this exactly. ?I wanted to avoid having to check if >> a >> bo was bound to a particular address space on every command >> submission. >> >> >> > > It perhaps might be a good idea to revisit this? > I think using move_notify to set up a new placement before the data has > actually been moved is very fragile and not the intended use. That > would > also save you from having to handle error paths. Also how do you handle > swapouts? > > I don't see how it's fragile, there's only the one error path after that point that needs to undo it. ?And, what *is* the expected use then? ?I see it as "tell the driver the buffer is moving so it can do whatever is necessary as a result". Swapouts are a missed case though, indeed. > > A quick check in c) that the virtual map hasn't been torn down by a > move_notify and, in that case, rebuild it would probably be next to > free. The virtual GPU mapping would then be valid only after validation > and while the bo is fenced or pinned. > > This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. >>> >>> I think you misunderstand me a little. >>> The swapout issue should be handled by calling a move_notify() to kill >>> the virtual GPU mappings. >>> >>> However, when moving data that has page tables pointing to it, one >>> should (IMHO) do: >>> >>> 1) Kill the old page tables >>> 2) Move the object >>> 3) Set up new page tables on demand. >>> >>> This is done by TTM for CPU page tables and I think that should be done >>> also for GPU page tables. move_notify() should be responsible for 1), >>> The driver execbuf for 3), and 3) needs only to be
max PWM is zero
So, anybody gets the same message? I'm trying the 3.2-rc2 and it gives the same message. Again, if you need someone to make tests, or test some patches, I'm able to do this. * Uma vida sem desafios ? uma vida sem raz?o * * A life without challanges is a non reason life * On Tue, 15 Nov 2011, Marcos Paulo de Souza wrote: > Hi lkml, > > I'm using the kernel 3.2-rc1 and I'm getting the following message in my > dmesg: > fixme: max PWM is zero. > > I don't remember if this message was here before... > > I'm trying to verify what is causing this. I found this waring message in the > drivers/gpu/drm/i915/intel_panel.c. > > There is a comment above this message, talking about put a code to query > mode clock or hw clock to set the max PWM. > > Bellow is my lspci. > > I will be happy if you continue to cc me, and if you need any test, I'm able > to do this. > > 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory > Controller Hub (rev 09) > Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 > Flags: bus master, fast devsel, latency 0 > Capabilities: [e0] Vendor Specific Information: Len=0a > Kernel driver in use: agpgart-intel > Kernel modules: intel-agp > > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset > Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) > Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 > Flags: bus master, fast devsel, latency 0, IRQ 44 > Memory at f800 (64-bit, non-prefetchable) [size=4M] > Memory at d000 (64-bit, prefetchable) [size=256M] > I/O ports at 1800 [size=8] > Expansion ROM at [disabled] > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > Capabilities: [d0] Power Management version 3 > Kernel driver in use: i915 > Kernel modules: i915 > > 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset > Integrated Graphics Controller (rev 09) > Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 > Flags: bus master, fast devsel, latency 0 > Memory at f840 (64-bit, non-prefetchable) [size=1M] > Capabilities: [d0] Power Management version 3 > > 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI > Controller #4 (rev 03) (prog-if 00 [UHCI]) > Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 > Flags: bus master, medium devsel, latency 0, IRQ 16 > I/O ports at 1820 [size=32] > Capabilities: [50] PCI Advanced Features > Kernel driver in use: uhci_hcd > > 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI > Controller #5 (rev 03) (prog-if 00 [UHCI]) > Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 > Flags: bus master, medium devsel, latency 0, IRQ 21 > I/O ports at 1840 [size=32] > Capabilities: [50] PCI Advanced Features > Kernel driver in use: uhci_hcd > > 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI > Controller #6 (rev 03) (prog-if 00 [UHCI]) > Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 > Flags: bus master, medium devsel, latency 0, IRQ 19 > I/O ports at 1860 [size=32] > Capabilities: [50] PCI Advanced Features > Kernel driver in use: uhci_hcd > > 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI > Controller #2 (rev 03) (prog-if 20 [EHCI]) > Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 > Flags: bus master, medium devsel, latency 0, IRQ 19 > Memory at f8704000 (32-bit, non-prefetchable) [size=1K] > Capabilities: [50] Power Management version 2 > Capabilities: [58] Debug port: BAR=1 offset=00a0 > Capabilities: [98] PCI Advanced Features > Kernel driver in use: ehci_hcd > > 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio > Controller (rev 03) > Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009 > Flags: bus master, fast devsel, latency 0, IRQ 43 > Memory at f870 (64-bit, non-prefetchable) [size=16K] > Capabilities: [50] Power Management version 2 > Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 > Capabilities: [100] Virtual Channel > Capabilities: [130] Root Complex Link > Kernel driver in use: snd_hda_intel > Kernel modules: snd-hda-intel > > 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 > (rev 03) (prog-if 00 [Normal decode]) > Flags: bus master, fast devsel, latency 0 > Bus: primary=00, secondary=02, subordinate=03, sec-latency=0 > I/O behind bridge: 2000-2fff > Memory behind bridge: f400-f5ff > Prefetchable memory behind bridge: f000-f1ff > Capabilities: [40] Express Root Port (Slot+), MSI 00 >
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On 11/19/2011 01:26 AM, Ben Skeggs wrote: > On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: > >> On 11/18/2011 06:26 PM, Ben Skeggs wrote: >> >>> On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: >>> >>> On 11/18/2011 02:15 PM, Ben Skeggs wrote: > On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: > > > >> Jerome, >> >> I don't like this change for the following reasons >> >> >> > -snip- > > > > >>> One can take advantage of move notify callback but, there are >>> corner case where bind/unbind might be call without move notify >>> being call (in error path mostly). So to make sure that each >>> virtual address space have a consistent view of wether a buffer >>> object is backed or not by system page it's better to pass the >>> buffer object to bind/unbind. >>> >>> >>> > As I discussed previously with Jerome on IRC, I believe the move_notify > hook is sufficient. I fixed a couple of issues back with it back when I > implemented support for this in nouveau. > > Jerome did point out two issues however, which I believe can be solved > easily enough. > > The first was that the error path after move_notify() has been called > doesn't reverse the move_notify() too, leaving incorrect page table > entries. This, I think, could easily be solved by swapping bo->mem and > mem, and re-calling move_notify() to have the driver reverse whatever it > did. > > The second issue is that apparently move_notify() doesn't get called in > the destroy path. Nouveau's GEM layer takes care of this for our > userspace bos, and we don't use any kernel bos that are mapped into a > channel's address space so we don't hit it. This can probably be solved > easily enough too I expect. > > Ben. > > > > OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. >>> Nouveau doesn't do this exactly. I wanted to avoid having to check if a >>> bo was bound to a particular address space on every command submission. >>> >>> >> It perhaps might be a good idea to revisit this? >> I think using move_notify to set up a new placement before the data has >> actually been moved is very fragile and not the intended use. That would >> also save you from having to handle error paths. Also how do you handle >> swapouts? >> > I don't see how it's fragile, there's only the one error path after that > point that needs to undo it. And, what *is* the expected use then? I > see it as "tell the driver the buffer is moving so it can do whatever is > necessary as a result". > > Swapouts are a missed case though, indeed. > > >> A quick check in c) that the virtual map hasn't been torn down by a >> move_notify and, in that case, rebuild it would probably be next to >> free. The virtual GPU mapping would then be valid only after validation >> and while the bo is fenced or pinned. >> > This alone doesn't solve the swapouts issue either unless you're also > wanting us to unmap once a buffer becomes unfenced, which would lead to > loads of completely unnecessary map/unmaps. > > Ben. > I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf for 3), and 3) needs only to be done for the particular ring / fifo which is executing commands that touch the buffer. This leaves a clear and well-defined requirement on TTM: Notify the driver when it needs to kill its GPU page tables. With the latest patch from jerome: Notify the driver when it needs to rebuild it page tables. Also on error paths, but not for swapins because no driver will probably set up GPU page tables to SYSTEM_MEMORY. This is what I mean with fragile, and I much rather see the other approach. Ben, I didn't fully understand why you didn't want to use that approach. Did you see a significant overhead with it. Thanks, /Thomas
max PWM is zero
On Sat, 19 Nov 2011 11:26:07 + (Local time zone must be set--see zic manual page), Marcos Paulo de Souza wrote: > So, anybody gets the same message? > > I'm trying the 3.2-rc2 and it gives the same message. > > Again, if you need someone to make tests, or test some patches, I'm > able to do this. Is your machine even using the intel backlight device? You can test this by: # cd /sys/class/backlight/intel_backlight Then look at 'max_brightness' and try echoing a range of numbers from 0 to max_brightness into the brightness file and see if it changes the backlight. It's more than possible that your machine is simply using some other hardware to drive the backlight and that the integrated backlight controller is simply disabled. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2019/f0e5c6cd/attachment.pgp>
[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov
wrote:
> Just one question I caught on 2nd read. Shouldn't we have #else within
> this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
> not defined, we'll always disable rc6.
Oops! Thanks for catching this. Here's a new version of that function
(the rest of the patch is the same). This one has explicit conditions
for Ironlake and Sandybridge (when CONFIG_INTEL_IOMMU is set), allowing
the Ivybridge and Sandybridge-without-IOMMU cases to take the default
path. This will also cause all future chips to enable rc6 by default.
+static bool intel_enable_rc6(struct drm_device *dev)
+{
+ /*
+* Respect the kernel parameter if it is set
+*/
+ if (i915_enable_rc6 >= 0)
+ return i915_enable_rc6;
+
+ /*
+* Disable RC6 on Ironlake
+*/
+ if (INTEL_INFO(dev)->gen == 5)
+ return 0;
+
+#ifdef CONFIG_INTEL_IOMMU
+ /*
+* Enable rc6 on Sandybridge if DMA remapping is disabled
+*/
+ if (INTEL_INFO(dev)->gen == 6)
+ return no_iommu || dmar_disabled;
+#endif
+ return 1;
+}
+
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2019/ed4e6053/attachment.pgp>
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: > On 11/18/2011 06:26 PM, Ben Skeggs wrote: > > On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: > > > >> On 11/18/2011 02:15 PM, Ben Skeggs wrote: > >> > >>> On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: > >>> > >>> > Jerome, > > I don't like this change for the following reasons > > > >>> -snip- > >>> > >>> > >>> > > One can take advantage of move notify callback but, there are > > corner case where bind/unbind might be call without move notify > > being call (in error path mostly). So to make sure that each > > virtual address space have a consistent view of wether a buffer > > object is backed or not by system page it's better to pass the > > buffer object to bind/unbind. > > > > > >>> As I discussed previously with Jerome on IRC, I believe the move_notify > >>> hook is sufficient. I fixed a couple of issues back with it back when I > >>> implemented support for this in nouveau. > >>> > >>> Jerome did point out two issues however, which I believe can be solved > >>> easily enough. > >>> > >>> The first was that the error path after move_notify() has been called > >>> doesn't reverse the move_notify() too, leaving incorrect page table > >>> entries. This, I think, could easily be solved by swapping bo->mem and > >>> mem, and re-calling move_notify() to have the driver reverse whatever it > >>> did. > >>> > >>> The second issue is that apparently move_notify() doesn't get called in > >>> the destroy path. Nouveau's GEM layer takes care of this for our > >>> userspace bos, and we don't use any kernel bos that are mapped into a > >>> channel's address space so we don't hit it. This can probably be solved > >>> easily enough too I expect. > >>> > >>> Ben. > >>> > >>> > >>> > >> OK. I understand. Surely if a move_notify is missing somewhere, that can > >> easily be fixed. > >> > >> It might be good if we can outline how the virtual tables are set up. In > >> my world, the following would happen: > >> > >> 1) Pre command submission: > >> > >> a) reserve bo > >> b) call ttm_bo_validate to set placement. move_notify will tear down any > >> existing GPU page tables for the bo. > >> c) Set up GPU page tables. > >> > > Nouveau doesn't do this exactly. I wanted to avoid having to check if a > > bo was bound to a particular address space on every command submission. > > > > It perhaps might be a good idea to revisit this? > I think using move_notify to set up a new placement before the data has > actually been moved is very fragile and not the intended use. That would > also save you from having to handle error paths. Also how do you handle > swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as "tell the driver the buffer is moving so it can do whatever is necessary as a result". Swapouts are a missed case though, indeed. > > A quick check in c) that the virtual map hasn't been torn down by a > move_notify and, in that case, rebuild it would probably be next to > free. The virtual GPU mapping would then be valid only after validation > and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. > > Thanks, > Thomas > > > We allocate the virtual address when a client first gets a reference to > > a bo (ie. creates new buffer, or opens an existing handle). If the > > buffer happens to be in VRAM or TT memory at this point, it's also > > mapped. > > > > And as buffers move around, we get called by TTM through move_notify() > > of course, and do any mapping/unmapping that's necessary as a result. > > > > Ben. > > > > > >> d) Command submission > >> e) unreserve_bo(). > >> > >> > >> 2) When eviction happens: > >> a) reserve bo > >> b) move_notify is called to tear down page tables > >> c) change placement > >> d) Unreserve bo. > >> > >> Let's say an error occurs in 1d) Why would you need to undo 1c? > >> > >> Similarly if an error occurs in 2c) Why would you need to undo 2b)? > >> > >> Thanks, > >> Thomas > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > >
[PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver
On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote: > On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang > wrote: > > > However when in X, ->mode_set won't be called at all. Only > > ->get_modes and ->detect are called... > > The desktop software will call mode_set when it configures the > monitor. Otherwise, it's not being used (and so shouldn't have audio > routed to it by default). Thanks for the info! I'll (borrow some monitor and) double check next week. Anyway, the first two patches are good and may be taken first. Thanks, Fengguang
[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Sat, Nov 19, 2011 at 04:41, Keith Packard wrote:
>
> +static bool intel_enable_rc6(struct drm_device *dev)
> +{
> + ? ? ? if (i915_enable_rc6 >= 0)
> + ? ? ? ? ? ? ? return i915_enable_rc6;
> + ? ? ? if (INTEL_INFO(dev)->gen >= 7)
> + ? ? ? ? ? ? ? return 1;
> +#ifdef CONFIG_INTEL_IOMMU
> + ? ? ? /*
> + ? ? ? ?* Only enable RC6 if all dma remapping is disabled, or if
> + ? ? ? ?* there's no iommu present in the machine.
> + ? ? ? ?*/
> + ? ? ? if (INTEL_INFO(dev)->gen == 6)
> + ? ? ? ? ? ? ? return no_iommu || dmar_disabled;
> +#endif
> + ? ? ? return 0;
> +}
Just one question I caught on 2nd read. Shouldn't we have #else within
this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
not defined, we'll always disable rc6.
Or we just always intend to disable rc6 in case CONFIG_INTEL_IOMMU is not there?
--
Eugeni Dodonov
[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Sat, Nov 19, 2011 at 04:41, Keith Packard wrote: > RC6 should always work on IVB, and should work on SNB whenever IO > remapping is disabled. Make the default value for the parameter turn > it on in these cases. Setting the value to either 0 or 1 will force > the specified behavior. > > Signed-off-by: Keith Packard > Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov <http://eugeni.dodonov.net/> -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2019/b674cf3e/attachment.html>
[PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: > On 11/18/2011 02:15 PM, Ben Skeggs wrote: > > On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: > > > >> Jerome, > >> > >> I don't like this change for the following reasons > >> > > -snip- > > > > > >>> One can take advantage of move notify callback but, there are > >>> corner case where bind/unbind might be call without move notify > >>> being call (in error path mostly). So to make sure that each > >>> virtual address space have a consistent view of wether a buffer > >>> object is backed or not by system page it's better to pass the > >>> buffer object to bind/unbind. > >>> > > As I discussed previously with Jerome on IRC, I believe the move_notify > > hook is sufficient. I fixed a couple of issues back with it back when I > > implemented support for this in nouveau. > > > > Jerome did point out two issues however, which I believe can be solved > > easily enough. > > > > The first was that the error path after move_notify() has been called > > doesn't reverse the move_notify() too, leaving incorrect page table > > entries. This, I think, could easily be solved by swapping bo->mem and > > mem, and re-calling move_notify() to have the driver reverse whatever it > > did. > > > > The second issue is that apparently move_notify() doesn't get called in > > the destroy path. Nouveau's GEM layer takes care of this for our > > userspace bos, and we don't use any kernel bos that are mapped into a > > channel's address space so we don't hit it. This can probably be solved > > easily enough too I expect. > > > > Ben. > > > > > > OK. I understand. Surely if a move_notify is missing somewhere, that can > easily be fixed. > > It might be good if we can outline how the virtual tables are set up. In > my world, the following would happen: > > 1) Pre command submission: > > a) reserve bo > b) call ttm_bo_validate to set placement. move_notify will tear down any > existing GPU page tables for the bo. > c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. We allocate the virtual address when a client first gets a reference to a bo (ie. creates new buffer, or opens an existing handle). If the buffer happens to be in VRAM or TT memory at this point, it's also mapped. And as buffers move around, we get called by TTM through move_notify() of course, and do any mapping/unmapping that's necessary as a result. Ben. > d) Command submission > e) unreserve_bo(). > > > 2) When eviction happens: > a) reserve bo > b) move_notify is called to tear down page tables > c) change placement > d) Unreserve bo. > > Let's say an error occurs in 1d) Why would you need to undo 1c? > > Similarly if an error occurs in 2c) Why would you need to undo 2b)? > > Thanks, > Thomas > > > > > > > >
Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Sat, Nov 19, 2011 at 04:41, Keith Packard kei...@keithp.com wrote: RC6 should always work on IVB, and should work on SNB whenever IO remapping is disabled. Make the default value for the parameter turn it on in these cases. Setting the value to either 0 or 1 will force the specified behavior. Signed-off-by: Keith Packard kei...@keithp.com Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Sat, Nov 19, 2011 at 04:41, Keith Packard kei...@keithp.com wrote:
+static bool intel_enable_rc6(struct drm_device *dev)
+{
+ if (i915_enable_rc6 = 0)
+ return i915_enable_rc6;
+ if (INTEL_INFO(dev)-gen = 7)
+ return 1;
+#ifdef CONFIG_INTEL_IOMMU
+ /*
+ * Only enable RC6 if all dma remapping is disabled, or if
+ * there's no iommu present in the machine.
+ */
+ if (INTEL_INFO(dev)-gen == 6)
+ return no_iommu || dmar_disabled;
+#endif
+ return 0;
+}
Just one question I caught on 2nd read. Shouldn't we have #else within
this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
not defined, we'll always disable rc6.
Or we just always intend to disable rc6 in case CONFIG_INTEL_IOMMU is not there?
--
Eugeni Dodonov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On 11/19/2011 01:26 AM, Ben Skeggs wrote: On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: On 11/18/2011 06:26 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: On 11/18/2011 02:15 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: Jerome, I don't like this change for the following reasons -snip- One can take advantage of move notify callback but, there are corner case where bind/unbind might be call without move notify being call (in error path mostly). So to make sure that each virtual address space have a consistent view of wether a buffer object is backed or not by system page it's better to pass the buffer object to bind/unbind. As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. This, I think, could easily be solved by swapping bo-mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. This can probably be solved easily enough too I expect. Ben. OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as tell the driver the buffer is moving so it can do whatever is necessary as a result. Swapouts are a missed case though, indeed. A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf for 3), and 3) needs only to be done for the particular ring / fifo which is executing commands that touch the buffer. This leaves a clear and well-defined requirement on TTM: Notify the driver when it needs to kill its GPU page tables. With the latest patch from jerome: Notify the driver when it needs to rebuild it page tables. Also on error paths, but not for swapins because no driver will probably set up GPU page tables to SYSTEM_MEMORY. This is what I mean with fragile, and I much rather see the other approach. Ben, I didn't fully understand why you didn't want to use that approach. Did you see a significant overhead with it. Thanks, /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: On 11/19/2011 01:26 AM, Ben Skeggs wrote: On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: On 11/18/2011 06:26 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: On 11/18/2011 02:15 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: Jerome, I don't like this change for the following reasons -snip- One can take advantage of move notify callback but, there are corner case where bind/unbind might be call without move notify being call (in error path mostly). So to make sure that each virtual address space have a consistent view of wether a buffer object is backed or not by system page it's better to pass the buffer object to bind/unbind. As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. This, I think, could easily be solved by swapping bo-mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. This can probably be solved easily enough too I expect. Ben. OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as tell the driver the buffer is moving so it can do whatever is necessary as a result. Swapouts are a missed case though, indeed. A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf for 3), and 3) needs only to be done for the particular ring / fifo which is executing commands that touch the buffer. This leaves a clear and well-defined requirement on TTM: Notify the driver when it needs to kill its GPU page tables. Ok. This I don't really object to really. I read the previous mail as that GPU mappings should only exist as long as the buffer is fenced, which would be a ridiculous amount of overhead. With the latest patch from jerome: Notify the driver when it needs to rebuild it page tables. Also on error paths, but not for swapins because no driver will probably set up GPU page tables to SYSTEM_MEMORY. This is what I mean with fragile, and I much rather see the other approach. Ben, I didn't fully understand why you didn't want to use that approach. Did you see a significant overhead with it. Now I'm more clear on what you meant, no, it wouldn't be a lot of overhead. However, move_notify() was never intended for the use you're proposing now, or the
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On 11/19/2011 03:53 PM, Ben Skeggs wrote: On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: On 11/19/2011 01:26 AM, Ben Skeggs wrote: On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: On 11/18/2011 06:26 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: On 11/18/2011 02:15 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: Jerome, I don't like this change for the following reasons -snip- One can take advantage of move notify callback but, there are corner case where bind/unbind might be call without move notify being call (in error path mostly). So to make sure that each virtual address space have a consistent view of wether a buffer object is backed or not by system page it's better to pass the buffer object to bind/unbind. As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. This, I think, could easily be solved by swapping bo-mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. This can probably be solved easily enough too I expect. Ben. OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as tell the driver the buffer is moving so it can do whatever is necessary as a result. Swapouts are a missed case though, indeed. A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf for 3), and 3) needs only to be done for the particular ring / fifo which is executing commands that touch the buffer. This leaves a clear and well-defined requirement on TTM: Notify the driver when it needs to kill its GPU page tables. Ok. This I don't really object to really. I read the previous mail as that GPU mappings should only exist as long as the buffer is fenced, which would be a ridiculous amount of overhead. I agree. What I meant was that the page tables wouldn't be considered valid when the fence had signaled. However that was actually incorrect because they would actually be valid until the next move_notify(). The intention was never to tear down the mappings once the fence had signaled; that would have been pretty stupid. With the latest patch from jerome: Notify the driver when it needs to rebuild it page tables. Also on error paths, but not for swapins because no driver will probably set up GPU page tables to SYSTEM_MEMORY. This is what I mean with fragile, and I much rather see the other approach.
[Bug 34626] Mesa-Gallium with R600 - Framerate limited to 60 fps after suspend-cycle
https://bugs.freedesktop.org/show_bug.cgi?id=34626 --- Comment #9 from Peter Weber peter.we...@ttyhoney.com 2011-11-19 09:40:14 PST --- I've tested this in the meantime also with a Intel based grapcis solution (Ironlake), it is not affected. But the Intel driver doesn't need the var vblank_mode for switching vsync off (only SwapbuffersWait). Maybe the setting of the var gets lost during suspend cycle? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom thellst...@vmware.com wrote: On 11/19/2011 03:53 PM, Ben Skeggs wrote: On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: On 11/19/2011 01:26 AM, Ben Skeggs wrote: On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: On 11/18/2011 06:26 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: On 11/18/2011 02:15 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: Jerome, I don't like this change for the following reasons -snip- One can take advantage of move notify callback but, there are corner case where bind/unbind might be call without move notify being call (in error path mostly). So to make sure that each virtual address space have a consistent view of wether a buffer object is backed or not by system page it's better to pass the buffer object to bind/unbind. As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. This, I think, could easily be solved by swapping bo-mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. This can probably be solved easily enough too I expect. Ben. OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as tell the driver the buffer is moving so it can do whatever is necessary as a result. Swapouts are a missed case though, indeed. A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf for 3), and 3) needs only to be done for the particular ring / fifo which is executing commands that touch the buffer. This leaves a clear and well-defined requirement on TTM: Notify the driver when it needs to kill its GPU page tables. Ok. This I don't really object to really. I read the previous mail as that GPU mappings should only exist as long as the buffer is fenced, which would be a ridiculous amount of overhead. I agree. What I meant was that the page tables wouldn't be considered valid when the fence had signaled. However that was actually incorrect because they would actually be valid until the next move_notify(). The intention was never to tear down the mappings once the fence had signaled; that would have been pretty stupid. With the latest patch from jerome: Notify the driver when it needs to rebuild it page tables. Also on error paths, but not for swapins because no driver will probably set up GPU page tables to SYSTEM_MEMORY. This is what I mean with fragile, and I much rather see the other approach. Ben, I didn't
Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov eug...@dodonov.net wrote:
Just one question I caught on 2nd read. Shouldn't we have #else within
this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
not defined, we'll always disable rc6.
Oops! Thanks for catching this. Here's a new version of that function
(the rest of the patch is the same). This one has explicit conditions
for Ironlake and Sandybridge (when CONFIG_INTEL_IOMMU is set), allowing
the Ivybridge and Sandybridge-without-IOMMU cases to take the default
path. This will also cause all future chips to enable rc6 by default.
+static bool intel_enable_rc6(struct drm_device *dev)
+{
+ /*
+* Respect the kernel parameter if it is set
+*/
+ if (i915_enable_rc6 = 0)
+ return i915_enable_rc6;
+
+ /*
+* Disable RC6 on Ironlake
+*/
+ if (INTEL_INFO(dev)-gen == 5)
+ return 0;
+
+#ifdef CONFIG_INTEL_IOMMU
+ /*
+* Enable rc6 on Sandybridge if DMA remapping is disabled
+*/
+ if (INTEL_INFO(dev)-gen == 6)
+ return no_iommu || dmar_disabled;
+#endif
+ return 1;
+}
+
--
keith.pack...@intel.com
pgpsVTFwiWzSB.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On 11/19/2011 07:11 PM, Jerome Glisse wrote: On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom thellst...@vmware.com wrote: On 11/19/2011 03:53 PM, Ben Skeggs wrote: On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: On 11/19/2011 01:26 AM, Ben Skeggs wrote: On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: On 11/18/2011 06:26 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: On 11/18/2011 02:15 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: Jerome, I don't like this change for the following reasons -snip- One can take advantage of move notify callback but, there are corner case where bind/unbind might be call without move notify being call (in error path mostly). So to make sure that each virtual address space have a consistent view of wether a buffer object is backed or not by system page it's better to pass the buffer object to bind/unbind. As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. This, I think, could easily be solved by swapping bo-mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. This can probably be solved easily enough too I expect. Ben. OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as tell the driver the buffer is moving so it can do whatever is necessary as a result. Swapouts are a missed case though, indeed. A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf for 3), and 3) needs only to be done for the particular ring / fifo which is executing commands that touch the buffer. This leaves a clear and well-defined requirement on TTM: Notify the driver when it needs to kill its GPU page tables. Ok. This I don't really object to really. I read the previous mail as that GPU mappings should only exist as long as the buffer is fenced, which would be a ridiculous amount of overhead. I agree. What I meant was that the page tables wouldn't be considered valid when the fence had signaled. However that was actually incorrect because they would actually be valid until the next move_notify(). The intention was never to tear down the mappings once the fence had signaled; that would have been pretty stupid. With the latest patch from jerome: Notify the
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sat, Nov 19, 2011 at 2:46 PM, Thomas Hellstrom thellst...@vmware.com wrote: On 11/19/2011 07:11 PM, Jerome Glisse wrote: On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom thellst...@vmware.com wrote: On 11/19/2011 03:53 PM, Ben Skeggs wrote: On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: On 11/19/2011 01:26 AM, Ben Skeggs wrote: On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: On 11/18/2011 06:26 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: On 11/18/2011 02:15 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: Jerome, I don't like this change for the following reasons -snip- One can take advantage of move notify callback but, there are corner case where bind/unbind might be call without move notify being call (in error path mostly). So to make sure that each virtual address space have a consistent view of wether a buffer object is backed or not by system page it's better to pass the buffer object to bind/unbind. As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. This, I think, could easily be solved by swapping bo-mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. This can probably be solved easily enough too I expect. Ben. OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as tell the driver the buffer is moving so it can do whatever is necessary as a result. Swapouts are a missed case though, indeed. A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf for 3), and 3) needs only to be done for the particular ring / fifo which is executing commands that touch the buffer. This leaves a clear and well-defined requirement on TTM: Notify the driver when it needs to kill its GPU page tables. Ok. This I don't really object to really. I read the previous mail as that GPU mappings should only exist as long as the buffer is fenced, which would be a ridiculous amount of overhead. I agree. What I meant was that the page tables wouldn't be considered valid when the fence had signaled. However that was actually incorrect because they would actually be valid until the next move_notify(). The intention was never to tear down the mappings once the fence had signaled; that would have been pretty stupid. With the latest patch from jerome: Notify the driver when it needs to rebuild it page tables. Also on error paths, but not for swapins because no driver
Re: [PATCH] drm/ttm: callback move_notify any time bo placement change v3
On 11/19/2011 12:32 AM, j.gli...@gmail.com wrote:
From: Jerome Glissejgli...@redhat.com
Previously we were calling back move_notify in error path when the
bo is returned to it's original position or when destroy the bo.
When destroying the bo set the new mem placement as NULL when calling
back in the driver.
Updating nouveau to deal with NULL placement properly.
v2: reserve the object before calling move_notify in bo destroy path
at that point ttm should be the only piece of code interacting
with the object so atomic_set is safe here.
v3: callback move notify only once the bo is in its new position
call move notify want swaping out the buffer
Reviewed-by: Jerome Glissejgli...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 17 +
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 857bca4..f12dd0f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -815,10 +815,10 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct
ttm_mem_reg *new_mem)
struct nouveau_vma *vma;
list_for_each_entry(vma,nvbo-vma_list, head) {
- if (new_mem-mem_type == TTM_PL_VRAM) {
+ if (new_mem new_mem-mem_type == TTM_PL_VRAM) {
nouveau_vm_map(vma, new_mem-mm_node);
} else
- if (new_mem-mem_type == TTM_PL_TT
+ if (new_mem new_mem-mem_type == TTM_PL_TT
nvbo-page_shift == vma-vm-spg_shift) {
nouveau_vm_map_sg(vma, 0, new_mem-
num_pages PAGE_SHIFT,
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index de7ad99..0c1d821 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -147,6 +147,12 @@ static void ttm_bo_release_list(struct kref *list_kref)
BUG_ON(!list_empty(bo-lru));
BUG_ON(!list_empty(bo-ddestroy));
+ /* force bo to reserved, at this point we should be the only owner */
+ atomic_set(bo-reserved, 1);
+ if (bdev-driver-move_notify)
+ bdev-driver-move_notify(bo, NULL);
+ atomic_set(bo-reserved, 0);
We can actually do this from the top of ttm_bo_cleanup_memtype_use().
Then we should catch all current and future use-cases and you wouldn't
need the fake reserving, because at that point, we're already reserved.
+
if (bo-ttm)
ttm_tt_destroy(bo-ttm);
atomic_dec(bo-glob-bo_count);
@@ -404,9 +410,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
}
- if (bdev-driver-move_notify)
- bdev-driver-move_notify(bo, mem);
-
if (!(old_man-flags TTM_MEMTYPE_FLAG_FIXED)
!(new_man-flags TTM_MEMTYPE_FLAG_FIXED))
ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve, no_wait_gpu,
mem);
@@ -419,6 +422,9 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
if (ret)
goto out_err;
+ if (bdev-driver-move_notify)
+ bdev-driver-move_notify(bo, mem);
+
moved:
if (bo-evicted) {
ret = bdev-driver-invalidate_caches(bdev, bo-mem.placement);
@@ -1872,9 +1878,12 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
if (bo-bdev-driver-swap_notify)
bo-bdev-driver-swap_notify(bo);
+ if (bo-bdev-driver-move_notify)
+ bo-bdev-driver-move_notify(bo, NULL);
+
Hmm. On second thought, we could use swap_notify() for this, I missed we
already had that and that's what vmwgfx once used for exactly the same
purpose.
ret = ttm_tt_swapout(bo-ttm, bo-persistent_swap_storage);
-out:
+out:
Whitespace.
/Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add a CS ioctl flag not to rewrite tiling flags in the CS
Ping. Will anyone pick up this patch, please?
Marek
On Tue, Oct 25, 2011 at 1:38 AM, Marek Olšák mar...@gmail.com wrote:
This adds a new optional chunk to the CS ioctl that specifies optional flags
to the CS parser. Why this is useful is explained below. Note that some regs
no longer need the NOP relocation packet if this feature is enabled.
Tested on r300g and r600g with this flag disabled and enabled.
Assume there are two contexts sharing the same mipmapped tiled texture.
One context wants to render into the first mipmap and the other one
wants to render into the last mipmap. As you probably know, the hardware
has a MACRO_SWITCH feature, which turns off macro tiling for small mipmaps,
but that only applies to samplers.
(at least on r300-r500, though later hardware likely behaves the same)
So we want to just re-set the tiling flags before rendering (writing
packets), right? ... No. The contexts run in parallel, so they may
set the tiling flags simultaneously and then fire their command streams
also simultaneously. The last one setting the flags wins, the other one
loses.
Another problem is when one context wants to render into the first and
the last mipmap in one CS. Impossible. It must flush before changing
tiling flags and do the rendering into the smaller mipmaps in another CS.
Yet another problem is that writing copy_blit in userspace would be a mess
involving re-setting tiling flags to please the kernel, and causing races
with other contexts at the same time.
The only way out of this is to send tiling flags with each CS, ideally
with each relocation. But we already do that through the registers.
So let's just use what we have in the registers.
Signed-off-by: Marek Olšák mar...@gmail.com
---
drivers/gpu/drm/radeon/evergreen_cs.c | 92 +---
drivers/gpu/drm/radeon/r300.c | 94
++---
drivers/gpu/drm/radeon/r600_cs.c | 26 ++
drivers/gpu/drm/radeon/radeon.h | 3 +-
drivers/gpu/drm/radeon/radeon_cs.c | 11 -
drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
include/drm/radeon_drm.h | 4 ++
7 files changed, 135 insertions(+), 98 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index a134790..86b060c 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -508,21 +508,23 @@ static inline int evergreen_cs_check_reg(struct
radeon_cs_parser *p, u32 reg, u3
}
break;
case DB_Z_INFO:
- r = evergreen_cs_packet_next_reloc(p, reloc);
- if (r) {
- dev_warn(p-dev, bad SET_CONTEXT_REG
- 0x%04X\n, reg);
- return -EINVAL;
- }
track-db_z_info = radeon_get_ib_value(p, idx);
- ib[idx] = ~Z_ARRAY_MODE(0xf);
- track-db_z_info = ~Z_ARRAY_MODE(0xf);
- if (reloc-lobj.tiling_flags RADEON_TILING_MACRO) {
- ib[idx] |= Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
- track-db_z_info |=
Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
- } else {
- ib[idx] |= Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
- track-db_z_info |=
Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
+ if (!p-keep_tiling_flags) {
+ r = evergreen_cs_packet_next_reloc(p, reloc);
+ if (r) {
+ dev_warn(p-dev, bad SET_CONTEXT_REG
+ 0x%04X\n, reg);
+ return -EINVAL;
+ }
+ ib[idx] = ~Z_ARRAY_MODE(0xf);
+ track-db_z_info = ~Z_ARRAY_MODE(0xf);
+ if (reloc-lobj.tiling_flags RADEON_TILING_MACRO) {
+ ib[idx] |= Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
+ track-db_z_info |=
Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
+ } else {
+ ib[idx] |= Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
+ track-db_z_info |=
Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
+ }
}
break;
case DB_STENCIL_INFO:
@@ -635,40 +637,44 @@ static inline int evergreen_cs_check_reg(struct
radeon_cs_parser *p, u32 reg, u3
case CB_COLOR5_INFO:
case CB_COLOR6_INFO:
case CB_COLOR7_INFO:
- r = evergreen_cs_packet_next_reloc(p, reloc);
- if (r) {
- dev_warn(p-dev, bad SET_CONTEXT_REG
- 0x%04X\n, reg);
- return -EINVAL;
- }
tmp = (reg - CB_COLOR0_INFO) /
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On 11/19/2011 09:37 PM, Jerome Glisse wrote: On Sat, Nov 19, 2011 at 2:46 PM, Thomas Hellstromthellst...@vmware.com wrote: On 11/19/2011 07:11 PM, Jerome Glisse wrote: On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom thellst...@vmware.com wrote: On 11/19/2011 03:53 PM, Ben Skeggs wrote: On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: On 11/19/2011 01:26 AM, Ben Skeggs wrote: On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: On 11/18/2011 06:26 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: On 11/18/2011 02:15 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: Jerome, I don't like this change for the following reasons -snip- One can take advantage of move notify callback but, there are corner case where bind/unbind might be call without move notify being call (in error path mostly). So to make sure that each virtual address space have a consistent view of wether a buffer object is backed or not by system page it's better to pass the buffer object to bind/unbind. As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. This, I think, could easily be solved by swapping bo-mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. This can probably be solved easily enough too I expect. Ben. OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as tell the driver the buffer is moving so it can do whatever is necessary as a result. Swapouts are a missed case though, indeed. A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf for 3), and 3) needs only to be done for the particular ring / fifo which is executing commands that touch the buffer. This leaves a clear and well-defined requirement on TTM: Notify the driver when it needs to kill its GPU page tables. Ok. This I don't really object to really. I read the previous mail as that GPU mappings should only exist as long as the buffer is fenced, which would be a ridiculous amount of overhead. I agree. What I meant was that the page tables wouldn't be considered valid when the fence had signaled. However that was actually incorrect because they would actually be valid until the next move_notify(). The intention was never to tear down the mappings once the fence had signaled; that would have been pretty stupid. With the latest patch from jerome: Notify the driver when it needs to rebuild it page tables. Also on error paths, but not for swapins because no driver will probably set up GPU page tables to SYSTEM_MEMORY.
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sat, Nov 19, 2011 at 4:01 PM, Thomas Hellstrom thellst...@vmware.com wrote: On 11/19/2011 09:37 PM, Jerome Glisse wrote: On Sat, Nov 19, 2011 at 2:46 PM, Thomas Hellstromthellst...@vmware.com wrote: On 11/19/2011 07:11 PM, Jerome Glisse wrote: On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom thellst...@vmware.com wrote: On 11/19/2011 03:53 PM, Ben Skeggs wrote: On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: On 11/19/2011 01:26 AM, Ben Skeggs wrote: On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: On 11/18/2011 06:26 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: On 11/18/2011 02:15 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: Jerome, I don't like this change for the following reasons -snip- One can take advantage of move notify callback but, there are corner case where bind/unbind might be call without move notify being call (in error path mostly). So to make sure that each virtual address space have a consistent view of wether a buffer object is backed or not by system page it's better to pass the buffer object to bind/unbind. As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. This, I think, could easily be solved by swapping bo-mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. This can probably be solved easily enough too I expect. Ben. OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as tell the driver the buffer is moving so it can do whatever is necessary as a result. Swapouts are a missed case though, indeed. A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf for 3), and 3) needs only to be done for the particular ring / fifo which is executing commands that touch the buffer. This leaves a clear and well-defined requirement on TTM: Notify the driver when it needs to kill its GPU page tables. Ok. This I don't really object to really. I read the previous mail as that GPU mappings should only exist as long as the buffer is fenced, which would be a ridiculous amount of overhead. I agree. What I meant was that the page tables wouldn't be considered valid when the fence had signaled. However that was actually incorrect because they would actually be valid until the next move_notify(). The intention was never to tear down the mappings once the fence had signaled; that would have been pretty stupid. With the latest patch
[Bug 43096] New: r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096
Bug #: 43096
Summary: r300g: r300_emit_draw_elements() refusing to render
when max_index = 0x
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: tstel...@gmail.com
Created attachment 53692
-- https://bugs.freedesktop.org/attachment.cgi?id=53692
Callstack from error message
I'm not exactly sure if this is a bug in r300g or st/mesa, but none of the
leader portraits are rendered in Civ4 and this error message is being printed:
r300: Got a huge number of vertices: 310, refusing to render (max_index: -1).
The reason this error message is being printed is because max_index is
0x, so this if statement at r300_render.c:448 evaluates to true:
if (count = (1 24) || max_index = (1 24)) {
fprintf(stderr, r300: Got a huge number of vertices: %i,
refusing to render (max_index: %i).\n, count, max_index);
return;
}
I'm not sure if the state tracker is wrong for passing 0x as the
max_index or if the driver needs to handle a max_index of 0x as a
special case, because it is the default value for pipe_draw_info-max_index. I
have captured the call stack when this error message is printed and attached it
to this bug report.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 Tom Stellard tstel...@gmail.com changed: What|Removed |Added Attachment #53692|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback
On Sat, Nov 19, 2011 at 5:37 PM, Thomas Hellstrom thellst...@vmware.com wrote: On 11/19/2011 10:22 PM, Jerome Glisse wrote: On Sat, Nov 19, 2011 at 4:01 PM, Thomas Hellstromthellst...@vmware.com wrote: On 11/19/2011 09:37 PM, Jerome Glisse wrote: On Sat, Nov 19, 2011 at 2:46 PM, Thomas Hellstromthellst...@vmware.com wrote: On 11/19/2011 07:11 PM, Jerome Glisse wrote: On Sat, Nov 19, 2011 at 12:00 PM, Thomas Hellstrom thellst...@vmware.com wrote: On 11/19/2011 03:53 PM, Ben Skeggs wrote: On Sat, 2011-11-19 at 11:07 +0100, Thomas Hellstrom wrote: On 11/19/2011 01:26 AM, Ben Skeggs wrote: On Fri, 2011-11-18 at 23:48 +0100, Thomas Hellstrom wrote: On 11/18/2011 06:26 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 15:30 +0100, Thomas Hellstrom wrote: On 11/18/2011 02:15 PM, Ben Skeggs wrote: On Fri, 2011-11-18 at 08:57 +0100, Thomas Hellstrom wrote: Jerome, I don't like this change for the following reasons -snip- One can take advantage of move notify callback but, there are corner case where bind/unbind might be call without move notify being call (in error path mostly). So to make sure that each virtual address space have a consistent view of wether a buffer object is backed or not by system page it's better to pass the buffer object to bind/unbind. As I discussed previously with Jerome on IRC, I believe the move_notify hook is sufficient. I fixed a couple of issues back with it back when I implemented support for this in nouveau. Jerome did point out two issues however, which I believe can be solved easily enough. The first was that the error path after move_notify() has been called doesn't reverse the move_notify() too, leaving incorrect page table entries. This, I think, could easily be solved by swapping bo-mem and mem, and re-calling move_notify() to have the driver reverse whatever it did. The second issue is that apparently move_notify() doesn't get called in the destroy path. Nouveau's GEM layer takes care of this for our userspace bos, and we don't use any kernel bos that are mapped into a channel's address space so we don't hit it. This can probably be solved easily enough too I expect. Ben. OK. I understand. Surely if a move_notify is missing somewhere, that can easily be fixed. It might be good if we can outline how the virtual tables are set up. In my world, the following would happen: 1) Pre command submission: a) reserve bo b) call ttm_bo_validate to set placement. move_notify will tear down any existing GPU page tables for the bo. c) Set up GPU page tables. Nouveau doesn't do this exactly. I wanted to avoid having to check if a bo was bound to a particular address space on every command submission. It perhaps might be a good idea to revisit this? I think using move_notify to set up a new placement before the data has actually been moved is very fragile and not the intended use. That would also save you from having to handle error paths. Also how do you handle swapouts? I don't see how it's fragile, there's only the one error path after that point that needs to undo it. And, what *is* the expected use then? I see it as tell the driver the buffer is moving so it can do whatever is necessary as a result. Swapouts are a missed case though, indeed. A quick check in c) that the virtual map hasn't been torn down by a move_notify and, in that case, rebuild it would probably be next to free. The virtual GPU mapping would then be valid only after validation and while the bo is fenced or pinned. This alone doesn't solve the swapouts issue either unless you're also wanting us to unmap once a buffer becomes unfenced, which would lead to loads of completely unnecessary map/unmaps. Ben. I think you misunderstand me a little. The swapout issue should be handled by calling a move_notify() to kill the virtual GPU mappings. However, when moving data that has page tables pointing to it, one should (IMHO) do: 1) Kill the old page tables 2) Move the object 3) Set up new page tables on demand. This is done by TTM for CPU page tables and I think that should be done also for GPU page tables. move_notify() should be responsible for 1), The driver execbuf for 3), and 3) needs only to be done for the particular ring / fifo which is executing commands that touch the buffer. This leaves a clear and well-defined requirement on TTM: Notify the driver when it needs to kill its GPU page tables. Ok. This I don't really object to really. I read the previous mail as that GPU mappings should only exist as long as the buffer is fenced, which would be a ridiculous amount of overhead. I agree. What I meant was that the page tables wouldn't be considered valid when the fence had signaled. However that was actually incorrect because they would actually be valid until the next move_notify(). The
Re: [PATCH] drm_edid: support CEA video modes
Another user confirming the working of the patch from xbmc forums: http://forum.xbmc.org/showpost.php?p=940016postcount=31 Any news on when this will be in master ? Thanks 2011/11/13 Christian Schmidt schm...@digadd.de TFT/plasma televisions and projectors have become commonplace, and so has the use of PCs to drive them. Add the video modes specified by an EDID's CEA extension to the mode database for a connector. Before: [1.158869] [drm:drm_mode_debug_printmodeline], Modeline 19:1920x1080i 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15 [1.158875] [drm:drm_mode_debug_printmodeline], Modeline 18:1920x1080i 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x48 0x15 [1.158882] [drm:drm_mode_debug_printmodeline], Modeline 20:1920x1080 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5 After: [1.144175] [drm:drm_mode_debug_printmodeline], Modeline 22:1920x1080 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15 [1.144179] [drm:drm_mode_debug_printmodeline], Modeline 21:1920x1080 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x48 0x15 [1.144187] [drm:drm_mode_debug_printmodeline], Modeline 30:1920x1080 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 [1.144190] [drm:drm_mode_debug_printmodeline], Modeline 29:1920x1080 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 [1.144192] [drm:drm_mode_debug_printmodeline], Modeline 25:1920x1080 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5 [1.144195] [drm:drm_mode_debug_printmodeline], Modeline 24:1280x720 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5 [1.144198] [drm:drm_mode_debug_printmodeline], Modeline 23:1280x720 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5 [1.144201] [drm:drm_mode_debug_printmodeline], Modeline 27:720x576 50 27000 720 732 796 864 576 581 586 625 0x40 0xa [1.144203] [drm:drm_mode_debug_printmodeline], Modeline 26:720x480 60 27000 720 736 798 858 480 489 495 525 0x40 0xa [1.144206] [drm:drm_mode_debug_printmodeline], Modeline 28:640x480 60 25175 640 656 752 800 480 490 492 525 0x40 0xa Signed-off-by: Christian Schmidt schm...@digadd.de ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43073] Trine not working on Radeon HD6520G
https://bugs.freedesktop.org/show_bug.cgi?id=43073 --- Comment #4 from Sandeep sandy.8...@gmail.com 2011-11-19 19:22:12 PST --- That was the case, libstdc++6 in trine directory was the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43073] Trine not working on Radeon HD6520G
https://bugs.freedesktop.org/show_bug.cgi?id=43073 Sandeep sandy.8...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #1 from Marek Olšák mar...@gmail.com 2011-11-19 20:22:03 PST --- Could you try this branch? git://people.freedesktop.org/~mareko/mesa vbufmgr-fixes -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43096] r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
https://bugs.freedesktop.org/show_bug.cgi?id=43096 --- Comment #2 from Tom Stellard tstel...@gmail.com 2011-11-19 20:48:46 PST --- (In reply to comment #1) Could you try this branch? git://people.freedesktop.org/~mareko/mesa vbufmgr-fixes Still they same problem, but now max_index is -2 instead of -1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
