On Wed, May 16, 2012 at 6:36 AM, Miguel Ramos
wrote:
> Hi,
>
> This question is not related to mesa itself, so sorry to use your
> mailing list, however, I know here someone will have the knowledge to
> help me.
> I'm trying to learn something about GPUs and would like to write some
> assembly lan
On Wed, May 16, 2012 at 6:05 PM, Miguel Ramos
wrote:
> 2012/5/16 Alex Deucher :
>> On Wed, May 16, 2012 at 6:36 AM, Miguel Ramos
>> wrote:
>>> Hi,
>>>
>>> This question is not related to mesa itself, so sorry to use your
>>> mailing list, howe
On Thu, Sep 6, 2012 at 7:04 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes corresponding cases in piglit fbo-generatemipmap-formats.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/si_state.c | 14 +++
On Thu, Sep 6, 2012 at 6:55 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
for the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/r600_texture.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
&g
On Thu, Sep 6, 2012 at 10:54 AM, Jerome Glisse wrote:
> On Thu, Sep 6, 2012 at 6:20 AM, Dave Airlie wrote:
>> On Thu, Sep 6, 2012 at 5:21 PM, Philipp Klaus Krause wrote:
>>> On 06.09.2012 07:35, j.gli...@gmail.com wrote:
From: Jerome Glisse
To avoid GPU lockup registers must be e
On Fri, Sep 7, 2012 at 6:27 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
for the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/SIInstructions.td |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
&g
On Mon, Sep 10, 2012 at 12:25 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
For the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/si_state.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On Fri, Sep 14, 2012 at 10:35 AM, Christian König
wrote:
> Gets VDPAUs shaders working again.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/SIInstructions.td |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
&g
For the series:
Reviewed-by: Alex Deucher
On Tue, Sep 18, 2012 at 8:51 PM, Marek Olšák wrote:
> Let's use the shader key describing the state.
> ---
> src/gallium/drivers/r600/r600_pipe.h | 13 +--
> src/gallium/drivers/r600/r600_shad
On Tue, Sep 25, 2012 at 7:46 PM, Marek Olšák wrote:
> This fixes rare graphical corruption.
>
> NOTE: This is a candidate for the stable branches.
> ---
> src/gallium/drivers/r600/evergreen_state.c |4
> src/gallium/drivers/r600/r600.h |1 +
> src/gallium/drivers
On Sun, Sep 30, 2012 at 9:52 AM, Sylvain BERTRAND wrote:
>> + si_pm4_set_reg(pm4, R_02882C_PA_SU_PRIM_FILTER_CNTL, 0);
>
> Should it be better defaulted in the linux module?
It could be added to the kernel, but it's probably more important to
emit the register state in the userspace drivers a
hose parameters.
>
> Prevents piglit regressions with the following fix.
>
> Signed-off-by: Michel Dänzer
for the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/radeonsi_shader.c | 10 ++
> src/gallium/drivers/radeonsi/radeonsi_shader.h |
On Thu, Oct 4, 2012 at 10:53 AM, Tom Stellard wrote:
> On Thu, Oct 04, 2012 at 10:42:45PM +0800, Liu Xin wrote:
>> Hi, Tom,
>>
>> thank you for your instant response. we decide to try clover for r600. it
>> should work on ubuntu(11.10), right?
>> have you refined tgsi compiler for r600?
>>
>
> Bu
On Fri, Oct 5, 2012 at 10:24 AM, Liu Xin wrote:
> Hi, Tom,
>
> thanks for your kind guidance. within a daunting day, we have made clover
> work on our APU platform. for your information, we are running on ubuntu
> 12-04, i386.
>
> out of curiosity, r600 driver relies on the newest llvm API, see l
On Thu, Oct 11, 2012 at 8:12 AM, Andreas Boll
wrote:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/evergreen_state.c | 101
> ++--
> 1 files changed, 7 insertions(+), 94 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergree
tions or ideas or concerns, please let us know.
Thanks,
Alex Deucher
X.Org Foundation Board
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Oct 26, 2012 at 10:01 PM, wrote:
> From: Jerome Glisse
>
> On r6xx/r7xx shader resource management need to make sure that the
> shader does not goes over the gpr register limit. Each specific
> asic has a maxmimum register that can be split btw shader stage.
> For each stage the shader m
Reviewed-by: Alex Deucher
On Mon, Oct 29, 2012 at 8:23 AM, Marek Olšák wrote:
> ---
> src/gallium/drivers/r600/evergreen_state.c | 72
> +++-
> src/gallium/drivers/r600/evergreend.h |1 +
> src/gallium/drivers/r600/r600_stat
on which fixes the problem (e.g. causing broken
> linear fog with radeonsi) at little extra cost (in the form of V_MOV_* from
> SGPR to VGPR).
>
> Signed-off-by: Michel Dänzer
Looks good to me until we figure out a better plan for dealing with
VGPRs vs. SPGRs.
Reviewed-by: Alex Deuche
On Wed, Oct 31, 2012 at 1:11 PM, Patrick Baggett
wrote:
> Hi all,
>
> I've got a really weird duck of system: an Itanium2 system running Linux
> 3.7.0-rc3 with the newest libdrm and mesa git from yesterday. I configured
> it with --enable-texture-float and the radeon DRI driver. When I use
> glxin
o.
Reviewed-by: Alex Deucher
Stable branches?
> ---
> src/gallium/drivers/r600/r600_buffer.c | 42
> ---
> src/gallium/drivers/r600/r600_texture.c |3 ++-
> 2 files changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/src/gallium
Reviewed-by: Alex Deucher
On Wed, Nov 7, 2012 at 11:49 AM, Vincent Lejeune
wrote:
> ---
> src/gallium/drivers/r600/r600_asm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/r600_asm.c
> b/src/gallium/drivers/r600/r600_asm
On Thu, Nov 8, 2012 at 10:28 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
>
> Signed-off-by: Michel Dänzer
For the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/radeonsi_shader.c |7 +++
> 1 file changed, 7 insertions(+)
>
&g
On Sat, Nov 10, 2012 at 10:52 AM, Marek Olšák wrote:
> On Fri, Nov 9, 2012 at 9:44 PM, Jerome Glisse wrote:
>> On Thu, Nov 01, 2012 at 03:13:31AM +0100, Marek Olšák wrote:
>>> On Thu, Nov 1, 2012 at 2:13 AM, Alex Deucher wrote:
>>> > On Wed, Oct 31, 2012
On Mon, Nov 12, 2012 at 6:43 PM, Marek Olšák wrote:
> though I guess the DDX allocates them as LINEAR_GENERAL
At one point I changed the ddx to use LINEAR_ALIGNED, but it might
have gotten changed back at some point. Shouldn't be too hard to fix
up.
Alex
> ---
> src/gallium/drivers/r600/r600_
On Mon, Nov 12, 2012 at 6:43 PM, Marek Olšák wrote:
For the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_texture.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_texture.c
linear_aligned may even be a better fit for 1D textures since we only
care about one dimension.
Reviewed-by: Alex Deucher
On Tue, Nov 13, 2012 at 10:05 AM, Marek Olšák wrote:
> ---
> src/gallium/drivers/r600/r600_texture.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
On Tue, Nov 13, 2012 at 10:13 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes assertion failure with Mesa demo glsl/samplers.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/radeonsi_pm4.h |2 +-
> 1 f
On Wed, Nov 14, 2012 at 6:39 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> lib/Target/AMDGPU/SIInstructions.td |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> dif
On Thu, Nov 15, 2012 at 8:46 AM, Michel Dänzer wrote:
> On Mit, 2012-11-14 at 14:14 -0500, alexdeuc...@gmail.com wrote:
>> From: Alex Deucher
>>
>> Clean up a few magic numbers and rework the code a bit.
>>
>> Signed-off-by: Alex Deucher
>
> Reviewed-by:
On Mon, Aug 16, 2010 at 10:54 AM, Luca Barbieri wrote:
> Regarding OpenCL, it was found that nv50 has the normalization bit in
> the sampler view, while r600 has it in the shader instruction.
>
> Thus, for nv50, the are two options:
> 1. Move the bit from the sampler state to the sampler view -> h
On Mon, Aug 16, 2010 at 12:01 PM, Luca Barbieri wrote:
>> It seems like there is an alternate fix possible -- modify the mesa
>> fixed-function vertex program generator to put these constant values in
>> the constant buffer, rather than passing them as vertex data. That
>> would remove the need f
On Mon, Aug 16, 2010 at 4:53 PM, Luca Barbieri wrote:
>> IIRC, the vertex fetch constants for r6xx+ accept 0 stride.
>
> But does the hardware fetch the same value repeatedly, wasting memory
> bandwidth, or is it smart enough to fetch it once and store it?
> (question applies to both r300-r500 and
On Tue, Aug 17, 2010 at 10:56 AM, Luca Barbieri wrote:
>> I don't see the need for this "any" flag -- if this is an internally
>> generated texture, the state tracker can query the driver, find out what
>> normalization it prefers, and then use that explicitly.
>
> It is for internal textures, whe
On Thu, Sep 16, 2010 at 9:27 AM, Tilman Sauerbeck wrote:
> Commit a508d2dddcc67d0f92cc36b9ed6f36a9bbfc579d removed the type specific
> limit.
>
> Signed-off-by: Tilman Sauerbeck
> ---
>
> I have no idea whether this is actually correct or not. Please review ;)
>
Since the shaders are unified, th
On Fri, Sep 17, 2010 at 6:36 AM, Tilman Sauerbeck wrote:
> Signed-off-by: Tilman Sauerbeck
> ---
>
> The changes to evergreend.h are just a guess. Please review.
The register bitfields for evergreen are in the ddx (and mesa):
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/evergr
On Wed, Sep 22, 2010 at 6:15 AM, Dave Airlie wrote:
> On Wed, Sep 22, 2010 at 7:50 PM, Keith Whitwell
> wrote:
>> On Wed, Sep 22, 2010 at 10:30 AM, Dave Airlie wrote:
>>> So Evergreen hardware appears to have only completely separate depth
>>> and stencil buffers and doesn't natively support a c
On Sat, Sep 25, 2010 at 11:48 AM, wrote:
>
>
> Ok, it seems very few people want to have them in working state from
> developers side of fence. Corbin simply can't boot them, others are busy with
> new radeon/nouveau/intel.
>
> So, first I will list drivers, as far as i understand them, please c
On Thu, Sep 30, 2010 at 1:43 PM, José Fonseca wrote:
> On Thu, 2010-09-30 at 10:19 -0700, Roland Scheidegger wrote:
>> On 30.09.2010 16:44, José Fonseca wrote:
>> > On Thu, 2010-09-30 at 07:32 -0700, Brian Paul wrote:
>> >> On 09/30/2010 12:41 AM, Dave Airlie wrote:
>> >>> some background:
>> >>>
On Sat, Oct 9, 2010 at 4:33 PM, Daniel Vetter wrote:
> By calling radeon_draw_buffers (which sets the necessary flags
> in radeon->NewGLState) and revalidating if NewGLState is non-zero
> in r200TclPrimitive. This fixes an assert in libdrm (the color-/
> depthbuffer was changed but not yet validat
On Sun, Oct 10, 2010 at 11:04 AM, Daniel Vetter wrote:
> By calling radeon_draw_buffers (which sets the necessary flags
> in radeon->NewGLState) and revalidating if NewGLState is non-zero
> in r200TclPrimitive. This fixes an assert in libdrm (the color-/
> depthbuffer was changed but not yet valid
On Tue, Oct 12, 2010 at 11:50 PM, Corbin Simpson
wrote:
> Yes, that particular part of the spec is fairly Poulsboriffic. Does any open
> hardware have a scissor enable/disable bit?
Most hardware can disable/enable cliprects, but not scissors.
Alex
>
> Sending from a mobile, pardon the brevity.
On Tue, Nov 2, 2010 at 3:40 PM, Keith Whitwell wrote:
> These were previously being left in the default (D3D) mode. This mean
> that triangles were drawn slightly incorrectly, but also because this
> state is relied on by the u_blitter code, all blits were half a pixel
> off.
Looks good. Evergr
On Tue, Nov 2, 2010 at 3:40 PM, Keith Whitwell wrote:
> Restore lost hunk in patch 2.
Set looks good to me. See my comment about updating evergreen to
follow the state rasterization rules as well.
Alex
>
> ___
> mesa-dev mailing list
> mesa-dev@lists
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
On Sun, Nov 7, 2010 at 10:09 PM, Mario Kleiner
wrote:
> Alex Deucher is currently preparing patches for page-flipped
> bufferswaps on radeon hardware. Testing these on a RV530 gpu
> with the R300 classic driver exposed a bug - We call
> radeon_prepare_render() too late. This ca
pleteness, but as long as the 3D driver emits the point sprite cntl
properly, I think it should be fine. Are there any cases where it
wouldn't?
Reviewed-by: Alex Deucher
> ---
> src/mesa/drivers/dri/r200/r200_swtcl.c | 7 +++
> src/mesa/drivers/dri/r200/r200_tcl.c | 5 +
On Tue, Nov 9, 2010 at 12:05 PM, Roland Scheidegger wrote:
> On 09.11.2010 17:17, Alex Deucher wrote:
>> On Mon, Nov 8, 2010 at 4:12 PM, Roland Scheidegger
>> wrote:
>>> DD_POINT_SIZE got never set for some time now (as it was set only in ifdefed
>>> out code)
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.
>
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
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
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 t
On Mon, Nov 15, 2010 at 4:57 AM, Keith Whitwell wrote:
> On Mon, 2010-11-15 at 01:32 -0800, Keith Whitwell wrote:
>> On Mon, 2010-11-15 at 01:28 -0800, Keith Whitwell wrote:
>> > On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
>> > > Eric just checked in a test into piglit that tests that th
On Mon, Nov 15, 2010 at 4:41 PM, Tilman Sauerbeck wrote:
> piglit/fbo-readpixels still passes for me.
>
> Signed-off-by: Tilman Sauerbeck
> ---
>
> Please review. And someone please tell me where those 512 and 256 bytes
> are coming from :)
The alignment depends on the type of tiling in use (lin
On Tue, Nov 16, 2010 at 11:35 AM, Keith Whitwell
wrote:
> On Mon, Nov 15, 2010 at 9:46 PM, Alex Deucher wrote:
>> On Mon, Nov 15, 2010 at 4:41 PM, Tilman Sauerbeck
>> wrote:
>>> piglit/fbo-readpixels still passes for me.
>>>
>>> Signed-off-by: Tilma
On Sun, Nov 21, 2010 at 7:29 AM, Joakim Sindholt wrote:
> I use these in st_nine and it's been bugging me for a long time.
FWIW:
http://en.wikipedia.org/wiki/Guard_band_clipping
The guardband clipping regs on r3xx-r5xx are:
VAP_GB_VERT_CLIP_ADJ
VAP_GB_VERT_DISC_ADJ
VAP_GB_HORZ_CLIP_ADJ
VAP_GB_HO
On Sat, Nov 20, 2010 at 8:49 PM, bloboidum wrote:
> Hello Mesa folks,
> Is there any Opengl 3.2 planned in any of the stacks (Mesa Classics,
> Gallium)? Do you have a road map to catch up other vendors upto opengl 4 for
> HWs which support requested features?
It's a work in progess. See the foll
On Sun, Nov 21, 2010 at 9:23 AM, Christian König
wrote:
> Hi everybody,
>
> just wanted to note that I got the first implementation of the XvMC iDCT
> code working. The luma/chroma scaling and clamping still need some work,
> but beside from that the pure matrix multiplication seems to work fine.
2010/11/23 Christian König :
> Am Sonntag, den 21.11.2010, 11:28 -0500 schrieb Alex Deucher:
>> Make sure you are using the latest drm patches. Dave and I fixed a
>> number of bugs in the CS checker in 2.6.37. Also, make sure you have
>> the latest mesa bits. I fixed
On Wed, Nov 24, 2010 at 7:23 AM, Marek Olšák wrote:
> In order to be able to create and render to textures of size 8192x8192
> on r600 and nv50, including 3D textures like 8192x4x4.
Can we bump this to 16k? evergreen and ni chips support 16k surfaces.
Alex
>
> Two new piglit tests have been ad
Looks good to me too. Once you've applied it, I'll bump the driver
limits appropriately for r6xx/7xx/evergreen.
Alex
On Mon, Nov 29, 2010 at 12:00 PM, Marek Olšák wrote:
> FWIW, it looks good to me.
>
> Marek
>
> On Wed, Nov 24, 2010 at 8:18 PM, Brian Paul wrote:
>>
>> On 11/24/2010 12:10 PM,
On Fri, Dec 3, 2010 at 10:30 AM, Jerome Glisse wrote:
> On Fri, Dec 3, 2010 at 7:03 AM, Fabian Bieler wrote:
>> Hello!
>>
>> In R700-family_instruction_set_architecture.pdf
>> pages 3-18 and 9-34 read that pop instructions never jump.
>> The table on page 3-16 however reads that it does jump if t
2010/12/13 Christian König :
> Am Montag, den 13.12.2010, 14:19 -0500 schrieb Jerome Glisse:
>> 2010/12/13 Christian König :
>> > tgsi_helper_copy is used on several occasions to copy a temporary result
>> > into the real destination register to emulate writemasks for OP3 and
>> > reduction operati
On Fri, Dec 17, 2010 at 7:50 PM, Dave Airlie wrote:
>> I think this is subtle enough that it needs some documentation.
>
> I was just initially checking the property idea was okay for everyone,
>
>
> http://cgit.freedesktop.org/~airlied/mesa/log/?h=gallium-color0-write-cbufs
>
> contains 4 patches
On Thu, Jan 6, 2011 at 4:30 PM, Tilman Sauerbeck wrote:
> Signed-off-by: Tilman Sauerbeck
looks good to me. should probably be applied to 7.10 as well.
Reviewed-by: Alex Deucher
Alex
> ---
> src/gallium/drivers/r600/r600_shader.c | 17 +++--
> 1 files changed, 1
ough.
>
> If the patch looks good to you I'd like to see it in the 7.10 release.
Looks good to me.
Reviewed-by: Alex Deucher
Alex
>
> Regards,
> Fredrik
>
>
> ___
> mesa-dev mailing list
> mes
2011/1/8 Christian König :
> Hi,
>
> in the past couple of weeks i tried to optimize the shaders used for the
> iDCT and MC code. Beside optimizing the TGSI code for the shaders i
> optimized the TGSI->R600 code generation in r600g quite a bit:
> * Removed the temporary register use from mos
On Tue, Jan 11, 2011 at 10:01 AM, Alberto Milone
wrote:
> Hi all,
>
> The attached patch adds ARL support in r600c. I followed the code in
> the equivalent commit in r600g:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=98b3f27439ba3a48286ed0d6a4467e5482b41fec
>
> Thanks
On Fri, Jan 7, 2011 at 2:57 AM, Fredrik Höglund wrote:
> On Thursday 16 December 2010, Michel Dänzer wrote:
>> The bigger issue here is that no blit should be necessary in the first
>> place. According to Dave on IRC he implemented this using sampler views
>> at some point, I guess that was probab
On Wed, Jan 12, 2011 at 7:35 AM, Fredrik Höglund wrote:
> On Tuesday 11 January 2011, Alex Deucher wrote:
>> On Fri, Jan 7, 2011 at 2:57 AM, Fredrik Höglund wrote:
>> > On Thursday 16 December 2010, Michel Dänzer wrote:
>> >> The bigger issue here is that no blit sh
On Thu, Jan 13, 2011 at 2:35 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/13/2011 06:51 AM, Stefanos A. wrote:
>> On Thu, 13 Jan 2011 14:18:01 +0200, Corbin Simpson
>> wrote:
>>
>>> 12, 2011 at 3:47 PM, rtfss none wrote:
Hi,
first sorry if no
On Mon, Jan 17, 2011 at 10:00 AM, Corbin Simpson
wrote:
> On Mon, Jan 17, 2011 at 1:11 AM, Dave Airlie wrote:
>>
>> Results: (5231 of 5344 passed, 3 timed out)
>>
>> This was with the latest Intel mesa driver on an Ironlake laptop.
>>
>> However I got a random crash on a previous run, I'm guessin
se review and may be apply.
>
> Thanks,
> Mathias
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
From 06a968cdac7c0e9bc3ab15a182e199ea83458aaa Mon Sep 17
Thanks Tim, I've applied the 2 r600g patches.
Alex
On Mon, Jan 24, 2011 at 10:59 AM, Tim Wiederhake wrote:
> ==5547== Conditional jump or move depends on uninitialised value(s)
> ==5547== at 0x8FE745D: r600_drm_winsys_create (r600_drm.c:86)
> ---
> src/gallium/winsys/r600/drm/r600_drm.c |
2011/1/24 Mathias Fröhlich :
>
> Hi Alex,
>
> On Monday, January 24, 2011 02:08:20 Alex Deucher wrote:
>> It varies based on what crystal is on the card (27 Mhz is the most
>> common, but you also see 100 Mhz, and 14.32 Mhz as well). We'll need
>> a new ra
On Sat, Feb 5, 2011 at 4:35 PM, Carl-Philip Haensch
wrote:
> Hi,
>
> the r600 has capabilities of bicubic texture filtering. But I found no
> constant in mesa that would force bicubic filtering, so I only added a todo
> into the r600 driver to add the case once if I know which mesa constant
> stan
On Thu, Feb 10, 2011 at 9:17 AM, Roland Scheidegger wrote:
> Am 10.02.2011 13:25, schrieb Henri Verbeet:
>> On 10 February 2011 09:47, José Fonseca > Wouldn't it be
>> easier/cleaner if sRGB sampling/rendering support was not
>>> done through formats, but through enable/disable bits in
>>> pipe_sa
I've tested and pushed your patch from IRC.
Thanks!
On Mon, Feb 14, 2011 at 12:07 PM, Fabian Bieler wrote:
> This patch fixes the fbo/fbo-clear-formats piglit test.
>
> As PIPE_FORMAT_B10G10R10A2_UNORM is the only format the mesa state tracker
> uses, this is the only format I actualy tested.
>
On Mon, Feb 21, 2011 at 8:21 PM, Brian Paul wrote:
> On 02/21/2011 05:06 PM, Brian Paul wrote:
>>
>> On 02/21/2011 03:01 PM, Ian Romanick wrote:
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> I'm planning to cherry pick a handful more patches back to the stable
>>> branches this
On Mon, Mar 14, 2011 at 2:18 PM, José Fonseca wrote:
> On Mon, 2011-03-14 at 10:06 -0700, Matt Turner wrote:
>> On Mon, Mar 14, 2011 at 4:52 PM, José Fonseca wrote:
>> > If we want a cleaner / more agile code base, then we could fork off the
>> > old mesa drivers which aren't being actively maint
On Fri, Mar 25, 2011 at 5:44 PM, Matt Turner wrote:
> On Wed, Mar 23, 2011 at 4:28 PM, ★ Emeric wrote:
>> Hi everyone,
>> My name is Emeric, I am a 22 years old french student, and I am
>> currently looking to apply to the google summer of code 2011.
>> I saw the "Gallium H.264 decoding" idea on
On Sat, Mar 26, 2011 at 1:01 PM, Matt Turner wrote:
> On Sat, Mar 26, 2011 at 4:53 PM, Alex Deucher wrote:
>> Plus, on AMD hardware at least, on
>> r1xx-r5xx asics we didn't have UVD so we used the 3D engine for video
>> decode and it worked well, even on mobile asic
On Wed, Apr 13, 2011 at 7:23 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/13/2011 12:27 PM, Eric Anholt wrote:
>> Fixes fbo-drawbuffers-arbfp.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34321
>
> I've been using References: for this lately,
On Tue, Apr 19, 2011 at 4:06 AM, Cédric Cano wrote:
> Hi
>
> Few days ago, I posted a couple of patches on dri-devel but it doesn't seem
> to be the correct place. Here you are 2 patches that adds support for RV730
> in r600c and r600g.
>
I've pushed the r600c patch. I'll take a look at the r600
On Tue, Apr 19, 2011 at 12:11 PM, Alex Deucher wrote:
> On Tue, Apr 19, 2011 at 4:06 AM, Cédric Cano
> wrote:
>> Hi
>>
>> Few days ago, I posted a couple of patches on dri-devel but it doesn't seem
>> to be the correct place. Here you are 2 patches that add
On Tue, Apr 19, 2011 at 1:24 PM, Henri Verbeet wrote:
> On 19 April 2011 18:11, Alex Deucher wrote:
>> I've pushed the r600c patch. I'll take a look at the r600g patch later
>> today.
>>
> I'm without r600 hardware this week, but personally I think I&#x
is code will not be missed.
>
> Right. I believe people eventually figured out that fglrx didn't use
> the fixed-function fog either. It seems likely that it was for the same
> reason. :) Looking at the i915 docs, there a bunch of restrictions and
> weird quirks that loo
On Mon, Apr 12, 2010 at 10:17 AM, Roland Scheidegger wrote:
> What's wrong with the stride zero concept?
> I think most hw can handle this just fine (pretty sure all radeons
> should, though of course driver might need some special case code if it
> uses this to determine max index due to zero div
On Tue, Apr 13, 2010 at 4:23 AM, Luca Barbieri wrote:
> Has Intel or anyone else considered open sourcing their Windows
> DirectX 10 user mode DDI drivers, porting them to Gallium and filling
> in the missing GL-specific functionality from the GL drivers?
AMD considered opening it's at least part
On Tue, Apr 13, 2010 at 6:01 AM, José Fonseca wrote:
> On Tue, 2010-04-13 at 00:55 -0700, Dave Airlie wrote:
>> No offence to gallium, but I don't think its been mature enough to
>> ship a driver for as long as Intel have had to ship drivers. I'm not
>> even sure its mature enough to ship a driver
On Wed, Apr 14, 2010 at 5:05 PM, Brian Paul wrote:
> Moving this to the new mesa-dev list...
>
> Roland Scheidegger wrote:
>>
>> On 14.04.2010 00:38, Dave Airlie wrote:
>>>
>>> On Wed, Apr 14, 2010 at 8:33 AM, Roland Scheidegger
>>> wrote:
&
On Thu, Apr 15, 2010 at 11:17 AM, Roland Scheidegger wrote:
> On 15.04.2010 02:03, Alex Deucher wrote:
>> On Wed, Apr 14, 2010 at 5:05 PM, Brian Paul wrote:
>>> Moving this to the new mesa-dev list...
>>>
>>> Roland Scheidegger wrote:
>>>> On 1
On Wed, Apr 21, 2010 at 5:39 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> http://ati.amd.com/products/RadeonX1650/x1650xt_specs.html
> http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processing_Units
>
> Signed-off-by: Tormod Volden
> ---
>
> I do not have the hardware to confirm t
On Thu, Apr 22, 2010 at 1:48 AM, Alex Deucher wrote:
> On Wed, Apr 21, 2010 at 5:39 PM, Tormod Volden wrote:
>> From: Tormod Volden
>>
>> http://ati.amd.com/products/RadeonX1650/x1650xt_specs.html
>> http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processin
On Thu, Apr 22, 2010 at 3:52 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> Although these cards have 2 pipelines on the silicon only
> the first passed the QA and the other should be disabled.
>
> http://www.digital-daily.com/video/ati-radeon9800se/
> http://www.rojakpot.com/showarticle.aspx
On Thu, Apr 22, 2010 at 3:52 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> Although these cards have 2 pipelines on the silicon only
> the first passed the QA and the other should be disabled.
>
> http://www.digital-daily.com/video/ati-radeon9800se/
> http://www.rojakpot.com/showarticle.aspx
On Thu, Apr 22, 2010 at 4:40 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> These should also be in the newest linux kernels.
>
> Signed-off-by: Tormod Volden
gallium and classic with kms get this number form the drm and can't
program the relevant regs, so the drm patch is required for gall
On Sat, Apr 24, 2010 at 8:01 AM, Marek Olšák wrote:
> On Tue, Apr 20, 2010 at 10:31 AM, Jerome Glisse
> wrote:
>>
>> As r300g has never been used as a production driver AFAIK i think
>> we could simply say that once it becomes such it will need at least
>> 2.6.34 kernel and thus avoid any fallbac
On Fri, Apr 30, 2010 at 12:59 AM, Dave Airlie wrote:
>> Alex Deucher 2 0
> - pci ids
My development pattern also favors work on master with cherry-picks to
stable. Usually I notice bugs when working on new code, then have to
go back and apply to stable. I
eases with this development cycle and from what I can see all the
> developers are still developing on master.
>
>
>>>
>>>> Author Signed- off-by
>>>> Brian Paul 20 18
>>> Lots of gallium and me
701 - 800 of 819 matches
Mail list logo
