> Note if it is known that x and y are less than or equal to 7 it can be
> done in 11 operations.
And bsr is one instruction for x86, cntlzw for ppc
Alan
Hi,
Attached is a change to the radeon reloc emitting code, that stores the reloc
index in the buffer object. This avoids quadratic runtime behavior in the
number of emitted buffer object relocs per command stream.
The reloc index is held in an array indexed by command stream number, which
mea
https://bugs.freedesktop.org/show_bug.cgi?id=28284
--- Comment #4 from Will Dyson 2010-05-27 21:56:22 PDT
---
Created an attachment (id=35898)
View: https://bugs.freedesktop.org/attachment.cgi?id=35898
Review: https://bugs.freedesktop.org/review?bug=28284&attachment=35898
Alternate patch for
https://bugs.freedesktop.org/show_bug.cgi?id=28284
--- Comment #4 from Will Dyson 2010-05-27 21:56:22
PDT ---
Created an attachment (id=35898)
View: https://bugs.freedesktop.org/attachment.cgi?id=35898
Review: https://bugs.freedesktop.org/review?bug=28284&attachment=35898
Alternate patch for
https://bugs.freedesktop.org/show_bug.cgi?id=28284
--- Comment #3 from Will Dyson 2010-05-27 21:53:52 PDT
---
(In reply to comment #2)
> (In reply to comment #1)
> > Is this a recent regression? If so, can you bisect it? I suspect one of
> > the
> > recent mipmap patches if so.
>
> My (admit
https://bugs.freedesktop.org/show_bug.cgi?id=28284
--- Comment #3 from Will Dyson 2010-05-27 21:53:52
PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > Is this a recent regression? If so, can you bisect it? I suspect one of
> > the
> > recent mipmap patches if so.
>
> My (admit
On Thu, May 27, 2010 at 7:52 PM, Alan Cox wrote:
>> Look up tables have some hidden penalties but I think it might be a
>> win. Looks like we may have to benchmark the solutions against one
>> another to really know which is best in real life.
>
> For x86 and ppc the single assembler instruction i
On Thu, May 27, 2010 at 7:52 PM, Alan Cox wrote:
>> Look up tables have some hidden penalties but I think it might be a
>> win. Looks like we may have to benchmark the solutions against one
>> another to really know which is best in real life.
>
> For x86 and ppc the single assembler instruction i
- This enables voltage adjustment on r6xx+ and certain
r5xx asics.
- Voltage drop support is already available for most
r1xx-r5xx asics.
V2: endian fix for voltage table.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c|6 +
drivers/gpu/drm/radeon/radeon.h
0x46c266f0 0x46c42578 Yes (*) /usr/lib/libpng12.so.0
0x47c162d0 0x47c306b8 Yes (*) /usr/lib/libjpeg.so.62
0x46da7740 0x46db14b8 Yes (*) /usr/lib/libXi.so.6
0x46aea720 0x46af4ff8 Yes (*) /usr/lib/libXext.so.6
0x4686a620 0x468758e8 Yes (*) /lib/libz.so.1
0x4a84fe00 0x4a
Fixes:
drivers/gpu/drm/radeon/atombios_crtc.c: In function ???atombios_crtc_set_pll???:
drivers/gpu/drm/radeon/atombios_crtc.c:678: error: ???pll??? may be used
uninitialized in this function
Signed-off-by: Prarit Bhargava
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/
Seems like a good simplification.
Reviewed-by: Matt Turner
On Thu, May 27, 2010 at 7:52 PM, Alan Cox wrote:
>> Look up tables have some hidden penalties but I think it might be a
>> win. Looks like we may have to benchmark the solutions against one
>> another to really know which is best in real life.
>
> For x86 and ppc the single assembler instruction i
- This enables voltage adjustment on r6xx+ and certain
r5xx asics.
- Voltage drop support is already available for most
r1xx-r5xx asics.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c|6 +
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeo
- Enable GPIO voltage for non pm modes as well so resetting
the default voltage works.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c |9 ++---
drivers/gpu/drm/radeon/radeon_combios.c |7 ++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git
- wait for vbl for both profile and dynpm
- unify profile and dynpm code paths more
- call pm_misc before of after clocks to make
sure voltage is changed in the proper order.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 75 ---
1 files ch
The default power state does not always match the default clocks and voltage
for a particular card. The information in the firmware info table is correct
and should be used in preference to the info the default power state.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.
On Thu, May 27, 2010 at 7:52 PM, Alan Cox wrote:
>> Look up tables have some hidden penalties but I think it might be a
>> win. Looks like we may have to benchmark the solutions against one
>> another to really know which is best in real life.
>
> For x86 and ppc the single assembler instruction i
> Look up tables have some hidden penalties but I think it might be a
> win. Looks like we may have to benchmark the solutions against one
> another to really know which is best in real life.
For x86 and ppc the single assembler instruction is fastest. Can you wire
an R600 to anything else ?
_
On Thu, 27 May 2010 11:20:59 -0400
Alex Deucher wrote:
> On Thu, May 27, 2010 at 10:55 AM, Matt Turner wrote:
> >> +static inline GLint r600_log2(GLint n)
> >> +{
> >> + ? ? ? GLint log2 = 0;
> >> +
> >> + ? ? ? while (n >>= 1)
> >> + ? ? ? ? ? ? ? ++log2;
> >> + ? ? ? return log2;
> >> +}
> >
>
On Thu, May 27, 2010 at 4:01 PM, Frieder Ferlemann
wrote:
> Hi,
>
> Am 28.05.2010 00:04, schrieb Conn Clark:
>> On Thu, May 27, 2010 at 8:51 AM, Brian Paul wrote:
>>
>> This code could be written with a faster algorithm requiring just 13
>> operations
>>
>> + pixel_number |= ((x >
On Thu, May 27, 2010 at 4:01 PM, Frieder Ferlemann
wrote:
> Hi,
>
> Am 28.05.2010 00:04, schrieb Conn Clark:
>> On Thu, May 27, 2010 at 8:51 AM, Brian Paul wrote:
>>
>> This code could be written with a faster algorithm requiring ?just 13
>> operations
>>
>> + ? ? ? ? ? ? ? pixel_number |= ((x >
- This enables voltage adjustment on r6xx+ and certain
r5xx asics.
- Voltage drop support is already available for most
r1xx-r5xx asics.
V2: endian fix for voltage table.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c|6 +
drivers/gpu/drm/radeon/radeon.h
Hi,
Am 28.05.2010 00:04, schrieb Conn Clark:
> On Thu, May 27, 2010 at 8:51 AM, Brian Paul wrote:
>
> This code could be written with a faster algorithm requiring just 13
> operations
>
> + pixel_number |= ((x >> 0) & 1) << 0; // pn[0] = x[0]
> + pixel_number |= ((
> Note if it is known that x and y are less than or equal to 7 it can be
> done in 11 operations.
And bsr is one instruction for x86, cntlzw for ppc
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/lis
Fixes:
drivers/gpu/drm/radeon/atombios_crtc.c: In function âatombios_crtc_set_pllâ:
drivers/gpu/drm/radeon/atombios_crtc.c:678: error: âpllâ may be used
uninitialized in this function
Signed-off-by: Prarit Bhargava
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/
https://bugs.freedesktop.org/show_bug.cgi?id=28284
--- Comment #2 from Chris Rankin 2010-05-27 15:12:52
PDT ---
(In reply to comment #1)
> Is this a recent regression? If so, can you bisect it? I suspect one of the
> recent mipmap patches if so.
My (admitted limited) git-fu says:
a9ee9565113
https://bugs.freedesktop.org/show_bug.cgi?id=28284
--- Comment #2 from Chris Rankin 2010-05-27
15:12:52 PDT ---
(In reply to comment #1)
> Is this a recent regression? If so, can you bisect it? I suspect one of the
> recent mipmap patches if so.
My (admitted limited) git-fu says:
a9ee9565113
On Thu, May 27, 2010 at 8:51 AM, Brian Paul wrote:
> Alex Deucher wrote:
>>
>> On Thu, May 27, 2010 at 10:55 AM, Matt Turner wrote:
+static inline GLint r600_log2(GLint n)
+{
+ GLint log2 = 0;
+
+ while (n >>= 1)
+ ++log2;
+
On Thu, May 27, 2010 at 8:51 AM, Brian Paul wrote:
> Alex Deucher wrote:
>>
>> On Thu, May 27, 2010 at 10:55 AM, Matt Turner wrote:
+static inline GLint r600_log2(GLint n)
+{
+ ? ? ? GLint log2 = 0;
+
+ ? ? ? while (n >>= 1)
+ ? ? ? ? ? ? ? ++log2;
+ ? ? ?
Seems like a good simplification.
Reviewed-by: Matt Turner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Ping!
On 04/28/2010 11:33 AM, Thomas Hellstrom wrote:
> The first patch removes some leftover debug messages in the ttm_lock code
> so far only used by the vmwgfx driver.
>
> The second patch removes the ttm_bo_block_reservation() function, since
> it is buggy. A bo shouldn't be reserved while rem
- This enables voltage adjustment on r6xx+ and certain
r5xx asics.
- Voltage drop support is already available for most
r1xx-r5xx asics.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c|6 +
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeo
- Enable GPIO voltage for non pm modes as well so resetting
the default voltage works.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c |9 ++---
drivers/gpu/drm/radeon/radeon_combios.c |7 ++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git
- wait for vbl for both profile and dynpm
- unify profile and dynpm code paths more
- call pm_misc before of after clocks to make
sure voltage is changed in the proper order.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 75 ---
1 files ch
The default power state does not always match the default clocks and voltage
for a particular card. The information in the firmware info table is correct
and should be used in preference to the info the default power state.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.
From: Jordan Crouse
The pgoff option in mmap() is defined as an unsigned long
so the offset generated by DRM needs to fit into
BITS_PER_LONG for the CPU in question.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_gem.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
From: Jordan Crouse
Add __arm defines to specify behavior specific for
an ARM processor.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_bufs.c |2 +-
drivers/gpu/drm/drm_vm.c | 14 +-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_
From: Jordan Crouse
Allow platform devices without PCI resources to be DRM devices.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/Kconfig |4 +-
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/drm_drv.c | 37 +---
drivers/gpu/drm/drm_edid
From: Jordan Crouse
Remove the drm_resource wrappers and directly use the
actual PCI and/or platform functions in their place.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_bufs.c| 13 -
drivers/gpu/drm/i915/i915_dma.c |6 +++---
drivers/gpu/d
Here is the second revision implementing platform device
support for DRM. I've split the original patch into three
and applied most of the comments I got from the previous
go-around. The first patch removes the resource wrappers from
DRM and switches the drivers to use the bus level functions.
Th
Fixes:
drivers/gpu/drm/i915/i915_dma.c: In function ???i915_setup_compression???:
drivers/gpu/drm/i915/i915_dma.c:1311: error: ???compressed_llb??? may be used
uninitialized in this function
Signed-off-by: Prarit Bhargava
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915
On Thu, 2010-05-27 at 14:14 +0200, Thomas Hellstrom wrote:
> Ping!
>
Ack!
Should have been in 2.6.34.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=28284
--- Comment #1 from Alex Deucher 2010-05-27 13:10:44 PDT ---
Is this a recent regression? If so, can you bisect it? I suspect one of the
recent mipmap patches if so.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=28284
--- Comment #1 from Alex Deucher 2010-05-27 13:10:44 PDT
---
Is this a recent regression? If so, can you bisect it? I suspect one of the
recent mipmap patches if so.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=28284
Summary: [r300, r600] celestia core dumps - Assertion
`dstRowStride' failed.
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=28284
Summary: [r300, r600] celestia core dumps - Assertion
`dstRowStride' failed.
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
From: Jordan Crouse
Allow platform devices without PCI resources to be DRM devices.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/Kconfig |4 +-
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/drm_drv.c | 37 +---
drivers/gpu/drm/drm_edid
From: Jordan Crouse
Add __arm defines to specify behavior specific for
an ARM processor.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_bufs.c |2 +-
drivers/gpu/drm/drm_vm.c | 14 +-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_
Here is the second revision implementing platform device
support for DRM. I've split the original patch into three
and applied most of the comments I got from the previous
go-around. The first patch removes the resource wrappers from
DRM and switches the drivers to use the bus level functions.
Th
From: Jordan Crouse
Remove the drm_resource wrappers and directly use the
actual PCI and/or platform functions in their place.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_bufs.c| 13 -
drivers/gpu/drm/i915/i915_dma.c |6 +++---
drivers/gpu/d
From: Jordan Crouse
The pgoff option in mmap() is defined as an unsigned long
so the offset generated by DRM needs to fit into
BITS_PER_LONG for the CPU in question.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_gem.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
>
> Prarit Bhargava wrote:
>
>> Fixes warning:
>>
>> /usr/include/drm/i915_drm.h:119: found __[us]{8,16,32,64} type without
>> #include
>>
>> Signed-off-by: Prarit Bhargava
>>
>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> index b64a8d7..5cf7f5b 100644
>> --- a/include/drm/
Fixes warning:
/usr/include/drm/i915_drm.h:119: found __[us]{8,16,32,64} type without #include
Signed-off-by: Prarit Bhargava
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index b64a8d7..5cf7f5b 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -27,6 +27,7 @@
On Thu, May 27, 2010 at 10:55 AM, Matt Turner wrote:
>> +static inline GLint r600_log2(GLint n)
>> +{
>> + ? ? ? GLint log2 = 0;
>> +
>> + ? ? ? while (n >>= 1)
>> + ? ? ? ? ? ? ? ++log2;
>> + ? ? ? return log2;
>> +}
>
> Does mesa not provide something like this?
The only one I could find was a
On Die, 2010-05-25 at 19:09 -0400, Alex Deucher wrote:
>
> Also, on r6xx/r7xx, we don't enable tiling of the front buffer as
> that would require the use of wfb or tiled to untiled blits for CPU
> access. Tiled to untiled blits works (I've tested it), but shows an
> approximately 40% performance
2010/5/27 Michel D?nzer :
> On Die, 2010-05-25 at 19:09 -0400, Alex Deucher wrote:
>>
>> Also, on r6xx/r7xx, we don't enable tiling of the front buffer as
>> that would require the use of wfb or tiled to untiled blits for CPU
>> access. Tiled to untiled blits works (I've tested it), but shows an
>>
> +static inline GLint r600_log2(GLint n)
> +{
> + ? ? ? GLint log2 = 0;
> +
> + ? ? ? while (n >>= 1)
> + ? ? ? ? ? ? ? ++log2;
> + ? ? ? return log2;
> +}
Does mesa not provide something like this?
Matt
Fixes:
drivers/gpu/drm/i915/i915_dma.c: In function âi915_setup_compressionâ:
drivers/gpu/drm/i915/i915_dma.c:1311: error: âcompressed_llbâ may be used
uninitialized in this function
Signed-off-by: Prarit Bhargava
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915
Hi Alex,
not tested (admittedly I haven't compiled it),
and probably not really relevant but these
switch cases could be more compact:
+static inline GLint r600_2d_tile_helper(const struct radeon_renderbuffer * rrb,
+GLint x, GLint y, GLint is_depth, GLint is_stencil)
...
+
Alex Deucher wrote:
> On Thu, May 27, 2010 at 10:55 AM, Matt Turner wrote:
>>> +static inline GLint r600_log2(GLint n)
>>> +{
>>> + GLint log2 = 0;
>>> +
>>> + while (n >>= 1)
>>> + ++log2;
>>> + return log2;
>>> +}
>> Does mesa not provide something like this?
>
>
Alex Deucher wrote:
On Thu, May 27, 2010 at 10:55 AM, Matt Turner wrote:
+static inline GLint r600_log2(GLint n)
+{
+ GLint log2 = 0;
+
+ while (n >>= 1)
+ ++log2;
+ return log2;
+}
Does mesa not provide something like this?
The only one I could find was a gal
Prarit Bhargava wrote:
Fixes warning:
/usr/include/drm/i915_drm.h:119: found __[us]{8,16,32,64} type without
#include
Signed-off-by: Prarit Bhargava
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index b64a8d7..5cf7f5b 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i
Prarit Bhargava wrote:
> Fixes warning:
>
> /usr/include/drm/i915_drm.h:119: found __[us]{8,16,32,64} type without
> #include
>
> Signed-off-by: Prarit Bhargava
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index b64a8d7..5cf7f5b 100644
> --- a/include/drm/i915_drm.h
> ++
On Thu, 27 May 2010 11:20:59 -0400
Alex Deucher wrote:
> On Thu, May 27, 2010 at 10:55 AM, Matt Turner wrote:
> >> +static inline GLint r600_log2(GLint n)
> >> +{
> >> + GLint log2 = 0;
> >> +
> >> + while (n >>= 1)
> >> + ++log2;
> >> + return log2;
> >> +}
> >
>
Prarit Bhargava wrote:
> Fixes warning:
>
> /usr/include/drm/i915_drm.h:119: found __[us]{8,16,32,64} type without
> #include
>
> Signed-off-by: Prarit Bhargava
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index b64a8d7..5cf7f5b 100644
> --- a/include/drm/i915_drm.h
> ++
Fixes warning:
/usr/include/drm/i915_drm.h:119: found __[us]{8,16,32,64} type without #include
Signed-off-by: Prarit Bhargava
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index b64a8d7..5cf7f5b 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -27,6 +27,7 @@
On Thu, May 27, 2010 at 10:55 AM, Matt Turner wrote:
>> +static inline GLint r600_log2(GLint n)
>> +{
>> + GLint log2 = 0;
>> +
>> + while (n >>= 1)
>> + ++log2;
>> + return log2;
>> +}
>
> Does mesa not provide something like this?
The only one I could find was a
2010/5/27 Michel Dänzer :
> On Die, 2010-05-25 at 19:09 -0400, Alex Deucher wrote:
>>
>> Also, on r6xx/r7xx, we don't enable tiling of the front buffer as
>> that would require the use of wfb or tiled to untiled blits for CPU
>> access. Tiled to untiled blits works (I've tested it), but shows an
>>
> +static inline GLint r600_log2(GLint n)
> +{
> + GLint log2 = 0;
> +
> + while (n >>= 1)
> + ++log2;
> + return log2;
> +}
Does mesa not provide something like this?
Matt
___
dri-devel mailing list
dri-devel@lists.freed
Ping!
On 04/28/2010 11:33 AM, Thomas Hellstrom wrote:
The first patch removes some leftover debug messages in the ttm_lock code
so far only used by the vmwgfx driver.
The second patch removes the ttm_bo_block_reservation() function, since
it is buggy. A bo shouldn't be reserved while remaining
On Die, 2010-05-25 at 19:09 -0400, Alex Deucher wrote:
>
> Also, on r6xx/r7xx, we don't enable tiling of the front buffer as
> that would require the use of wfb or tiled to untiled blits for CPU
> access. Tiled to untiled blits works (I've tested it), but shows an
> approximately 40% performance
Hi Alex,
not tested (admittedly I haven't compiled it),
and probably not really relevant but these
switch cases could be more compact:
+static inline GLint r600_2d_tile_helper(const struct radeon_renderbuffer * rrb,
+GLint x, GLint y, GLint is_depth, GLint is_stencil)
...
+
73 matches
Mail list logo
