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
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,
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=43096
Tom Stellard changed:
What|Removed |Added
Attachment #53692|application/octet-stream|text/plain
mime type|
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
;>>> 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>
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 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
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
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
>>>
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
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
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:
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,
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:
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2019/f0e5c6cd/attachment.pgp>
--
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>
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:
>
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
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
> + ?
ied 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>
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=43073
Sandeep sandy.8...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
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
---
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
45 matches
Mail list logo
