Hi,
How far is glsl compiler working for fp64 shader?
On Sun, Feb 8, 2015 at 4:00 AM, Ilia Mirkin wrote:
> From: Dave Airlie
>
> v2: add define bit (Tapani Pälli)
>
> Patch makes following Piglit tests pass:
>arb_gpu_shader_fp64/preprocessor/define.vert
>arb_gpu_shader_fp64/preprocessor
w only computes 32 bits of the 64-bit
> result).
>
>
> On Sun, Feb 8, 2015 at 12:04 PM, Aditya Avinash
> wrote:
> > Hi,
> > How far is glsl compiler working for fp64 shader?
> >
> > On Sun, Feb 8, 2015 at 4:00 AM, Ilia Mirkin
> wrote:
> >>
> >&g
ppen
> too.
>
> On Sun, Feb 8, 2015 at 3:21 PM, Aditya Avinash
> wrote:
> > Interesting... Does the actual hardware support double? (atleast for nv0)
> > Thank you!
> >
> > On Sun, Feb 8, 2015 at 12:20 PM, Ilia Mirkin
> wrote:
> >>
> >> I
Yes. All the low end cards of AMD does not support native double precision.
(Until the most recent SI).
Are there any good papers or documentation to do soffloat? Or emulate fglrx
stuff?
On Sun, Feb 8, 2015 at 5:51 PM, Dave Airlie wrote:
> On 9 February 2015 at 08:44, Aditya Avinash
>
If softfloat is implemented, where can be a right place to put it?
On Sun, Feb 8, 2015 at 6:17 PM, Ilia Mirkin wrote:
> On Sun, Feb 8, 2015 at 5:51 PM, Dave Airlie wrote:
> > On 9 February 2015 at 08:44, Aditya Avinash
> wrote:
> >> Ya. I just want to know that part &qu
On Sun, Feb 8, 2015 at 6:30 PM, Matt Turner wrote:
> On Sun, Feb 8, 2015 at 2:51 PM, Dave Airlie wrote:
> > On 9 February 2015 at 08:44, Aditya Avinash
> wrote:
> >> Ya. I just want to know that part "only some r600".
> >> I believe some of the nv0 ca
I am sorry. I don't mean it in conventional sense. I'll describe it soon.
On Sunday, February 8, 2015, Matt Turner wrote:
> On Sun, Feb 8, 2015 at 3:45 PM, Aditya Avinash > wrote:
> > I think using softfloat at GLSL compilation stage will be a good idea
> > (a
Hi,
I was looking at RadeonFeature. It shows that Tessellation stage is "TODO".
What should I do to pick it? I am new to Mesa. Can you help me with some
documentation which is useful for me to accomplish the task?
Thank you!
--
Regards,
*Aditya Atluri.*
___
Hi,
Thank you!!
Can I join them? I have good knowledge on Tessellation using proprietary
drivers.
I don't know where to start. Can you provide me some documentation on it?
Thank you!
On Sun, Jun 8, 2014 at 1:00 PM, Matt Turner wrote:
> On Sun, Jun 8, 2014 at 5:05 AM, Aditya Avinash
Gallium interface and program all the hardware registers
> correctly. On the shader side, add support to the TGSI->LLVM IR
> converter. (src/gallium/drivers/radeonsi) You might also need some
> small changes in the LLVM shader backend, not sure about that.
>
>
Ok!
> 6) Add a lot of o
ed, Jun 11, 2014 at 8:45 AM, Aditya Avinash
> wrote:
> > Hi,
> > Thank you very much!!
> >
> > On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák wrote:
> >>
> >> This is probably one of the most difficult tasks. You'll need to:
> >>
> >>
Hi,
Thank you very much.
On Tue, Jun 10, 2014 at 5:28 PM, Marek Olšák wrote:
> On Tue, Jun 10, 2014 at 10:45 PM, Aditya Avinash
> wrote:
> > Hi,
> > Thank you very much!!
> >
> > On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák wrote:
> >>
> >>
Hi,
I have started writing code for GL_shader_atomic_counters[1]. How do I
proceed to the next steps?
Thank you!
[1]
https://github.com/adityaatluri/shader_atomic_counters/blob/master/atomic_counters.h
--
Regards,
*Aditya Atluri,*
*USA.*
___
mesa-de
Hi,
In src/mesa/main, the bindings for atomic buffers are made to
mesa_init_buffers, mesa_free_buffers, mesa_deletebuffers.
Here are the two commits made on Jul 07 2014.
https://github.com/adityaatluri/mesa/commits/master
--
Regards,
*Aditya Atluri,*
*USA.*
__
Hi,
I am sorry. This is my first patch. I'll correct it for the next time. Do
you want me to resend it?
On Wednesday, July 23, 2014, Ian Romanick wrote:
> On 07/23/2014 12:39 PM, Marek Olšák wrote:
> > I thought so too, but these bits are really missing there, e.g.
> > glDeleteBuffers doesn't un
Hi,
Do you want me to resend it?
On Thursday, July 24, 2014, Matt Turner wrote:
> The commit message should be something like
>
> "mesa: Add missing atomic buffer bindings and unbindings."
>
> On Thu, Jul 24, 2014 at 12:18 PM, Aditya Atluri
> > wrote:
> > ---
> > src/mesa/main/bufferobj.c | 3
Hi,
I am a student. I have experience in OpenCL for 3 years. I would like to
know what need to be done exactly.
Thank you
--
Regards,
*Atluri Aditya Avinash.*
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org
Hi Tom,
Do I need to have an AMD GPU for compute images to R600?
Thank you!
On Tue, Mar 18, 2014 at 9:14 PM, Tom Stellard wrote:
> On Mon, Mar 17, 2014 at 10:50:18PM -0400, Aditya Avinash wrote:
> > Hi,
> > I am a student. I have experience in OpenCL for 3 years. I would like t
Hi,
Please provide me with the feedback of my GSOC proposal.
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/aatluri/5707702298738688
Thank you.
--
Regards,
*Atluri Aditya Avinash*,
India.
___
mesa-dev mailing list
mesa-dev
Hi,
I am trying to integrate atomic counters to Mesa. I was able to do until
pipes (with the help of Marek and Ilia). How to integrate them to R600?
Thank you!
--
Regards,
*Aditya Atluri,*
*USA.*
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.
Hi,
About this patch:
1. It is not tested. I'll test it after 12th.
2. It implements atomic buffers as a surface which can be reused for
ARB_shader_image_load_store
3. You can ignore the first patch.
My questions:
1. What does R_028AC0_ALU_ATOM_CACHE_GS_0 represent?
2. What determines the values
Hi,
I lost this mail in the mail box.
I am sorry about patch related to pipe. My work is based on Ilia Mirkin
pipe commits. As per my previous mail, you can ignore pipe patch.
My current work is related to R600 backend.
On Tue, Jan 6, 2015 at 8:54 AM, Jose Fonseca wrote:
> Do we really need a n
On Tue, Jan 6, 2015 at 4:23 PM, Marek Olšák wrote:
> Having a different view type for writable shader resources sounds good.
>
> An alternative solution would be to have separate functions for images
> and buffers:
>
> - set_image_views - image views only, pipe_image_view should look
> similar to
Hi,
Sounds great but, do you think a separate buffer pipe is required for this?
Changing Constant buffer to a generic buffer (with alu+load+store) can help.
What about for R600? Do we have to add
r600_init_atom(rctx, &rctx->shaderbuf_state[PIPE_SHADER_VERTEX].atom, id++,
r600_emit_vs_shader_buffe
On Wed, Jan 7, 2015 at 4:56 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> set_shader_resources is unused.
>
> set_shader_buffers should support shader atomic counter buffers and shader
> storage buffers from OpenGL.
>
> The plan is to use slots 0..15 for atomic counters and slots 16..31
> for s
Oh. So, we get better performance if we use atomic counters as buffers
rather than textures (images) [manipulating views are expensive].
Am I right?
On Wed, Jan 7, 2015 at 8:52 AM, Marek Olšák wrote:
> On Wed, Jan 7, 2015 at 3:44 PM, Aditya Avinash
> wrote:
> >
> >
> >
Thank you!
On Wednesday, January 7, 2015, Marek Olšák wrote:
> On Wed, Jan 7, 2015 at 2:42 PM, Aditya Avinash > wrote:
> > Hi,
> > Sounds great but, do you think a separate buffer pipe is required for
> this?
> > Changing Constant buffer to a generic buffer (with
Hi,
I am currently working on implementing the extension
*GL_ARB_shader_atomic_counters*. I have a few questions.
1. What does CSO and cso_context for? Why do we have to bind with it?
2. There is a file called st_atom_constbuf.c/.h in mesa/state_tracker. As
counter buffers are different from cons
Hi,
On Sunday, November 16, 2014, Ilia Mirkin wrote:
> The direction I went in was by adapting the shader resources interface
> for this. I believe it will be possible to use for
> shader_image_load_store as well.
>
I asked some questions on mailing list about the implementation. I took the
sam
Hi,
I am having difficulty in understanding why you implemented pipe_surface in
st_atom_atomicbuf.c.
On Mon, Nov 17, 2014 at 2:24 AM, Aditya Avinash
wrote:
> Hi,
>
> On Sunday, November 16, 2014, Ilia Mirkin wrote:
>
>> The direction I went in was by adapting the shader r
atomic buffers,
> but there's no good reason to -- they will have to be handled in
> essentially the same way as regular "image" surfaces will for
> ARB_shader_image_load_store.
>
> Cheers,
>
> -ilia
>
> On Mon, Nov 17, 2014 at 11:19 AM, Aditya Avinash
Hi,
I am looking for a GSOC project. I am interested in working on driver.
Hardware available:
All AMD gpus (+1 APU)
NVIDIA k40, GTX780, Quadro 3500, GT755M
Intel: Haswell (buying on next pay date)
On Wed, Mar 18, 2015 at 2:58 PM, Matt Turner wrote:
> On Thu, Mar 12, 2015 at 9:46 PM, Matt Turne
Hi,
I would like to softfloat for GSOC. Is anyone working on it?
Thank you!! :)
On Tue, Mar 24, 2015 at 12:16 AM, Kenneth Graunke
wrote:
> On Monday, March 23, 2015 05:02:51 PM Aaron Watry wrote:
> > On a related note,
> >
> > Has anyone ported shader-db over to working on R600/RadeonSI/ > non-i
I mean, implementing fp64 on single precision systems.
On Thu, Mar 26, 2015 at 2:59 PM, Jason Ekstrand
wrote:
> On Thu, Mar 26, 2015 at 11:20 AM, Aditya Avinash
> wrote:
> > Hi,
> > I would like to softfloat for GSOC. Is anyone working on it?
> > Thank you!! :)
Do you know anyone working on it?
On Thu, Mar 26, 2015 at 3:02 PM, Jason Ekstrand
wrote:
> On Thu, Mar 26, 2015 at 12:00 PM, Aditya Avinash
> wrote:
> > I mean, implementing fp64 on single precision systems.
>
> Ok, That makes more sense! Having lowering passes for various
What about Nouveau and Intel?
On Thu, Mar 26, 2015 at 3:10 PM, Ilia Mirkin wrote:
> On Thu, Mar 26, 2015 at 3:02 PM, Jason Ekstrand
> wrote:
> > On Thu, Mar 26, 2015 at 12:00 PM, Aditya Avinash
> > wrote:
> >> I mean, implementing fp64 on single precision systems.
Are you suggesting bringing OpenCL support for Adreno gpus and using
softfloat?
On Thu, Mar 26, 2015 at 8:50 PM, Rob Clark wrote:
> On Thu, Mar 26, 2015 at 3:10 PM, Ilia Mirkin wrote:
> > On Thu, Mar 26, 2015 at 3:02 PM, Jason Ekstrand
> wrote:
> >> On Thu, Mar 26, 201
37 matches
Mail list logo
