https://bugzilla.kernel.org/show_bug.cgi?id=39972
--- Comment #4 from Robert Piasek 2011-08-02 07:38:23 ---
Hi Alex,
I can bi-select this weekend. I cannot do it earlier I'm afraid as it's my
production workstation.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> But I believe this is a problem of all approaches which provide
> multiple hardware-accelerated (or Xv-enabled) seats on a single GPU,
> no matter if based on multiple DRM devices, on Xephyr or Xnest
> with some kind of OpenGL or DRI passthrough, or on Wayland:
> If one has direct access to the g
2011/8/2 Alan Cox :
>> But I believe this is a problem of all approaches which provide
>> multiple hardware-accelerated (or Xv-enabled) seats on a single GPU,
>> no matter if based on multiple DRM devices, on Xephyr or Xnest
>> with some kind of OpenGL or DRI passthrough, or on Wayland:
>> If one h
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #13 from Andrew Randrianasulu 2011-08-02 04:06:28
PDT ---
More info.
When I set NVFX_SWTNL=1 ./vertexrate it also works without lockup. I was
playing with amount of vertex data, and found what defining MAX_VERTS up to
1263 works OK
https://bugs.freedesktop.org/show_bug.cgi?id=34969
Andrew Randrianasulu changed:
What|Removed |Added
Attachment #49333|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=34969
Andrew Randrianasulu changed:
What|Removed |Added
Attachment #49334|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=34495
--- Comment #52 from Lars G 2011-08-02 04:40:28 PDT ---
(In reply to comment #51)
> Created an attachment (id=49807)
View: https://bugs.freedesktop.org/attachment.cgi?id=49807
Review: https://bugs.freedesktop.org/review?bug=34495&attachment=498
On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
wrote:
> On 2011-07-31 22:09, Dave Airlie wrote:
>>>
>>> There once was a patch to allow one X server per graphics card
>>> output:
>>> http://www.facebook.com/note.php?note_id=110388492307351
>>> http://people.freedesktop.org/~airlied/multise
https://bugs.freedesktop.org/show_bug.cgi?id=34495
--- Comment #53 from Micael Dias 2011-08-02 06:27:05 PDT
---
Thanks for testing.
I can reproduce the problem with normal blender, subdivs applied and textured
mode. However it doesn't seem related to this patch or Pierre's since even
rotating a
On Tue, Aug 2, 2011 at 10:22 AM, Prof. Dr. Klaus Kusche
wrote:
> On 2011-08-02 14:59, Alex Deucher wrote:
>>
>> On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
>> wrote:
>>>
>>> Hmmm, what's about the opposite approach?
>>> To me, it sounds simpler and more logical when the kernel always
On 2011-08-01 22:22, Alan Cox wrote:
There are also some interesting security issues with a lot of GPUs where
you'd be very very hard pushed to stop one task spying on the display of
another as there isn't much in the way of MMU contexts on the GPU side.
Alan
But I believe this is a problem of
On 2011-08-02 12:28, Rafał Miłecki wrote:
2011/8/2 Alan Cox:
But I believe this is a problem of all approaches which provide
multiple hardware-accelerated (or Xv-enabled) seats on a single GPU,
no matter if based on multiple DRM devices, on Xephyr or Xnest
with some kind of OpenGL or DRI passthr
On 2011-08-02 12:26, Alan Cox wrote:
Hence, that's no argument against multiple DRM devices on a single card,
because the other solutions suffer from the same problem.
Displaylink USB devices don't have this problem - they have others. Ditto
mulitple graphics cards doesn't.
Multiple single-se
I wonder if a custom window manager wouldn't be enough? Using
multi-pointer and locking each focus group to a given screen, making
sure that no one can interfere with anyone else. If the wm is root it
should be capable of spawning programs of different user privileges on
each screen. Of course that
On 2011-08-02 14:59, Alex Deucher wrote:
On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
wrote:
Hmmm, what's about the opposite approach?
To me, it sounds simpler and more logical when the kernel always creates
one device node per output (or maybe dynamically per connected output),
with
On Die, 2011-08-02 at 13:10 +0200, Prof. Dr. Klaus Kusche wrote:
> On 2011-08-02 12:28, Rafał Miłecki wrote:
> > 2011/8/2 Alan Cox:
> >>> But I believe this is a problem of all approaches which provide
> >>> multiple hardware-accelerated (or Xv-enabled) seats on a single GPU,
> >>> no matter if ba
On Tue, Aug 2, 2011 at 11:28 AM, Prof. Dr. Klaus Kusche
wrote:
> On 2011-08-02 16:34, Alex Deucher wrote:
>>
>> On Tue, Aug 2, 2011 at 10:22 AM, Prof. Dr. Klaus Kusche
>> wrote:
>>>
>>> On 2011-08-02 14:59, Alex Deucher wrote:
On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
On 2011-08-02 16:34, Alex Deucher wrote:
On Tue, Aug 2, 2011 at 10:22 AM, Prof. Dr. Klaus Kusche
wrote:
On 2011-08-02 14:59, Alex Deucher wrote:
On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
wrote:
Hmmm, what's about the opposite approach?
To me, it sounds simpler and more log
On 08/01/2011 10:22 PM, Alan Cox wrote:
> On Mon, 1 Aug 2011 20:47:42 +0100
> Dave Airlie wrote:
>
>>>
>>> Hmmm, what's about the opposite approach?
>>> To me, it sounds simpler and more logical when the kernel always creates
>>> one device node per output (or maybe dynamically per connected outp
https://bugs.freedesktop.org/show_bug.cgi?id=39782
Summary: [r300g] XvMC playback fails with MPEG2 video and RV350
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: me
Alex Deucher gmail.com> writes:
> Some drivers can already do this (the radeon driver at least). google
> for zaphod mode. You basically start one instance of the driver for
> each display controller and then assign which randr outputs are used
> by each instance of the driver. It already work
On 2011-08-02 17:48, Alex Deucher wrote:
On Tue, Aug 2, 2011 at 11:28 AM, Prof. Dr. Klaus Kusche
wrote:
On 2011-08-02 16:34, Alex Deucher wrote:
On Tue, Aug 2, 2011 at 10:22 AM, Prof. Dr. Klaus Kusche
wrote:
On 2011-08-02 14:59, Alex Deucher wrote:
On Mon, Aug 1, 2011 at 3:41 PM, Pro
Hi
On Tuesday 02 August 2011, Matthew Garrett wrote:
> qemu-kvm emulates a Cirrus GPU, including its acceleration engine. We
> typically then run a Cirrus-specific X driver on top of this, which
> turns requests into commands and sends them to the emulated accelerator.
> This all seems to be unnec
https://bugs.freedesktop.org/show_bug.cgi?id=39782
--- Comment #1 from Michel Dänzer 2011-08-02 23:21:47 PDT
---
Does your X driver have commit f59c3b294b0f715fc96e2bbe25893f2b31aa488b
('Register XvMC video decoding acceleration') required for XvMC?
--
Configure bugmail: https://bugs.freedeskt
https://bugzilla.kernel.org/show_bug.cgi?id=39972
--- Comment #4 from Robert Piasek 2011-08-02 07:38:23
---
Hi Alex,
I can bi-select this weekend. I cannot do it earlier I'm afraid as it's my
production workstation.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=emai
> But I believe this is a problem of all approaches which provide
> multiple hardware-accelerated (or Xv-enabled) seats on a single GPU,
> no matter if based on multiple DRM devices, on Xephyr or Xnest
> with some kind of OpenGL or DRI passthrough, or on Wayland:
> If one has direct access to the g
2011/8/2 Alan Cox :
>> But I believe this is a problem of all approaches which provide
>> multiple hardware-accelerated (or Xv-enabled) seats on a single GPU,
>> no matter if based on multiple DRM devices, on Xephyr or Xnest
>> with some kind of OpenGL or DRI passthrough, or on Wayland:
>> If one h
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #13 from Andrew Randrianasulu 2011-08-02
04:06:28 PDT ---
More info.
When I set NVFX_SWTNL=1 ./vertexrate it also works without lockup. I was
playing with amount of vertex data, and found what defining MAX_VERTS up to
1263 works OK
https://bugs.freedesktop.org/show_bug.cgi?id=34969
Andrew Randrianasulu changed:
What|Removed |Added
Attachment #49333|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=34969
Andrew Randrianasulu changed:
What|Removed |Added
Attachment #49334|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=34495
--- Comment #52 from Lars G 2011-08-02 04:40:28 PDT
---
(In reply to comment #51)
> Created an attachment (id=49807)
View: https://bugs.freedesktop.org/attachment.cgi?id=49807
Review: https://bugs.freedesktop.org/review?bug=34495&attachment=49
On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
wrote:
> On 2011-07-31 22:09, Dave Airlie wrote:
>>>
>>> There once was a patch to allow one X server per graphics card
>>> output:
>>> http://www.facebook.com/note.php?note_id=110388492307351
>>> http://people.freedesktop.org/~airlied/multise
https://bugs.freedesktop.org/show_bug.cgi?id=34495
--- Comment #53 from Micael Dias 2011-08-02 06:27:05
PDT ---
Thanks for testing.
I can reproduce the problem with normal blender, subdivs applied and textured
mode. However it doesn't seem related to this patch or Pierre's since even
rotating a
On Tue, Aug 2, 2011 at 10:22 AM, Prof. Dr. Klaus Kusche
wrote:
> On 2011-08-02 14:59, Alex Deucher wrote:
>>
>> On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
>> ?wrote:
>>>
>>> Hmmm, what's about the opposite approach?
>>> To me, it sounds simpler and more logical when the kernel always
On 2011-08-01 22:22, Alan Cox wrote:
> There are also some interesting security issues with a lot of GPUs where
> you'd be very very hard pushed to stop one task spying on the display of
> another as there isn't much in the way of MMU contexts on the GPU side.
>
> Alan
But I believe this is a prob
On 2011-08-02 12:28, Rafa? Mi?ecki wrote:
> 2011/8/2 Alan Cox:
>>> But I believe this is a problem of all approaches which provide
>>> multiple hardware-accelerated (or Xv-enabled) seats on a single GPU,
>>> no matter if based on multiple DRM devices, on Xephyr or Xnest
>>> with some kind of OpenGL
On 2011-08-02 12:26, Alan Cox wrote:
>> Hence, that's no argument against multiple DRM devices on a single card,
>> because the other solutions suffer from the same problem.
>
> Displaylink USB devices don't have this problem - they have others. Ditto
> mulitple graphics cards doesn't.
Multiple si
I wonder if a custom window manager wouldn't be enough? Using
multi-pointer and locking each focus group to a given screen, making
sure that no one can interfere with anyone else. If the wm is root it
should be capable of spawning programs of different user privileges on
each screen. Of course that
On 2011-08-02 14:59, Alex Deucher wrote:
> On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
> wrote:
>> Hmmm, what's about the opposite approach?
>> To me, it sounds simpler and more logical when the kernel always creates
>> one device node per output (or maybe dynamically per connected out
On Die, 2011-08-02 at 13:10 +0200, Prof. Dr. Klaus Kusche wrote:
> On 2011-08-02 12:28, Rafa? Mi?ecki wrote:
> > 2011/8/2 Alan Cox:
> >>> But I believe this is a problem of all approaches which provide
> >>> multiple hardware-accelerated (or Xv-enabled) seats on a single GPU,
> >>> no matter if ba
On Tue, Aug 2, 2011 at 11:28 AM, Prof. Dr. Klaus Kusche
wrote:
> On 2011-08-02 16:34, Alex Deucher wrote:
>>
>> On Tue, Aug 2, 2011 at 10:22 AM, Prof. Dr. Klaus Kusche
>> ?wrote:
>>>
>>> On 2011-08-02 14:59, Alex Deucher wrote:
On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
On 2011-08-02 16:34, Alex Deucher wrote:
> On Tue, Aug 2, 2011 at 10:22 AM, Prof. Dr. Klaus Kusche
> wrote:
>> On 2011-08-02 14:59, Alex Deucher wrote:
>>>
>>> On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
>>> wrote:
Hmmm, what's about the opposite approach?
To me, it
On 08/01/2011 10:22 PM, Alan Cox wrote:
> On Mon, 1 Aug 2011 20:47:42 +0100
> Dave Airlie wrote:
>
>>>
>>> Hmmm, what's about the opposite approach?
>>> To me, it sounds simpler and more logical when the kernel always creates
>>> one device node per output (or maybe dynamically per connected outp
https://bugs.freedesktop.org/show_bug.cgi?id=39782
Summary: [r300g] XvMC playback fails with MPEG2 video and RV350
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: me
Alex Deucher gmail.com> writes:
> Some drivers can already do this (the radeon driver at least). google
> for zaphod mode. You basically start one instance of the driver for
> each display controller and then assign which randr outputs are used
> by each instance of the driver. It already work
On 2011-08-02 17:48, Alex Deucher wrote:
> On Tue, Aug 2, 2011 at 11:28 AM, Prof. Dr. Klaus Kusche
> wrote:
>> On 2011-08-02 16:34, Alex Deucher wrote:
>>>
>>> On Tue, Aug 2, 2011 at 10:22 AM, Prof. Dr. Klaus Kusche
>>> wrote:
On 2011-08-02 14:59, Alex Deucher wrote:
>
> On
Hi
On Tuesday 02 August 2011, Matthew Garrett wrote:
> qemu-kvm emulates a Cirrus GPU, including its acceleration engine. We
> typically then run a Cirrus-specific X driver on top of this, which
> turns requests into commands and sends them to the emulated accelerator.
> This all seems to be unnec
https://bugs.freedesktop.org/show_bug.cgi?id=39782
--- Comment #1 from Michel D?nzer 2011-08-02 23:21:47
PDT ---
Does your X driver have commit f59c3b294b0f715fc96e2bbe25893f2b31aa488b
('Register XvMC video decoding acceleration') required for XvMC?
--
Configure bugmail: https://bugs.freedeskt
48 matches
Mail list logo
