On Thu, Jul 24, 2014 at 8:07 PM, Alex Deucher wrote:
> On Thu, Jul 24, 2014 at 6:28 PM, wrote:
> > From: Jerome Glisse
> >
> > The ucode we got for hawaii does not support 0x1000 special nop
> > packet type 3 and this leads to gpu reading invalid memory. As pa
On Thu, Jul 24, 2014 at 05:42:21PM -0400, j.gli...@gmail.com wrote:
> From: Jerome Glisse
>
> The gpu packet prefetcher hates the ugly big nop packet those leads
> to prefetching some invalid memory in some case. Apparently hawaii
> is particularly sensible to this.
>
> No
On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote:
> On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote:
> > On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding
> > wrote:
> > > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote:
> > >> On Mon, Nov 18, 2013 at 8:29 AM, Thie
On Thu, Sep 05, 2013 at 03:29:52PM -0400, Jerome Glisse wrote:
> On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
> > Hi all,
> >
> > This thread is about
> > http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
> >
> > We rec
On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
> Hi all,
>
> This thread is about
> http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
>
> We recently find some interesting thing about UVD based playback on
> loongson 3a plaform, and also find a way to fix the prob
On Mon, May 20, 2013 at 5:13 AM, Vadim Girlin wrote:
> On 05/20/2013 11:27 AM, Dragomir Ivanov wrote:
>>
>> 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0,
>> surf=0x88d848,
>> level=0x88dea8, bpe=1, tile_split=0, offset=65536, start_level=0)
>>
>> It looks like division by 0. tile_sp
On Wed, May 1, 2013 at 1:23 PM, Marek Olšák wrote:
> This is a funny subject. Originally, we only used SURFACE_SYNC on
> Evergreen, which is what the hw guys recommend using, but then Jerome
> came and rewrote it with no reasonable argument to back it up (what he
> was trying to fix by his cache-f
On Wed, Apr 24, 2013 at 3:15 PM, wrote:
> From: Alex Deucher
>
> Lighter weight then using streamout. Only evergreen
> and newer asics support embedded data as src with
> CP DMA.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
>
On Wed, Mar 27, 2013 at 11:27 AM, wrote:
> From: Jerome Glisse
>
> Build time option, set RADEON_CS_DUMP_ON_LOCKUP to 1 in radeon_drm_cs.h to
> enable it.
>
> When enabled after each cs submission the code will try to detect lockup by
> waiting on one of the buffer of
On Wed, Mar 27, 2013 at 4:45 AM, Christian König
wrote:
> Am 27.03.2013 01:43, schrieb Jerome Glisse:
>
>> On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie wrote:
>>>>>>
>>>>>> correctly). But Marek is quite right that this only counts for state
>&g
On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie wrote:
>>
correctly). But Marek is quite right that this only counts for state
objects
and makes no sense for set_* and draw_* calls (and I'm currently thinking
how to avoid that and can't come up with a proper solution). Anyway it's
On Tue, Mar 26, 2013 at 2:14 PM, Jordan Justen wrote:
> On Tue, Mar 26, 2013 at 10:34 AM, Jerome Glisse wrote:
>> On Tue, Mar 26, 2013 at 4:39 AM, violin yanev wrote:
>>> Thanks for your replies guys!
>>>
>>> The output of eglinfo is:
>>> EGL API ver
On Tue, Mar 26, 2013 at 4:39 AM, violin yanev wrote:
> Thanks for your replies guys!
>
> The output of eglinfo is:
> EGL API version: 1.4
> EGL vendor string: Mesa Project
> EGL version string: 1.4 (DRI2)
> EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
> EGL extensions string:
> EGL_MESA_drm_im
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák wrote:
> On Tue, Mar 26, 2013 at 3:59 PM, Christian König
> wrote:
>> Am 26.03.2013 15:34, schrieb Marek Olšák:
>>
>>> Speaking of si_pm4_state, I think it's a horrible mechanism for
>>> anything other than constant state objects (create/bind/delete
>
On Tue, Mar 26, 2013 at 6:22 AM, Christian König
wrote:
> Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
>
>> From: Jerome Glisse
>>
>> Same as on r600, trace cs execution by writting cs offset after each
>> states, this allow to pin point lockup inside command
On Mon, Mar 25, 2013 at 1:12 PM, Christian König
wrote:
> Am 25.03.2013 17:50, schrieb Jerome Glisse:
>
>> On Mon, Mar 25, 2013 at 12:38 PM, Christian König
>> wrote:
>>>
>>> Am 25.03.2013 17:01, schrieb j.gli...@gmail.com:
>>>
>>>>
On Mon, Mar 25, 2013 at 12:38 PM, Christian König
wrote:
> Am 25.03.2013 17:01, schrieb j.gli...@gmail.com:
>
>> From: Jerome Glisse
>>
>> Same as on r600, trace cs execution by writting cs offset after each
>> states, this allow to pin point lockup inside command
On Mon, Mar 25, 2013 at 12:17 PM, Michel Dänzer wrote:
> On Mon, 2013-03-25 at 12:01 -0400, j.gli...@gmail.com wrote:
>> From: Jerome Glisse
>>
>> Same as on r600, trace cs execution by writting cs offset after each
>> states, this allow to pin point lockup inside c
On Mon, Mar 4, 2013 at 2:05 PM, Michel Dänzer wrote:
> On Mon, 2013-03-04 at 13:17 -0500, j.gli...@gmail.com wrote:
>> From: Jerome Glisse
>>
>> Some code calling the flush function gave a fence pointer that point
>> to an old fence and should be unrefer
On Wed, Feb 27, 2013 at 6:11 PM, Marek Olšák wrote:
> The states were split because we thought it caused a hardlock. Now we know
> the hardlock was caused by something else and has since been fixed.
For the serie:
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/everg
On Sun, Mar 3, 2013 at 8:39 AM, Marek Olšák wrote:
> also change names of other functions, so that they make sense
For the serie:
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/evergreen_state.c |4 +-
> src/gallium/drivers/r600/r600_pipe.h |8 +--
&g
On Sun, Mar 3, 2013 at 9:13 AM, Marek Olšák wrote:
> This avoids the kernel CS checker errors with MSAA textures.
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/r600_texture.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/ga
> -util_hash_table_set(bo->mgr->bo_handles,
> (void*)(uintptr_t)whandle->handle, bo);
> -pipe_mutex_unlock(bo->mgr->bo_handles_mutex);
> -
> whandle->stride = stride;
> return TRUE;
> }
> --
> 1.8.1.4
>
Reviewed-by: Jerome Glisse
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Feb 26, 2013 at 1:05 PM, Stefan Seifert wrote:
> Good news!
>
> I gave the r600-sb branch a good testing at commit
> 265ae41b1f1d086d35d274c7378c43cddb8215c8 and so far I've not had a single
> lockup in about 1 1/2 hours of flight time!
>
> The downside is that this is with R600_HYPERZ=0.
|3 +--
> src/gallium/drivers/r600/r600_hw_context.c | 26 +-
> 2 files changed, 18 insertions(+), 11 deletions(-)
For the serie:
Reviewed-by: Jerome Glisse
>
> --
> 1.7.7.5
>
> ___
>
>
> Also the sampler swizzling was broken in theory and the fact it worked was
> a lucky coincidence.
>
> radeonsi might need to port this.
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/evergreen_state.c | 13 +++-
> src/gallium/drivers/r600/r60
On Mon, Feb 11, 2013 at 6:45 PM, wrote:
> From: Jerome Glisse
>
> Seems that alpha test being enabled confuse the GPU on the order in
> which it should perform the Z testing. So force the order programmed
> throught db shader control.
>
> v2: Only force z order when
On Wed, Jan 30, 2013 at 10:35 PM, Marek Olšák wrote:
> On Wed, Jan 30, 2013 at 6:14 PM, wrote:
>> From: Jerome Glisse
>>
>> We are now seing cs that can go over the vram+gtt size to avoid
>> failing flush early cs that goes over 70% (gtt+vram) usage. 70%
>> i
On Tue, Jan 8, 2013 at 10:15 AM, Marek Olšák wrote:
> On Mon, Jan 7, 2013 at 9:30 PM, wrote:
>> From: Jerome Glisse
>>
>> Signed-off-by: Jerome Glisse
>> ---
>> src/gallium/drivers/r300/r300_context.c | 2 +-
>> src/gallium/drivers/r600/r6
On Mon, Jan 7, 2013 at 11:03 AM, Marek Olšák wrote:
> On Mon, Jan 7, 2013 at 3:45 PM, Christian König
> wrote:
>> On 07.01.2013 01:24, Marek Olšák wrote:
>>>
>>> On Sun, Jan 6, 2013 at 11:58 PM, Jerome Glisse wrote:
>>>>
>>>> On Sun, Jan
On Sat, Jan 5, 2013 at 9:49 AM, Christian König wrote:
> On 04.01.2013 23:19, j.gli...@gmail.com wrote:
> [SNIP]
>
>> diff --git a/src/gallium/drivers/r300/r300_emit.c
>> b/src/gallium/drivers/r300/r300_emit.c
>> index d1ed4b3..c824821 100644
>> --- a/src/gallium/drivers/r300/r300_emit.c
>> +++ b/
On Fri, Jan 4, 2013 at 6:33 PM, Alex Deucher wrote:
> On Fri, Jan 4, 2013 at 5:19 PM, wrote:
>> From: Jerome Glisse
>>
>> The design is to take advantage of the fact that kernel will emit
>> semaphore when buffer is referenced by different ring. So the only
On Fri, Jan 4, 2013 at 5:19 PM, wrote:
> From: Jerome Glisse
>
> Signed-off-by: Jerome Glisse
For the serie piglit says no regression on r7xx/evergreen. I need to
test r3xx/r5xx and SI.
Cheers,
Jerome
> ---
> src/gallium/drivers/r600/r600_pipe.c | 18 +-
On Wed, Dec 19, 2012 at 12:33 PM, Tom Stellard wrote:
> On Sun, Dec 16, 2012 at 08:33:23PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This adds TBO support to r600g, and with GLSL 1.40 enabled,
>> we now get 3.1 core profiles advertised for r600g.
>>
>> This code is evergreen only so fa
On Wed, Dec 19, 2012 at 12:17 PM, wrote:
> From: Jerome Glisse
>
> It's a build time option you need to set R600_TRACE_CS to 1 and it
> will print to stderr all cs along as cs trace point value which
> gave last offset into a cs process by the GPU.
>
> Signed-o
aven't paid much attention to compute side, i should probably look at it.
> And one question:
>
> Why do you use set both FLUSH_AND_INV and STREAMOUT_FLUSH on
> Evergreen, while r600 only gets FLUSH_AND_INV? Did you overlook this?
No, just matching fglrx pattern, i don't think i teste
On Fri, Nov 30, 2012 at 7:43 AM, Benoit Jacob wrote:
> On 12-11-23 02:21 PM, Benoit Jacob wrote:
>> On 12-11-21 12:48 PM, Chad Versace wrote:
>>> On 11/20/2012 09:29 AM, Benoit Jacob wrote:
>>>
Any questions?
Do you support or oppose me asking FD.o admins to allow hidden bugs on
Mes
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 at 8:05 PM, Marek Olšák wrote:
> >> The problem was we set VRAM|GTT for relocations of STATIC resources.
> >> Setting just VRAM increases the framerate 4 tim
o.
Reviewed-by: Jerome Glisse
> ---
> 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/drivers/r600/r600_bu
On Tue, Oct 30, 2012 at 8:49 PM, Tzvetan Mikov wrote:
> On 10/30/2012 05:20 PM, Tzvetan Mikov wrote:
>>
>> Thanks a lot! I reproduced the same results here and I think I have
>> figured out what the problem is. The frame buffer is always created in
>> linear mode. The temporary hack included below
On Tue, Oct 30, 2012 at 10:43 AM, Tzvetan Mikov wrote:
> On 10/30/2012 07:12 AM, Patrick Baggett wrote:
>> Is your screen refresh rate 70 Hz? Because if so, that means that it's
>> syncing to the vblank on Mesa, and not doing so on the proprietary one.
>
> Unfortunately no. In fact the Gallium EGL
On Fri, Oct 26, 2012 at 10:26 PM, Tzvetan Mikov wrote:
>> -Original Message-
>> From: Jerome Glisse
>
>> > Can anyone shed some light on this? Is this by design - e.g. is
>> > this a case of "we know that tiling is currently slower than linear
&g
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 eac
On Fri, Oct 26, 2012 at 8:07 PM, Tzvetan Mikov wrote:
> Hi,
> I have been running tests with Mesa 9.0 and Rdeon R600 (Radeon HD 6460) and I
> accidentally noticed that a small hack I did to disable texture tiling,
> actually *doubles* the frame rate. With different chips (e.g. 6750) the
> diffe
;
> The command buffers are nothing like that. They represent states, not state
> slots.
>
> We could probably give r600_atom a better name someday.
For the serie:
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/evergreen_compute.c |4 +--
> src/gallium/d
On Wed, Oct 3, 2012 at 5:50 PM, Marek Olšák wrote:
> The decompression is done in-place and only the compressed tiles are
> decompressed. Note: R6xx-R7xx can do that only with Z16 and Z32F.
>
> The texture unit is programmed to use non-displayable tiling and depth
> ordering of samples, so that it
On Wed, Sep 12, 2012 at 5:24 PM, Jerome Glisse wrote:
> On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák wrote:
>> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse wrote:
>>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák wrote:
>>>> Please provide information about the G
On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák wrote:
> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse wrote:
>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák wrote:
>>> Please provide information about the GPU and the test which locks up. I'd
>>> like to reproduc
On Tue, Jul 17, 2012 at 1:58 PM, wrote:
> From: Jerome Glisse
>
> htile is used for HiZ and HiS support and fast Z/S clears.
> This commit just adds the htile setup and Fast Z clear.
> We don't take full advantage of HiS with that patch.
>
> v2 really use fast clea
On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák wrote:
> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse wrote:
>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák wrote:
>>> Please provide information about the GPU and the test which locks up. I'd
>>> like to reproduc
On Tue, Sep 11, 2012 at 3:00 PM, Jerome Glisse wrote:
> On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák wrote:
>> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse wrote:
>>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák wrote:
>>>> Please provide information about the G
On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák wrote:
> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse wrote:
>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák wrote:
>>> Please provide information about the GPU and the test which locks up. I'd
>>> like to reproduc
e ta_cntl_aux and before cb/db. But the
ordering relative to pa is kind of weird and moving when looking at
fglrx.
Cheers,
Jerome
> On Tue, Sep 11, 2012 at 6:48 PM, Jerome Glisse wrote:
>> On Mon, Sep 10, 2012 at 7:16 PM, Marek Olšák wrote:
>>
>> NAK this one introduce lo
On Mon, Sep 10, 2012 at 7:16 PM, Marek Olšák wrote:
NAK this one introduce lockup. As i said in another email register
group/order matter and with this patch i get 100% lockup rate in some
test case for instance the test case i reference in my other email
> ---
> src/gallium/drivers/r600/evergr
right now),
> atomization of some states, some fixes and a major cleanup in r600_draw_vbo.
>
> Tested on RS880 and REDWOOD.
>
> Please review.
For the first 18 patch :
Reviewed-by: Jerome Glisse
NAK for the 19 see other reply
>
> Marek Olšák (19):
> r600g: consolidate initial
On Sun, Sep 9, 2012 at 1:03 AM, Marek Olšák wrote:
> Based on the patch called "simplify and fix flushing and synchronization"
> by Jerome Glisse.
>
> Rebased, removed unneded code, simplified more and cleaned up.
>
> Also, SH_ACTION_ENA is not set when changing shader
On Thu, Sep 6, 2012 at 11:32 AM, Alex Deucher wrote:
> 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.
On Thu, Sep 6, 2012 at 8:32 PM, Dave Airlie wrote:
> On Fri, Sep 7, 2012 at 10:03 AM, Marek Olšák wrote:
>> On Fri, Sep 7, 2012 at 12:05 AM, Jerome Glisse wrote:
>>> On Thu, Sep 6, 2012 at 4:10 PM, Marek Olšák wrote:
>>>> On Thu, Sep 6, 2012 at 8:34 PM, Jerome Gl
On Thu, Sep 6, 2012 at 4:10 PM, Marek Olšák wrote:
> On Thu, Sep 6, 2012 at 8:34 PM, Jerome Glisse wrote:
>> On Thu, Sep 6, 2012 at 2:29 PM, Marek Olšák wrote:
>>> This looks good to me. It's funny to see the r300g architecture being
>>> re-implemented
On Thu, Sep 6, 2012 at 2:29 PM, Marek Olšák wrote:
> This looks good to me. It's funny to see the r300g architecture being
> re-implemented in r600g. :)
>
> There's one optimization that r300g has that this patch doesn't. r300g
> keeps the index of the first and the last dirty atom and the loops
>
On Thu, Sep 6, 2012 at 11:32 AM, Alex Deucher wrote:
> 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.
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 emited in a specific or
ompression for MSAA colorbuffers for evergreen
> r600g: change programming of CB_SHADER_MASK on r600-r700
> r600g: implement MSAA for r700
For the serie :
Reviewed-by: Jerome Glisse
What's wrong with r6xx ?
>
> src/gallium/auxiliary/util/u_blitter.c
On Fri, Aug 3, 2012 at 11:06 AM, Christian König
wrote:
> Wait for VA use to end before reusing it.
>
> Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=45018
>
> Signed-off-by: Christian König
Actually you right mesa can't free right away va, it needs to wait
kernel is done. But kernel
On Fri, Aug 3, 2012 at 11:06 AM, Christian König
wrote:
> Wait for VA use to end before reusing it.
>
> Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=45018
>
> Signed-off-by: Christian König
> ---
> src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 64
> +
> 1
On Sun, Jul 29, 2012 at 1:50 PM, Marek Olšák wrote:
> On Tue, Jul 17, 2012 at 7:58 PM, wrote:
>> From: Jerome Glisse
>>
>> htile is used for HiZ and HiS support and fast Z/S clears.
>> This commit just adds the htile setup and Fast Z clear.
>> We don'
On Mon, Jul 23, 2012 at 5:28 PM, Marek Olšák wrote:
> On Mon, Jul 23, 2012 at 4:25 PM, Jerome Glisse wrote:
>> On Sun, Jul 22, 2012 at 8:58 PM, Marek Olšák wrote:
>>> On Fri, Jul 20, 2012 at 4:54 AM, Jerome Glisse wrote:
>>>> On Thu, Jul 19, 2012 at 10:25 PM, Ma
On Mon, Jul 23, 2012 at 5:28 PM, Marek Olšák wrote:
> On Mon, Jul 23, 2012 at 4:25 PM, Jerome Glisse wrote:
>> On Sun, Jul 22, 2012 at 8:58 PM, Marek Olšák wrote:
>>> On Fri, Jul 20, 2012 at 4:54 AM, Jerome Glisse wrote:
>>>> On Thu, Jul 19, 2012 at 10:25 PM, Ma
On Sun, Jul 22, 2012 at 8:58 PM, Marek Olšák wrote:
> On Fri, Jul 20, 2012 at 4:54 AM, Jerome Glisse wrote:
>> On Thu, Jul 19, 2012 at 10:25 PM, Marek Olšák wrote:
>>> On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse wrote:
>>>> On Thu, Jul 19, 2012 at 10:06 P
On Thu, Jul 19, 2012 at 10:25 PM, Marek Olšák wrote:
> On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse wrote:
>> On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák wrote:
>>> I actually care a lot about lockups. Well, you are complaing about
>>> lockups, yet you have quite
On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák wrote:
> I actually care a lot about lockups. Well, you are complaing about
> lockups, yet you have quite obvious bugs in your hyperz code, so let's
> fix them first. (I wouldn't even try and run the hyperz code in its
> current state. Please don't tak
On Thu, Jul 19, 2012 at 9:00 PM, Marek Olšák wrote:
> On Fri, Jul 20, 2012 at 1:34 AM, Jerome Glisse wrote:
>> On Thu, Jul 19, 2012 at 6:07 PM, Marek Olšák wrote:
>>> I have these issues with the patch:
>>>
>>> 1) On GPUs without a vertex cache, you fl
On Sat, Jul 14, 2012 at 9:56 AM, Alex Deucher wrote:
> On Fri, Jul 13, 2012 at 8:11 PM, Jerome Glisse wrote:
>> On Fri, Jul 13, 2012 at 8:08 PM, Marek Olšák wrote:
>>> Hi Jerome,
>>>
>>> I couldn't open the patch, because freedesktop.org doesn't
On Fri, Jul 13, 2012 at 8:08 PM, Marek Olšák wrote:
> Hi Jerome,
>
> I couldn't open the patch, because freedesktop.org doesn't seem to
> work for me today, it always times out.
>
> Anyway, non-working code shouldn't be merged into Mesa master, because
> it decreases the quality of the driver and
On Tue, Jul 10, 2012 at 5:16 PM, Marek Olšák wrote:
> On Tue, Jul 10, 2012 at 10:00 PM, Jerome Glisse wrote:
>> On Tue, Jul 10, 2012 at 2:10 PM, Marek Olšák wrote:
>>> On Tue, Jul 10, 2012 at 6:40 AM, Vadim Girlin wrote:
>>>> On Sat, 2012-07-07 at 01:48 +0200, M
On Tue, Jul 10, 2012 at 2:10 PM, Marek Olšák wrote:
> On Tue, Jul 10, 2012 at 6:40 AM, Vadim Girlin wrote:
>> On Sat, 2012-07-07 at 01:48 +0200, Marek Olšák wrote:
>>> On Wed, Jun 27, 2012 at 1:34 AM, Vadim Girlin wrote:
>>> > Use r600_resource_texture::flished_depth_texture for GPU access, and
On Tue, Jun 26, 2012 at 5:45 AM, Vadim Girlin wrote:
> On Fri, 2012-06-22 at 14:24 -0400, Jerome Glisse wrote:
>> On Fri, Jun 22, 2012 at 10:02 AM, Vadim Girlin wrote:
>> > r600g: avoid unnecessary shader exports
>> > r600g: enable DUAL_EXPORT mode when possible
>
On Fri, Jun 22, 2012 at 10:02 AM, Vadim Girlin wrote:
> r600g: avoid unnecessary shader exports
> r600g: enable DUAL_EXPORT mode when possible
>
> First patch fixes the lockups with DUAL_EXPORT mode for me, also AFAICS it
> fixes some depth/stencil tests, though I'm not sure why, haven't looked
dim Girlin
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/evergreen_state.c | 46
> ++
> src/gallium/drivers/r600/evergreend.h | 7
> src/gallium/drivers/r600/r600_pipe.h | 5 +++
> src/gallium/drivers/r600/r600_st
we are doing less exports, which are very costly.
>
> Signed-off-by: Vadim Girlin
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/evergreen_state.c | 10 +++---
> src/gallium/drivers/r600/r600_shader.c | 25 ++---
> src/gall
On Tue, Jun 19, 2012 at 4:46 PM, Jerome Glisse wrote:
> On Mon, Jun 18, 2012 at 8:33 PM, Fredrik Höglund wrote:
>> On Tuesday 19 June 2012, Brian Paul wrote:
>>> On 06/18/2012 02:50 PM, Fredrik Höglund wrote:
>>> > Reviewed-by: Brian Paul
>>> >
On Mon, Jun 18, 2012 at 8:33 PM, Fredrik Höglund wrote:
> On Tuesday 19 June 2012, Brian Paul wrote:
>> On 06/18/2012 02:50 PM, Fredrik Höglund wrote:
>> > Reviewed-by: Brian Paul
>> > ---
>> >
>> > v2: Change baseinstance to base_instance in _mesa_prims
>> > and to baseInstance in the vbo_ex
On Tue, Jun 19, 2012 at 2:06 PM, Tom Stellard wrote:
> On Tue, Jun 19, 2012 at 07:57:50PM +0200, Marek Olšák wrote:
>> Hi Tom,
>>
>> This adds new calls to r600_inval_xxx_cache, which justs sets the
>> dirty flag in the atom "surface_sync_cmd" to true, but I couldn't find
>> where the compute code
On Tue, Jun 12, 2012 at 1:34 PM, Christoph Bumiller
wrote:
> On 06/12/2012 06:52 PM, Jerome Glisse wrote:
>> On Tue, Jun 12, 2012 at 8:39 AM, Christoph Bumiller
>> wrote:
>>> On 06/12/2012 02:25 PM, Olivier Galibert wrote:
>>>> On Tue, Jun 12, 2012 at 01:50:
On Tue, Jun 12, 2012 at 8:39 AM, Christoph Bumiller
wrote:
> On 06/12/2012 02:25 PM, Olivier Galibert wrote:
>> On Tue, Jun 12, 2012 at 01:50:08PM +0200, Christoph Bumiller wrote:
First question: how many depths should be computed, and for which
coordinates? Which of these values is asso
On Thu, 2012-03-01 at 13:56 -0600, Patrick Baggett wrote:
> Now I'm curious. Is it the case that every DRI1 driver could be a DRI2
> driver with enough effort? Not talking about emulating hardware
> features.
>
>
> Patrick
DRI2 impose nothing on hw capabilities. So any hw can do DRI2 even hw
wit
On Tue, Feb 21, 2012 at 7:55 PM, Marek Olšák wrote:
> Hi everyone,
>
> Besides the cleanups, there are fixes for create_context fail paths and
> rework of queries. The rework is the most important, because it eliminates
> buffer_map calls (and therefore buffer_wait) in begin_query.
>
> There are
Hi,
So tiling work is i believe done. I have run piglit accross wide range
of hw and sw combination. Bottom line is new mesa on top of either old
kernel or old ddx won't regress anything. New mesa on top of proper
kernel will get you 2D tiling for texture and anything allocated by
mesa, and if you
On Mon, Jan 30, 2012 at 09:23:03PM +0100, Marek Olšák wrote:
> Hi everyone,
>
> This patch series is a follow-up to the previous one ("Remove all uses of the
> register mask"). First, it cleans up some code and merges r600_context into
> r600_pipe_context. The split of functionality between the
On Mon, Jan 16, 2012 at 12:08:17PM +, Simon Farnsworth wrote:
> (resending due to my inability to work my e-mail client - I neither cc'd
> Jerome, nor used the correct identity, so the original appears to be held in
> moderation).
>
> On Thursday 12 January 2012, Jerome G
On Fri, Jan 13, 2012 at 11:59:28AM +0100, Michel Dänzer wrote:
> On Don, 2012-01-12 at 14:50 -0500, Jerome Glisse wrote:
> >
> > Attached is kernel, libdrm, ddx, mesa/r600g patches to enable 2D tiling
> > on r600 to cayman. I haven't yet done a full regression testing
On Sat, Jan 7, 2012 at 8:08 PM, Marek Olšák wrote:
> On Fri, Jan 6, 2012 at 4:42 PM, wrote:
>> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
>> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
>> index ccf9c4f..8ef0c18 100644
>> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
>>
On Tue, Nov 29, 2011 at 10:12 AM, Jose Fonseca wrote:
> The bulk is there but there are a few places missing.
>
> I'll update those, do some sanity checks and commit.
>
> Jose
Is there a good reason to delete i965g ? Maybe some people are interested in it.
Cheers,
Jerome
On Fri, Sep 23, 2011 at 3:18 AM, wrote:
> Hi all,
>
> In our mesa code, there is a pipe driver named failover which is not used
> at all. I think the failover pipe driver is a good solution of the hardware
> without full capability to support GL2.0. But why it’s discarded? It’s
> because fall
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://bugs.freedesktop.org/sho
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 Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlin wrote:
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38440
>
> Signed-off-by: Vadim Girlin
As discussed previously, there is better to handle this. I think best
solution is to always add the instruction and to conditionally execute
them thank
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 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:59, schrieb Sven Arvidsson:
>>> This change broke a whole lot of stuff on r600g, for example Unigine
>>> Heaven:
>>>
>>> shader uses too many varying co
On Thu, Jun 16, 2011 at 10:08 AM, Brian Paul wrote:
> On 06/15/2011 03:38 PM, Bryan Cain wrote:
>>
>> My work on the GLSL IR to TGSI translator I announced on the list this
>> April is now at the point where I think it is ready to be merged into
>> Mesa. It is stable and doesn't regress any pigli
1 - 100 of 192 matches
Mail list logo
