On Fri, Jul 20, 2012 at 5:09 AM, Julien Cristau wrote:
> From: Julien Cristau
>
> Doing
> size = reply.length * 4;
> [...]
> extra = 4 - (size & 3);
>
> is useless, size & 3 will always be 0.
>
> Signed-off-by: Julien Cristau
Review
On Wed, Jul 25, 2012 at 1:58 PM, Christian König
wrote:
> Also split it into seperate header and add
> some helper functions.
>
> Signed-off-by: Christian König
For the series:
Reviewed-by: Alex Deucher
___
mesa-dev mailing l
re when I'll have a chance
to pop in an r100 or r200. Maybe the user on bug 47375
(http://bugs.freedesktop.org/show_bug.cgi?id=47375) could test.
Reviewed-by: Alex Deucher
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists
On Fri, Aug 3, 2012 at 11:06 AM, Christian König
wrote:
> Fix a stupid typo that could lead to memory
> leaks and/or segfaults.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/radeonsi_pm4.c |2 +-
> 1 file chang
On Mon, Aug 6, 2012 at 12:14 PM, Christian König
wrote:
> Move releasing the VM area after closing the bo handle.
Maybe reference the bugzilla in the commit message?
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> src/gallium/winsys/radeon/drm/radeon_
On Mon, Aug 6, 2012 at 1:12 PM, Jason Wood wrote:
> Add OpenGL 4.3 requirements.
>
> Signed-off-by: Jason Wood
>
> --- a/docs/GL3.txt 2012-08-06 10:49:10.185597917 -0600
> +++ b/docs/GL3.txt 2012-08-06 10:48:45.809477043 -0600
> @@ -130,5 +130,35 @@
> GL_ARB_map_buffer_alignment
On Mon, Aug 6, 2012 at 12:43 AM, Benoit Jacob wrote:
> Hi,
>
> Just so you know: the WebGL 1.0.1 tests are now passing on 2 drivers on
> Linux: the Intel Mesa driver, and the NVIDIA driver.
>
> Technically that's enough for us to claim conformance (we need to pass with 2
> drivers on each OS we
On Mon, Aug 6, 2012 at 5:14 PM, Alex Deucher wrote:
> On Mon, Aug 6, 2012 at 12:43 AM, Benoit Jacob wrote:
>> Hi,
>>
>> Just so you know: the WebGL 1.0.1 tests are now passing on 2 drivers on
>> Linux: the Intel Mesa driver, and the NVIDIA driver.
>>
>> Te
On Tue, Aug 7, 2012 at 5:43 PM, Marek Olšák wrote:
> Do you have any idea what could be wrong with the patch? Also could
> please tell me how to setup VDPAU and where to download the tests, so
> that I can test this.
Just add:
--enable-vdpau
to your mesa configure line to enable it. To test it,
On Wed, Aug 8, 2012 at 9:37 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Otherwise we're likely to hang the GPU.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
___
mesa-dev mailing list
mesa-dev@lists.
sys.c | 21
> +
> src/gallium/winsys/radeon/drm/radeon_winsys.h |7 +++
> 4 files changed, 56 insertions(+), 2 deletions(-)
Reviewed-by: Alex Deucher
>
> diff --git a/src/gallium/drivers/r600/r600_pipe.c
> b/src/gallium/drivers/r600/r600_pipe.c
> index 76a019d..e
On Mon, Aug 13, 2012 at 7:29 AM, Christian König
wrote:
> Necessary for texture fetches with temp regs as source on SI.
>
> Signed-off-by: Christian König
For the series:
Reviewed-by: Alex Deucher
> ---
> .../drivers/radeon/radeon_setup_tgsi_llvm.c| 12 +++
On Tue, Aug 14, 2012 at 8:45 PM, Maxim Levitsky wrote:
>
> Hi, I have this backported patch here for more that an year, and forgot all
> about it.
> It just makes gallium drivers use driver name instread of 'dri' in driconf
> parser, thus making it compatable with 'driconf' GUI.
Sounds reasonabl
ntial address space loss in
> [PATCH 6/7] gallium/radeon: Create hole for waste when allocating
> [PATCH 7/7] gallium/radeon: Don't assign virtual address space for
For the series:
Reviewed-by: Alex Deucher
___
mesa-dev mailing li
On Wed, Aug 15, 2012 at 12:37 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 ++
> src/gallium/drivers/radeonsi/si_state_draw.c |
On Thu, Aug 16, 2012 at 6:04 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50389
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
BTW, any reason not to rename the files at th
om that series if it might help:
>
> http://lists.freedesktop.org/archives/mesa-dev/2012-April/020729.html
Series looks good to me. Looks like Michel added his reviewed-by at
the time as well. If it still applies, I'd say go ahead and commit
it.
Reviewed-by: Alex Deucher
Alex
On Wed, Aug 22, 2012 at 11:54 AM, Vadim Girlin wrote:
> On Wed, 2012-08-22 at 11:31 -0400, Alex Deucher wrote:
>> On Wed, Aug 22, 2012 at 11:24 AM, Vadim Girlin wrote:
>> > On Wed, 2012-08-22 at 11:23 +0300, Maxim Levitsky wrote:
>> >> Currently Gall
On Thu, Aug 23, 2012 at 11:19 AM, Vadim Girlin wrote:
> See https://bugs.freedesktop.org/show_bug.cgi?id=52064
Looks good to me.
Reviewed-by: Alex Deucher
> ---
> src/mesa/Makefile.am | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/mesa/Makefile.am b/sr
On Fri, Aug 24, 2012 at 11:37 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> It should be initialized by the kernel as necessary.
Does this patch work ok after powering off the system to make sure
there is no state in the register from a previous run? If all is
well, add my reviewed-by.
A
On Fri, Aug 24, 2012 at 8:52 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Could cause build failures if trying to use the macros in certain constructs.
>
> Signed-off-by: Michel Dänzer
For the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeo
On Mon, Aug 27, 2012 at 11:54 AM, Michel Dänzer wrote:
> On Mon, 2012-08-27 at 14:14 +0200, Marek Olšák wrote:
>> On Mon, Aug 27, 2012 at 10:37 AM, Michel Dänzer wrote:
>> > On Mon, 2012-08-27 at 02:27 +0200, Marek Olšák wrote:
>> >> This sets AR_HANDLE_NORMAL for RS880. I've added RS780 too, bec
On Wed, Aug 29, 2012 at 5:11 AM, Christian König
wrote:
> Signed-off-by: Christian König
for the series:
Reviewed-by: Alex Deucher
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Aug 30, 2012 at 10:41 AM, Tom Stellard wrote:
> The relevant POINT_SIZE registers are being set using the
> pipe_rasterizer_state, so we just need to tell the shader compiler which
> export type to use.
>
> This fixes several of the glean glsl tests.
Reviewed-b
On Thu, Aug 30, 2012 at 11:35 AM, Marek Olšák wrote:
> This fixes hangs on Cayman. We should have this patch in stable branches,
> but it would be better to have it in master as well for Cayman to be usable.
There is no VM support in the stable branches, only master so no need
to backport this.
On Thu, Aug 30, 2012 at 1:14 PM, Tom Stellard wrote:
> On Thu, Aug 30, 2012 at 07:00:44PM +0200, Christian König wrote:
>> Hi everybody,
>>
>> with the following patchset the radeonsi driver finally
>> completes a run of nearly all tests in Piglits "quick-driver"
>> profile without an GPU hang or
On Fri, Aug 31, 2012 at 4:57 AM, Vadim Girlin wrote:
> Use 1/256 for R6xx/7xx, 1/4096 for evergreen, instead of default 1/16.
>
> Helps to pass some piglit tests (fbo, multisample).
>
> Signed-off-by: Vadim Girlin
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r
On Mon, Sep 3, 2012 at 2:09 PM, Andreas Boll wrote:
> Hi list,
>
> I've read some critical news [0] about mesa and I want to fix the issue asap.
>
> I wanted to cherry pick the following commit to the stable branch 8.0:
>
>
> commit b4082f492b4b55df4c636445e47b97d1f1
On Thu, Apr 21, 2011 at 7:39 AM, Marek Olšák wrote:
> OpenSUSE is (was?) shipping r300g with LLVM disabled. Can you believe it?
> Poor users with SWTCL chipsets... and bad reputation for us too.
Both patches look good to me.
Reviewed-by: Alex Deucher
> ---
> configure.ac |
On Mon, Apr 25, 2011 at 1:01 PM, Sven Arvidsson wrote:
> On Fri, 2011-04-22 at 22:02 -0700, Tom Stellard wrote:
>> R500 cards do support 1024 fragment shader instructions (512 ALU + 512 TEX),
>> so I
>> think the value of GL_MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB should be 1024.
>
> I noticed that s
On Mon, Apr 25, 2011 at 7:09 PM, Matt Turner wrote:
> On Mon, Apr 4, 2011 at 4:33 PM, ★ Emeric wrote:
>> Hello again !
>> Last call for comments, this is the GSoC proposal that I will submit,
>> probably tommorow.
>>
>> Thank you,
>> Emeric
>
> So quite disappointingly, this project wasn't accept
2011/4/26 Christian König :
> Hi Andy and everybody on the list,
>
> sorry for the late reply, but i've been on vacation the last couple of
> days.
>
> Am Dienstag, den 12.04.2011, 21:38 +0100 schrieb Andy Furniss:
>> In addition to the quit crash I notice that resizing will also crash.
> Should be
2011/4/26 Christian König :
> Hi Alex,
>
> Am Dienstag, den 26.04.2011, 09:52 -0400 schrieb Alex Deucher:
>> This looks great Christian. Nice work. One quick note regarding
>> 68cc6bc5d8b6986acc7f5780d705f4ae9be2a446, COLOR[0-7]_INFO does need a
>> bo. It's
2011/4/26 Alex Deucher :
> 2011/4/26 Christian König :
>> Hi Alex,
>>
>> Am Dienstag, den 26.04.2011, 09:52 -0400 schrieb Alex Deucher:
>>> This looks great Christian. Nice work. One quick note regarding
>>> 68cc6bc5d8b6986acc7f5780d705f4ae9be2a446, CO
On Sun, May 1, 2011 at 3:17 PM, Sven Arvidsson wrote:
> Hi,
>
> I just got my first r600g capable card (a HD 5670) and noticed that
> quite a few games and apps either refuse to run or segfault (sometimes
> taking down X).
>
> Is it okay to start filing bugs for these issues, or is Evergreen
> sup
On Mon, May 2, 2011 at 10:05 AM, Jeffrey Collins wrote:
> I am interested in Mesa running on a P2020 Power Architecture system. What
> is the current state of Mesa for big endian systems? Is there a branch I
> should be looking at? I have noticed on the main line branch there are
> numerous change
2011/5/2 Mathias Fröhlich :
>
> Hi,
>
> On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote:
>> > So, I know that this patch is not applicable, since it does not account
>> > for sufficient cs space for this additional flush. Also it is probably
>> > too croase in face of the finegrained bo
2011/5/3 Mathias Fröhlich :
>
> Marek,
>
> On Tuesday, May 03, 2011 01:33:17 you wrote:
>> 2011/5/2 Mathias Fröhlich :
>> > I have again spent some more tries with different kinds of flushes on the
>> > rv635. What helps for the mipmap problem here is emitting a
>> > texture_barrier as well as flus
wrong there.
Patch looks good. I'll do some more digging internally to see if I
can find any additional info.
Reviewed-by: Alex Deucher
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/winsys/r600/drm/r600_hw_context.c | 77
> +++--
> src/gallium
t; value[3] = (GLfloat)(ctx->Fog.Density * ONE_DIV_SQRT_LN2);
>>
>> It's not intuitively obvious that M_LOG2E == 1/ln(2), so I actually
>> think the patch is good as is.
>>
>> Matt
>
> I never saw any response, so how about the two attach
2011/5/5 Mathias Fröhlich :
>
> Hi all,
>
> On Thursday, May 05, 2011 04:32:03 you wrote:
>> Okay my guess at the problem is that:
>>
>> the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
>> on the base in the CB being the same as the texture BASE which it won't
>> be in the case
2011/5/5 Alex Deucher :
> 2011/5/5 Mathias Fröhlich :
>>
>> Hi all,
>>
>> On Thursday, May 05, 2011 04:32:03 you wrote:
>>> Okay my guess at the problem is that:
>>>
>>> the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
&
rdware?
>
> Regards,
> Christian.
>
> _______
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
From cf459847da193c103bc34fea6a789373dee63568 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 5 Ma
2011/5/5 Alex Deucher :
> 2011/5/5 Alex Deucher :
>> 2011/5/5 Mathias Fröhlich :
>>>
>>> Hi all,
>>>
>>> On Thursday, May 05, 2011 04:32:03 you wrote:
>>>> Okay my guess at the problem is that:
>>>>
>>>> the CP trac
2011/5/7 Christian König :
> Am Donnerstag, den 05.05.2011, 17:53 -0400 schrieb Alex Deucher:
>> Something like the attached patch should work.
> If EXPORT_NORM is just an optimisation, then why is piglits "fbo-srgb"
> test is failing when I comment it out on my RV710?
On Mon, May 9, 2011 at 2:29 PM, Marek Olšák wrote:
> FWIW we can alternatively import the r300 compiler to
> gallium/drivers/r300 to prevent r300c breakages.
>
I don't think anyone is planning to do anything else with r300c, so it
might be best to just put it out to pasture and pull the compiler
On Mon, May 9, 2011 at 7:04 PM, Matt Turner wrote:
> On Mon, May 9, 2011 at 3:38 PM, Alex Deucher wrote:
>> On Mon, May 9, 2011 at 2:29 PM, Marek Olšák wrote:
>>> FWIW we can alternatively import the r300 compiler to
>>> gallium/drivers/r300 to prevent r300c breakag
On Wed, May 25, 2011 at 4:15 AM, Gustaw Smolarczyk wrote:
> The line 209 of src/gallium/drivers/r600/r600_opcodes.h:
> #define EG_V_SQ_CF_WORD1_SQ_CF_INST_HALT
> 0x001f
> has been duplicated by this patch.
Fixed. thanks!
5ed7a7b7205b5680d617b77a8cf228b80cf15f5e
Alex
> __
On Mon, Jun 6, 2011 at 11:49 AM, Benjamin Franzke
wrote:
> We need pci id to driver-name mapping for drm and
> wayland platforms in egl_dri2 and egl_gallium.
>
> egl_dri2 holds a own list, which is redundant with the information
> thats already stored in the drivers.
> egl_gallium uses the kernel
o put the pci ids together
somewhere. For the series:
Reviewed-by: Alex Deucher
>
> 2011/6/6 Alex Deucher :
>> On Mon, Jun 6, 2011 at 11:49 AM, Benjamin Franzke
>> wrote:
>>> We need pci id to driver-name mapping for drm and
>>> wayland platforms in egl_dri2
On Mon, Jun 6, 2011 at 2:38 PM, Benjamin Franzke
wrote:
> 2011/6/6 Alex Deucher :
>> Looks good. Thanks. Overall the patch set looks fine to me. I agree
>> with Marek that it might be better to put the pci ids together
>> somewhere. For the series:
>>
>>
On Mon, Jun 6, 2011 at 3:12 PM, Benjamin Franzke
wrote:
> 2011/6/6 Alex Deucher :
>> Sorry, I just thought of one tricky situation. Only r600g supports
>> CAYMAN asics, so r600c shouldn't have the CAYMAN pci ids. Maybe just
>> split the CAYMAN ids out into a new hea
On Tue, Jun 7, 2011 at 4:28 PM, Benjamin Franzke
wrote:
> 2011/6/7 Ian Romanick :
>> 1. These files need to have license statements.
>
> Right, thanks.
>
>> 2. These files add some new dependencies (e.g., libudev.h), so updates
>> to configure.ac need to be made to account for that.
>
> libudev wa
2011/6/12 Mathias Fröhlich :
>
> Hi,
>
> attached is a set of patches to r600g.
>
> 0001-r600g-Fix-typo.patch:
> Fix a more or less obvious typo in shader initialization setup.
>
> 0002-r600g-Set-the-domains-value-also-for-recycled-buffer.patch:
> Makes sure that buffer objects from the userspace b
ault and removing r300g and r600g
> from scons. I am not a fan of having multiple build systems and most people
> prefer autoconf anyway. It's not like anybody needs to build those drivers on
> Windows.
>
> Please review.
Patches look good to me.
Reviewed-by: Alex Deucher
&
On Wed, Jun 15, 2011 at 2:14 PM, Jeffrey Collins wrote:
> Does line anti aliasing work for r600 and r700 processors? It does not seem
> to change anything visually when I
> set PA_SC_AA_MASK.u32All, PA_SC_AA_SAMPLE_LOCS_MCTX.u32All, PA_SC_AA_SAMPLE_LOCS_8S_WD1_MCTX.u32All
> and PA_SC_AA_CONFIG.u32
On Wed, Jun 15, 2011 at 9:09 PM, Chad Versace wrote:
> If a renderbuffer wraps multiple renderbuffers, then Unwrapped points to
> the them.
>
> For example, if hardware requires separate depth and stencil buffers
> (X8_Z24 and S8), then glRenderbufferStorage(GL_DEPTH24_STENCIL8) may
> create a fak
On Thu, Jun 16, 2011 at 1:26 PM, Chad Versace wrote:
> On 06/16/2011 08:01 AM, Alex Deucher wrote:
>> On Wed, Jun 15, 2011 at 9:09 PM, Chad Versace wrote:
>>> If a renderbuffer wraps multiple renderbuffers, then Unwrapped points to
>>> the them.
>>>
>>&g
On Wed, Jun 22, 2011 at 10:12 PM, Roland Scheidegger wrote:
> Am 21.06.2011 20:59, schrieb Sven Arvidsson:
>> This change broke a whole lot of stuff on r600g, for example Unigine
>> Heaven:
>>
>> shader uses too many varying components (36 > 32)
>
> It looks like the r600g driver claims to o
On Thu, Jun 23, 2011 at 10:38 AM, Roland Scheidegger wrote:
> Am 23.06.2011 16:09, schrieb Jerome Glisse:
>> On Wed, Jun 22, 2011 at 10:49 PM, Alex Deucher wrote:
>>> On Wed, Jun 22, 2011 at 10:12 PM, Roland Scheidegger
>>> wrote:
>>>> Am 21.06.2011 20
On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlin wrote:
> #1 fixes slots order for x & y writes in the LIT implementation.
> Without this patch "fp-lit-mask" piglit test fails after patch 3. It seems
> wrong order causes wrong PV.* values for the next instruction.
>
> #2 reduces unneeded calls to r6
On Mon, Jun 27, 2011 at 9:32 AM, Jerome Glisse wrote:
> On Mon, Jun 27, 2011 at 8:38 AM, Roland Scheidegger
> wrote:
>> Am 25.06.2011 00:22, schrieb Vadim Girlin:
>>> On 06/24/2011 11:38 PM, Jerome Glisse wrote:
On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlin
wrote:
> Fixes https://
On Wed, Jun 29, 2011 at 10:34 AM, Micael wrote:
> Hi
> I'm new here, and I'm looking for a way to submit a patch that I have
> created that fixes an "index out of bounds" issue.
> I already attached the patch to the bug report in question
> (https://bugs.freedesktop.org/show_bug.cgi?id=34495). Is
< ctx->max_db; i++) {
> - results[(i * 4)+1] = 0x8000;
> - results[(i * 4)+3] = 0x8000;
> + for (i = 0; i < ctx->max_db; i++) {
> + if (!(ctx->zpass_b
On Thu, Jul 14, 2011 at 4:03 PM, Emil Velikov wrote:
> Is it still possible to build radeon,r300,r600 without LIBDRM_RADEON?
You can, but only for UMS/DRI1 and I don't know how well tested that
is any more. KMS/DRI2 classic drivers require libdrm_radeon.
Alex
>
> Signed-off-by: Emil Velikov
>
On Thu, Jul 14, 2011 at 4:35 PM, Emil Velikov wrote:
> In a rare case of building gallium only, we need to
> check if the required packages are available
>
> libdrm_[intel|radeon|nouveau] - gallium[i915 i965|r300 r600|nouveau]
r300g and r600g do not use libdrm_radeon anymore. Only the classic dr
On Thu, Jul 14, 2011 at 4:54 PM, Emil Velikov wrote:
> On Thu, 14 Jul 2011 21:40:13 +0100, Marek Olšák wrote:
>
>> r300g and r600g do not use libdrm_radeon. Only the classic drivers do.
>>
>> Marek
>
> There appears to be a dependency on "radeon_drm.h" in the winsys files
>
> ./src/gallium/driver
On Fri, Jul 15, 2011 at 2:22 PM, Brian Paul wrote:
> On 07/15/2011 10:07 AM, Dave Airlie wrote:
>>
>> On Fri, Jul 15, 2011 at 4:10 AM, Brian Paul
>> wrote:
>>>
>>> On Thu, Jun 23, 2011 at 7:08 PM, Brian Paul wrote:
I'd like to overhaul the part of Mesa related to texture memory
re
On Thu, Jul 21, 2011 at 12:15 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> I've been hacking around trying to make this test work and discovered
> writing some bits up at bit 16 of the exported word seems to act like
> some sort of mask. However I've no idea what this is or why this fixes
> thi
On Tue, Jul 26, 2011 at 11:05 AM, Bryan Cain wrote:
> On Mon, Jul 25, 2011 at 9:54 PM, Ian Romanick wrote:
>> The only changes in the 7.11 branch (until the final release) should be
>> low-risk fixes for significant bugs. Other than updates to the release
>> notes and changing the version, RC3 s
On Fri, Jul 29, 2011 at 7:51 AM, Dave Airlie wrote:
> On Fri, Jul 29, 2011 at 12:41 PM, Vadim Girlin wrote:
>> On Fri, 2011-07-29 at 12:20 +0100, Dave Airlie wrote:
>>> On Thu, Jul 28, 2011 at 9:33 PM, Vadim Girlin wrote:
>>> > Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39572
>>>
>>> Hi
On Fri, Jul 29, 2011 at 10:04 AM, Alex Deucher wrote:
> On Fri, Jul 29, 2011 at 7:51 AM, Dave Airlie wrote:
>> On Fri, Jul 29, 2011 at 12:41 PM, Vadim Girlin wrote:
>>> On Fri, 2011-07-29 at 12:20 +0100, Dave Airlie wrote:
>>>> On Thu, Jul 28, 2011 at 9:33
On Tue, Aug 2, 2011 at 9:37 AM, Micael Dias wrote:
> ---
Might want to mention the relevant bug and Pierre's prior patches for
future reference in case anyone wants to implement it for non-gallium
drivers. It would probably be useful to come up with a piglit test
for this, although I'm not sure
On Thu, Aug 4, 2011 at 10:26 AM, Christian König
wrote:
> Am Donnerstag, den 04.08.2011, 13:41 +0800 schrieb fykc...@gmail.com:
>> I guess that may be related with driver or DRM stack, after playback,
>> my desktop corrupts
>> http://dev.lemote.com/files/upload/software/temp/newmobcal1920-desktop-
e
> former too, as the latter is way simpler.
>
> This new work has been pushed into a new branch r600winsys2 in the
> main Mesa repository, please review/test.
>
Looks good. I'll try and run some tests on various hw later this week.
Reviewed-by: Alex Deu
On Mon, Aug 8, 2011 at 7:56 PM, Alex Deucher wrote:
> On Sun, Aug 7, 2011 at 5:25 PM, Marek Olšák wrote:
>> Hi,
>>
>> I have been recently trying to get thread offloading of the CS ioctl
>> into r600g in order to reduce the impact of kernel overhead on fps.
>> Th
On Mon, Aug 22, 2011 at 3:33 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> This doesn't implement any of the "cool" features of MapBufferRange.
> Adding this function is necessary for the next commit in the series.
>
Looks ok to me.
Reviewed-by: Alex Deucher
On Wed, Aug 24, 2011 at 3:11 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'd like to propose giving the ax to a bunch of old, unmaintained
> drivers. I've been doing a bunch of refactoring and reworking of core
> Mesa code, and these drivers have been causing me
On Wed, Aug 24, 2011 at 3:37 PM, Dee Sharpe
wrote:
> On 8/24/2011 2:11 PM, Ian Romanick wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I'd like to propose giving the ax to a bunch of old, unmaintained
>> drivers. I've been doing a bunch of refactoring and reworking of core
>>
On Wed, Aug 24, 2011 at 10:35 AM, Micael wrote:
> Any more feedback regarding this?
> I now don't have much time to work on it again, but I may find some, so
> knowing what's left to do would be nice...
Does anyone want to see this in a separate branch first, or should it
just go into master?
Al
4] r600g: Handle PIPE_TRANSFER_MAP_DIRECTLY.
> [PATCH 4/4] r600g: Hook up xorg state tracker.
For the series:
Reviewed-by: Alex Deucher
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Aug 25, 2011 at 11:34 AM, Brian Paul wrote:
> On 08/25/2011 09:17 AM, Alex Deucher wrote:
>>
>> On Wed, Aug 24, 2011 at 10:35 AM, Micael wrote:
>>>
>>> Any more feedback regarding this?
>>> I now don't have much time to work on it again, but
On Fri, Aug 26, 2011 at 4:11 AM, Chia-I Wu wrote:
> On Fri, Aug 26, 2011 at 3:52 PM, Ilyes Gouta wrote:
>> Thanks a lot Chia-l,
>>
>> In general, do you guys keep a matrix (per driver, mesa version),
>> where supported and unsupported features are listed?
> Some of the driver developers do, but I
2011/8/26 Kristian Høgsberg :
> On Fri, Aug 26, 2011 at 4:52 AM, matthew green wrote:
>>
>> hi folks,
>>
>>> - Remove all DRI1 drivers: i810, mach64, mga, r128, savage, sis, tdfx,
>>> and unichrome.
>>
>> over in netbsd land we're still lagging on DRI2 support[*]. of
>> the above cards, i've har
uery.
>
> There are no piglit regressions on Evergreen.
>
> Please review.
Reviewed-by: Alex Deucher
>
> Marek Olšák (12):
> r600g: define GROUP_FORCE_NEW_BLOCK in common header
> r600g: consolidate common context init code
> r600g: fix possible
On Tue, Feb 28, 2012 at 10:42 AM, Brian Paul wrote:
> This lets us use the resource_copy_region() path when blitting from
> R8G8B8A8 to R8G8B8x8, for example.
>
> v2: be smarter when src_format==dst_format
Reviewed-by: Alex Deucher
> ---
> src/gallium/auxiliary/ut
e just noticed while
> thinking about the shininess tables pushdown.
>
> The complete series passes piglit quick on swrast, swrastg and r600g with no
> regressions.
>
> Please Review
>
Series looks good to me.
Reviewed-by: Alex Deucher
> Thanks
>
> Mathias
>
>
performance.
> If those flags are ignored, both the CPU and the GPU may idle in the middle
> of rendering (because of the GEM_WAIT_IDLE ioctl), which makes every other
> optimization less useful. I have seen the last patch improve framerate in
> Wine.
>
> Please review.
Loo
ter for dst
caches. Other than that,
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_asm.c | 24 +--
> src/gallium/drivers/r600/r600_pipe.h | 5 ---
> src/gallium/drivers/r600/r600_state_common.c | 39
> ++-
I've gone ahead and pushed the initial SI gallium driver to my mesa
tree on fdo. The new driver is called radeonsi. I've left it in my
personal repo for now as Tom wants to restructure the llvm stuff
before we merged it into mesa proper. You can find the code here
(http://cgit.freedesktop.org/~a
On Thu, Apr 5, 2012 at 11:37 AM, Lucas Stach wrote:
> Am Donnerstag, den 05.04.2012, 09:48 -0400 schrieb Alex Deucher:
>> I've gone ahead and pushed the initial SI gallium driver to my mesa
>> tree on fdo. The new driver is called radeonsi. I've left it in my
>&g
On Mon, Apr 9, 2012 at 4:44 PM, Vadim Girlin wrote:
> This should help to prevent gpu lockups.
> See https://bugs.freedesktop.org/show_bug.cgi?id=48472
>
> Signed-off-by: Vadim Girlin
Reviewed-by: Alex Deucher
Should probably also add a note that this should be applied to the
sta
On Mon, Apr 16, 2012 at 8:09 AM, Marek Olšák wrote:
> Hi,
>
> does lack of feedback mean that this idea is still off the table
> despite the performance increase, or that nobody is opposed to it
> anymore?
>
> In other words, may I start adapting the other drivers and send patches?
Seems ok to me
On Tue, Apr 17, 2012 at 12:11 PM, Tom Stellard wrote:
> ---
> src/gallium/drivers/r600/r600_llvm.c | 300
> ++
> src/gallium/drivers/r600/r600_llvm.h | 29
> 2 files changed, 329 insertions(+), 0 deletions(-)
> create mode 100644 src/gallium/drivers/r600/
thing missing from the backend is support for most of the
> texturing instructions.
>
> At the moment, I do not have any plans to improve support for graphics
> in the LLVM backend, but I wanted to get these patches merged into master
> to give people who are interested a chance to hack on
On Fri, Apr 27, 2012 at 3:12 PM, Tom Stellard wrote:
> The SQ_LOOP_CONST_* registers range from SQ_LOOP_CONST_0 to
> SQ_LOOP_CONST_191.
> ---
> src/gallium/drivers/r600/evergreend.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreend.
gt; src/mesa/drivers/dri/radeon/radeon_state.c | 5 +++--
> 4 files changed, 14 insertions(+), 10 deletions(-)
Reviewed-by: Alex Deucher
>
> diff --git a/src/mesa/drivers/dri/r200/r200_state.c
> b/src/mesa/drivers/dri/r200/r200_state.c
> index 3131007..0f7b564 1006
On Wed, May 9, 2012 at 11:31 AM, Kai Wasserbäch
wrote:
>
> Signed-off-by: Kai Wasserbäch
added as part of 6ae12bac596ce3a6aa8e09f638ad2cb4a7c18e5c
Alex
> ---
> Wasn't able to build-test this one, my connection is a little slow and I
> would
> need to update my build chroot on this machine.
On Fri, May 11, 2012 at 10:03 AM, Francisco Jerez wrote:
> jfons...@vmware.com writes:
>
>> From: José Fonseca
>>
>> For consistency.
>
> I'm OK with this change, but, just so that you know, the only reason I
> called it TGSI_BUFFER instead of TGSI_TEXTURE_BUFFER was to keep it
> consistent with
On Fri, May 11, 2012 at 11:00 AM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On Fri, May 11, 2012 at 10:03 AM, Francisco Jerez
>> wrote:
>> > jfons...@vmware.com writes:
>> >
>> >> From: José Fonseca
>> >>
>> >> For consistency.
>> >
>> > I'm OK with this change, but, just so that
601 - 700 of 819 matches
Mail list logo
