Am Freitag, den 12.11.2010, 10:11 -0500 schrieb Younes Manton:
> 2010/11/12 Christian König :
> > What I need for both the ycrcb texture and vertex uploads is a buffer in
> > system memory, where the cpu access is fast and a function to tell the
> > gpu to upload this buffer to vram, so the cpu doe
2010/11/12 Christian König :
> Am Freitag, den 12.11.2010, 12:48 -0500 schrieb Alex Deucher:
>> 2010/11/12 Christian König :
>> > Hi Alex,
>> >
>> > by the way I am playing around with iDCT and while doing so I have tried
>> > to allocate an 8x8 texture through r600g, resulting in this error
>> > m
Am Freitag, den 12.11.2010, 12:48 -0500 schrieb Alex Deucher:
> 2010/11/12 Christian König :
> > Hi Alex,
> >
> > by the way I am playing around with iDCT and while doing so I have tried
> > to allocate an 8x8 texture through r600g, resulting in this error
> > message:
> > radeon :01:00.0: text
2010/11/12 Christian König :
> Hi Alex,
>
> by the way I am playing around with iDCT and while doing so I have tried
> to allocate an 8x8 texture through r600g, resulting in this error
> message:
> radeon :01:00.0: texture bo too small (64 1024 2 0 -> 8126464 have
> 4194304)
>
> Google shows up
Hi Alex,
by the way I am playing around with iDCT and while doing so I have tried
to allocate an 8x8 texture through r600g, resulting in this error
message:
radeon :01:00.0: texture bo too small (64 1024 2 0 -> 8126464 have
4194304)
Google shows up an patch with your name in it, do I need a k
2010/11/12 Younes Manton :
> 2010/11/12 Christian König :
>> What I need for both the ycrcb texture and vertex uploads is a buffer in
>> system memory, where the cpu access is fast and a function to tell the
>> gpu to upload this buffer to vram, so the cpu doesn't need to pump the
>> data over the
2010/11/12 Christian König :
> What I need for both the ycrcb texture and vertex uploads is a buffer in
> system memory, where the cpu access is fast and a function to tell the
> gpu to upload this buffer to vram, so the cpu doesn't need to pump the
> data over the system bus, wait for an "in use"
Am Donnerstag, den 11.11.2010, 17:59 -0500 schrieb Jerome Glisse:
> I am not sure on how gallium texture upload was ever supposed to be or
> done, but from memory management point of view the idea i had was to
> create all bo in GTT and let migrate them to VRAM once they are use,
> eliminating any
On Thu, 2010-11-11 at 14:59 -0800, Jerome Glisse wrote:
> 2010/11/11 Keith Whitwell :
> > There is still more to do there. Currently r600g treats buffer and texture
> > uploads separately, and I've only attempted to improve texture uploads.
> > Buffer is just as important however.
> >
> > The c
Christian König wrote:
I figured out an usable workaround for motion_vertical_field_selection
and now even field based mc looks 99% correct, only some minor colored
artefacts left in your Pendulum.mpg test video. If you like you could
test some other interlaced videos now.
It's certainly bette
This. I thought that, to trigger uploads, we just had to change the domain
on the buffer.
Sending from a mobile, pardon the brevity. ~ C.
On Nov 11, 2010 3:00 PM, "Jerome Glisse" wrote:
> 2010/11/11 Keith Whitwell :
>> There is still more to do there. Currently r600g treats buffer and
texture u
2010/11/11 Keith Whitwell :
> There is still more to do there. Currently r600g treats buffer and texture
> uploads separately, and I've only attempted to improve texture uploads.
> Buffer is just as important however.
>
> The change needed is likely to be one of two:
> a) Allow newly created ve
sa-dev-bounces+keithw=vmware@lists.freedesktop.org
> [mesa-dev-bounces+keithw=vmware@lists.freedesktop.org] On Behalf Of Alex
> Deucher [alexdeuc...@gmail.com]
> Sent: Thursday, November 11, 2010 3:25 PM
> To: Christian König
> Cc: mesa-dev@lists.freedesktop.org
> Subject: R
x
Deucher [alexdeuc...@gmail.com]
Sent: Thursday, November 11, 2010 3:25 PM
To: Christian König
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] Status update of XvMC on R600
2010/11/11 Christian König :
> Am Mittwoch, den 10.11.2010, 15:30 -0500 schrieb Younes Manton:
>> In the meantime
2010/11/11 Christian König :
> Am Mittwoch, den 10.11.2010, 15:30 -0500 schrieb Younes Manton:
>> In the meantime, I suggest you check if your vertex buffers are in
>> sytem memory (preferably at least WC-ed if not cached); I don't recall
>> spending that much time in gen_block_verts in Nouveau.
>
Am Mittwoch, den 10.11.2010, 15:30 -0500 schrieb Younes Manton:
> In the meantime, I suggest you check if your vertex buffers are in
> sytem memory (preferably at least WC-ed if not cached); I don't recall
> spending that much time in gen_block_verts in Nouveau.
Looks like your suspicions about th
Am Mittwoch, den 10.11.2010, 14:11 -0700 schrieb Brian Paul:
> Here's an idea. I may be totally off base (this is off the top of my
> head) but suppose the interlaced texture is:
>
> A B C D (even line)
> e f g h (odd line)
> I J K L (even line)
> m n o p (odd line)
>
> Couldn't you lie to
Am Mittwoch, den 10.11.2010, 15:30 -0500 schrieb Younes Manton:
> Keep in mind that the XvMC interface makes no guarantees about the
> order in which macroblocks are submitted. Also, we're already sorting
> macroblocks by I/P/B type in order to batch draw calls. Otherwise it
> would be possible to
On 11/10/2010 12:31 PM, Christian König wrote:
Am Mittwoch, den 10.11.2010, 17:24 +0100 schrieb Roland Scheidegger:
On 10.11.2010 15:56, Christian König wrote:
Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
Looking (for the first time) at iso13818-2 I think the chroma handling
wo
On 10.11.2010 20:31, Christian König wrote:
> Am Mittwoch, den 10.11.2010, 17:24 +0100 schrieb Roland Scheidegger:
>> On 10.11.2010 15:56, Christian König wrote:
>>> Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
Looking (for the first time) at iso13818-2 I think the chroma handl
On Wed, Nov 10, 2010 at 9:56 AM, Christian König
wrote:
> I also started to profile the performance of the code a bit, as expected
> we spend far to much time deciding of how and where to draw something
> compared to really drawing something. Up to 50% of the whole cpu time is
> spend in gen_block
On Wed, Nov 10, 2010 at 3:56 PM, Christian König wrote:
> Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
> > Looking (for the first time) at iso13818-2 I think the chroma handling
> > would be part of display rather than decode, though the iso does specify
> > how chroma is laid out
Am Mittwoch, den 10.11.2010, 17:24 +0100 schrieb Roland Scheidegger:
> On 10.11.2010 15:56, Christian König wrote:
> > Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
> >> Looking (for the first time) at iso13818-2 I think the chroma handling
> >> would be part of display rather than
On 10.11.2010 15:56, Christian König wrote:
> Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
>> Looking (for the first time) at iso13818-2 I think the chroma handling
>> would be part of display rather than decode, though the iso does specify
>> how chroma is laid out for fields in
Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
> Looking (for the first time) at iso13818-2 I think the chroma handling
> would be part of display rather than decode, though the iso does specify
> how chroma is laid out for fields in 6.1.1.8.
>
> An article that describes the issue
Christian König wrote:
We currently only support 4:2:0 and deinterlace the luma channel very
early when copying to video buffers and to be honest, I have no idea how
interlacing is handled on chroma channels when there is only one chroma
value per four result pixels. I have read the section in t
Hi Christian
You have to ask jrch2k10 about that. He is the one working on an IDCT
implementation within the video pipe.
I am/were looking at a vaapi backend. Right now I am busy moving to USA,
where I am going to study for the next 7 month. So the vaapi might hold
still for a while, though I don
Am Samstag, den 06.11.2010, 22:55 + schrieb Andy Furniss:
> Testing interlaced on 600g, I notice that (like most -vo) chroma is
> getting treated as progressive when displayed as weaved, so the "teeth"
> may look twice as bad on saturated colours.
>
> Maybe this is already on your radar, jus
Christian König wrote:
Hi guys,
just wanted to give a little status update for the xvmc state tracker
for r600 hardware. I think I found most of the bugs related to
progressive video playback and it now seems to work 100%.
All the old compliance progressive streams (ones ending 015.m2v, > 015
Christian König wrote:
Hi guys,
just wanted to give a little status update for the xvmc state tracker
for r600 hardware. I think I found most of the bugs related to
progressive video playback and it now seems to work 100%. I also started
to implement interlaced video support, which already looks
On Sat, Nov 6, 2010 at 12:30 PM, Christian König
wrote:
> Hi guys,
>
> just wanted to give a little status update for the xvmc state tracker
> for r600 hardware. I think I found most of the bugs related to
> progressive video playback and it now seems to work 100%. I also started
> to implement in
Hi guys,
just wanted to give a little status update for the xvmc state tracker
for r600 hardware. I think I found most of the bugs related to
progressive video playback and it now seems to work 100%. I also started
to implement interlaced video support, which already looks quite good at
the moment
32 matches
Mail list logo
