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)
...
+
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
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
> +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
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
>>
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
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, 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
> ++
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
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
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
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
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
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
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
--- 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
-
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
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.
- 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
- 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
- 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
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
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;
+
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
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/
> 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
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 |= ((
- 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
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 >
> 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, 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
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 #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
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
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)
...
+
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
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
> +static inline GLint r600_log2(GLint n)
> +{
> + ? ? ? GLint log2 = 0;
> +
> + ? ? ? while (n >>= 1)
> + ? ? ? ? ? ? ? ++log2;
> + ? ? ? return log2;
> +}
Does mesa not provide something like this?
Matt
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
>>
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
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, 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
> ++
>
> 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/
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?
>
>
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
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
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
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
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
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
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
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.
- 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
- 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
- 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
Seems like a good simplification.
Reviewed-by: Matt Turner
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;
+ ? ? ?
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
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/
> 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
- 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
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 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
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 #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
73 matches
Mail list logo
